this post was submitted on 04 Apr 2024
1113 points (98.1% liked)
Programmer Humor
19589 readers
2168 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn't part of the same feature branch.
Agreed, you also lose the info about the resolved merge conflicts during the merge (which have been crucial a few times to me).
Well, with a rebase workflow, there should be no merge conflicts during the final merge. That should always be a fast-forward.
Of course, that's because you shift those merge conflicts to occur earlier, during your regular rebases. But since they're much smaller conflicts at a time, they're much easier to resolve correctly, and will often be auto-resolved by Git.
You're still right, that if you've got a long-running feature branch, there's a chance that a conflict resolution broke a feature that got developed early on, and that does become invisible. On the flip-side, though, the person working on that feature-branch has a chance to catch that breakage early on, before the merge happens.