this post was submitted on 28 Aug 2024
525 points (97.0% liked)
Programmer Humor
32410 readers
581 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
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
Another solution to this situation is to squash your changes in place so that your branch is just 1 commit, and then do the rebase against your master branch or equivalent.
Works great if you're willing to lose the commit history on your branch, which obviously isn't always the case.
Yeah that's what I did as a workaround. Reset (soft) to the first parent commit and do a single commit with all the changes.