1205
A classic
(sopuli.xyz)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 26 Aug 2023
1205 points (98.4% liked)
Programmer Humor
32479 readers
228 users here now
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.
founded 5 years ago
MODERATORS
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.
!usernamechecksout@lemmy.zip
Inschools project, I once used the flag ours.
git push -f