this post was submitted on 28 Aug 2024
527 points (97.0% liked)
Programmer Humor
32472 readers
992 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You need to merge more often.
Rebase. That's where the real trauma is.
Neither rebasing nor merging should cause trauma if everyone on the team takes a day or two to understand git
I consider myself above average in terms of Git know how. But I've come across situations using rebase where you're stuck resolving the same conflicts over several commits.
I still don't understand that part quite well.
This doesn't happen when you do a normal merge though. Making it easier to manage
The reason for this is that git rebase is kind of like executing a separate merge for every commit that is being reapplied. A proper merge on the other hand looks at the tips of the two branches and thus considers all the commits/changes "at once."
You can improve the situation with git rerere
Holy shit! I never took the time to read about it rerere. But it all makes sense now.
However, it's still a lot of extra steps for what could otherwise be really simple with a regular merge.
Is there really a big advantage in using rebase vs merge other than trying to keep a single line of progress in the history? It's it really worth all the hassle? Especially if you're using a squash merge in a pull request...
I don't think
rerereapplies here. Once you do a rebase, the rewritten commits should contain the conflict resolutions. The only way conflicts could reoccur on subsequent rebases is if changes reoccur in those same files/lines.