Merge keeps the original timeline. Your commits go in along with anything else that happened relative to the branch you based your work off (probably main). This generates a merge commit.
Rebase will replay all the commits that happened while you were doing your work before your commits happen, and then put yours at the HEAD, so that they are the most recent commits. You have to mitigate any conflicts that impact the same files as these commits are replayed, if any conflicts arise. These are resolved the same way any merge conflict is. There is no frivolous merge commit in this scenario.
TlDR; End result, everything that happened to the branch minus your work, happens. Then your stuff happens after. Much tidy and clean.
Never use rebase for any branch that has left your machine (been pushed) and which another entity may have a local copy of (especially if that entity may have committed edits to it).
Merge gives an accurate view of the history but tends to be “cluttered” with multiple lines and merge commits. Rebase cleans that up and gives you a simple A->B->C view.
Personally I prefer merge because when I’m tracking down a bug and narrow it down to a specific commit, I get to see what change was made in what context. With rebase commits that change is in there, but it’s out of context and cluttered up with zillions of other changes from the inherent merges and squashes that are included in that commit, making it harder to see what was changed and why. The same cluttered history is still in there but it’s included in the commits instead of existing separately outside the commits.
I honestly can’t see the point of a rebased A->B->C history because (a) it’s inaccurate and (b) it makes debugging harder. Maybe I’m missing some major benefit? I’m willing to learn.
I know this is a meme post, but can someone succinctly explain rebase vs merge?
I am an amateur trying to learn my tool.
Merge keeps the original timeline. Your commits go in along with anything else that happened relative to the branch you based your work off (probably
main). This generates a merge commit.Rebase will replay all the commits that happened while you were doing your work before your commits happen, and then put yours at the HEAD, so that they are the most recent commits. You have to mitigate any conflicts that impact the same files as these commits are replayed, if any conflicts arise. These are resolved the same way any merge conflict is. There is no frivolous merge commit in this scenario.
TlDR; End result, everything that happened to the branch minus your work, happens. Then your stuff happens after. Much tidy and clean.
Thanks for the explanation. It makes sense. To my untrained eyes, it feels like both merge and rebase have their use. I will try to keep that in mind.
Never use rebase for any branch that has left your machine (been pushed) and which another entity may have a local copy of (especially if that entity may have committed edits to it).
Merge gives an accurate view of the history but tends to be “cluttered” with multiple lines and merge commits. Rebase cleans that up and gives you a simple A->B->C view.
Personally I prefer merge because when I’m tracking down a bug and narrow it down to a specific commit, I get to see what change was made in what context. With rebase commits that change is in there, but it’s out of context and cluttered up with zillions of other changes from the inherent merges and squashes that are included in that commit, making it harder to see what was changed and why. The same cluttered history is still in there but it’s included in the commits instead of existing separately outside the commits.
I honestly can’t see the point of a rebased A->B->C history because (a) it’s inaccurate and (b) it makes debugging harder. Maybe I’m missing some major benefit? I’m willing to learn.