This post has originally been published on https://juristr.com/blog/2019/12/git-rebase-vs-merge/. Go to juristr.com/blog for more content
Git is an "old" technology if you want that has been around for ages now. Still, when speaking or collaborating with other software developers, I always again see them struggle with apparently basic commands. But it doesn't have to be scary. In this article I'm going to quickly walk you through the difference between "merge" and "rebase".
Before starting, if Git is something that sounds interesting to you, where you think you might want to learn more and dig deeper, then I have something for you 😃. A while ago, I recorded a ~30min course on Egghead that walks you through the main commands you need to know to safely use Git on a daily basis. Check out the course here:
Merge vs Rebase
Other Resources
You're more a "book person"? Then you might want to check out the "Rebase Book" written by my friend Pascal Precht.
Top comments (8)
thanks for posting and making the video! great explanation. seems like
git rebaseis cleaner and maybe preferred?what are some example situations when
git mergeis the better method to go with? (other than the example you mentioned in the video when you're not the only working on a feature branch)It's not "cleaner" or "preferred" 🙂. It's another option to "git merge".
Rebasing (for merging) is basically always preferred when you want to have a linear git commit history. On the other side, if you're following branching models like "git flow" then that's probably not what you want, as that strategy suggests to keep merge commits. On the other side, if you're using something like "trunk based development" (trunkbaseddevelopment.com/) then you will.
Now apart from updating feature branches etc, having a linear commit history on the main branch (i.e. master) has helped me a lot for things like "git bisect" to debug problems in a larger git based monorepository.
The trick is that the statement "don't use rebase on shared branches" is just wrong.
+1 IMO, the working branch should be rebased against the upstream. But shared branches ie. Master / or anything else similar should have merge commits.
Can you elaborate on that? If I got you right, you basically say that the feature branches should be rebased to be updated with master, but when you merge it back it, you want to use a merge commit, so use "git merge". Is that what you intended?
What do you mean by "is just wrong"? You suggest using rebase also on shared branches? Can you elaborate?
git rebaseis probably my favorite git command currently. It just helps to create a much cleaner commit history.Absolutely. The only important thing about
rebaseis to properly understand it. Especially the thing that it is actually rewriting your history and thus you shouldn't do it on shared branches etc :)But once you get past that, it's pure power 🙂