What's the difference between git merge
and git rebase
?
This question is related to
git
merge
git-merge
rebase
git-rebase
I found one really interesting article on git rebase vs merge, thought of sharing it here
I really love this excerpt from 10 Things I hate about git (it gives a short explanation for rebase in its second example):
3. Crappy documentation
The man pages are one almighty “f*** you”1. They describe the commands from the perspective of a computer scientist, not a user. Case in point:
git-push – Update remote refs along with associated objects
Here’s a description for humans:
git-push – Upload changes from your local repository into a remote repository
Update, another example: (thanks cgd)
git-rebase – Forward-port local commits to the updated upstream head
Translation:
git-rebase – Sequentially regenerate a series of commits so they can be applied directly to the head node
And then we have
git-merge - Join two or more development histories together
which is a good description.
1. uncensored in the original
While the accepted and most upvoted answer is great, I additionally find it useful trying to explain the difference only by words:
merge
rebase
summary: When possible, rebase is almost always better. Making re-integration into the main branch easier.
Because? ? 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. Unlike merges, multiple rebases do not add up. (another big plus)
Git rebase is closer to a merge. The difference in rebase is:
So that means that all your local commits are moved to the end, after all the remote commits. If you have a merge conflict, you have to solve it too.
Personally I don't find the standard diagramming technique very helpful - the arrows always seem to point the wrong way for me. (They generally point towards the "parent" of each commit, which ends up being backwards in time, which is weird).
To explain it in words:
For 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. So if you want a "clean history", you need to use rebase.
I seem to recall having read blog posts from programmers who only use rebase and others that never use rebase.
I'll try explaining this with a just-words example. Let's say other people on your project are working on the user interface, and you're writing documentation. Without rebase, your history might look something like:
Write tutorial
Merge remote-tracking branch 'origin/master' into fixdocs
Bigger buttons
Drop down list
Extend README
Merge remote-tracking branch 'origin/master' into fixdocs
Make window larger
Fix a mistake in howto.md
That is, merges and UI commits in the middle of your documentation commits.
If you rebased your code onto master instead of merging it, it would look like this:
Write tutorial
Extend README
Fix a mistake in howto.md
Bigger buttons
Drop down list
Make window larger
All of your commits are at the top (newest), followed by the rest of the master
branch.
(Disclaimer: I'm the author of the "10 things I hate about Git" post referred to in another answer)
Source: Stackoverflow.com