1114
Rebase Supremacy (programming.dev)
you are viewing a single comment's thread
view the rest of the comments
[-] Atemu@lemmy.ml 2 points 7 months ago

you also lose the merge-commits, which convey no valuable information of their own.

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.

[-] someonesmall@lemmy.ml 1 points 7 months ago

Agreed, you also lose the info about the resolved merge conflicts during the merge (which have been crucial a few times to me).

[-] Ephera@lemmy.ml 1 points 7 months ago

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.

this post was submitted on 04 Apr 2024
1114 points (98.1% liked)

Programmer Humor

19622 readers
71 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

founded 1 year ago
MODERATORS