I feel like I often would prefer to get the merge conflict. So many times my coworkers will somehow mess up the code I committed when resolving the conflict.
Rebase all of your work branches onto HEAD so that conflicts require refactoring the first commit where things don’t match up. This can make conflicts easier to deal with (in my humble opinion) since you deal with conflicts earlier in your commit history as opposed to at the end after ALL of your changes are made.
Plus a linear history is super nice to work with later on.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
I feel like I often would prefer to get the merge conflict. So many times my coworkers will somehow mess up the code I committed when resolving the conflict.
Inschools project, I once used the flag ours.
Dear god yes. Please just let me deal with the conflict before the kids make it worse.
!usernamechecksout@lemmy.zip
git push -fThis way I can wreck their shit instead! Enjoy debugging this one Tim, you obtuse bastard!
Rebase all of your work branches onto HEAD so that conflicts require refactoring the first commit where things don’t match up. This can make conflicts easier to deal with (in my humble opinion) since you deal with conflicts earlier in your commit history as opposed to at the end after ALL of your changes are made.
Plus a linear history is super nice to work with later on.
I always squash my commits before rebasing. Is your way easier? I never really seem to have a problem with merge conflicts.
We squash when merging. Final git history is super clean and linear.