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.
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.
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.
This way I can wreck their shit instead! Enjoy debugging this one Tim, you obtuse bastard!
Dear god yes. Please just let me deal with the conflict before the kids make it worse.
[email protected]
Inschools project, I once used the flag ours.
git push -f