![]() ![]() Let's contextualize these statements with a side-by-side example!Īs illustrated above, the merge operation intertwined the branches together by creating a new single merge commit ( C7), causing a diamond shaped non-linear history - essentially preserving history as it happened. In other words, the key difference between merge and rebase is that while merge preserves history as it happened, rebase rewrites it. Reading the official Git manual it states that “rebase reapplies commits on top of another base branch”, whereas “merge joins two or more development histories together”. What's the difference between merge and rebase? Unlike merges, multiple rebases do not add up. Making re-integration into the main branch easier.īecause? ➝ your feature work can be presented as one big ‘patch file’ (aka diff) in respect to the main branch, not having to ‘explain’ multiple parents: At least two, coming from one merge, but likely many more, if there were several merges. Summary: When possible, rebase is almost always better. “Likely -if the changes I raked in have little to do with my work- history actually won't change much, if I look at my commits diff by diff (you may also think of ‘patches’).“.“Rewrite the history of my changes to reflect that.” (need to force-push them, because normally versioning is all about not tampering with given history).Do so by pretending my feature work started later, in fact on the current state of the main branch.” “Give the changes of the main branch (whatever its name) to my feature branch.“okay, we got two differently developed states of our repository.While the accepted and most upvoted answer is great, I additionally find it useful trying to explain the difference only by words: ![]() ![]() ( Disclaimer: I'm the author of the "10 things I hate about Git" post referred to in another answer) If you rebased your code onto master instead of merging it, it would look like this: Write tutorialĪll of your commits are at the top (newest), followed by the rest of the master branch. That is, merges and UI commits in the middle of your documentation commits. Merge remote-tracking branch 'origin/master' into fixdocs Without rebase, your history might look something like: Write tutorial Let's say other people on your project are working on the user interface, and you're writing documentation. ![]() I'll try explaining this with a just-words example. I seem to recall having read blog posts from programmers who only use rebase and others that never use rebase. So if you want a "clean history", you need to use rebase. Some people find this messy or undesirable.įor reasons I don't understand, GUI tools for Git have never made much of an effort to present merge histories more cleanly, abstracting out the individual merges. If you do this again later with more changes, you begin to create an interleaved thread of histories: some of their changes, some of my changes, some of their changes.
0 Comments
Leave a Reply. |