Up until now, I had only merged branches into one another but recently I discovered another option -- rebasing! Rebasing and merging are essentially doing the same thing so what exactly goes on behind the scenes for each?
Merge
Git merge combines multiple commits into one history. It will look at the two branches you want to combine and finds a common commit between them. Next, it takes the content of the feature or source branch and integrates it with the target (in our example, master) branch by creating an entirely new commit. This new commit holds the history of both of your branches. Because of that, you'll see all of the commits in chronological order.
Rebase
Rebasing is a bit different. Instead of merging the history of your two branches together from one base commit, you're actually making it seem like you created your branch from a different commit than you originally did. This allows you to keep a linear project history. This makes it a lot easier in the future to revert a change if you have a bug because you won't have to dig through to where the commit was made in the timeline.
So, which do you prefer? Rebase or merge? I'd love to hear in the comments below!
Be sure to follow me on Twitter for lots of tweets about tech, and if I'm being honest, lots of tweets about dogs too.
Latest comments (29)
I rebase on my feature branches through development and right before merging so in the history it looks like i branched off the latest master and merged. This makes it easy to see branches in isolation.
If your place of employment does not enforce some sort of git style rules, this will throw your tidiness out the window.
for good habits i merge all the time.
Squash
When I was first starting out in development, one of my mentors told me that rebasing is rewriting git history. Whenever you rewrite history you must take extra precautions, It can be very easy to mess things up.
But it is a very important skill to have in order to GIT good :)
I might be miss something, but I always merge.
What is the point of having two tools doing almost the same thing? One of them is potentially dangerous and might screw the work if used in a public branch.
Rebase allows to have a clean linear history.
Well, I guess it's personal, but I don't mind merge commits. In our company we usually have max 3 developers working on the repo at the same time, so the git history looks well readable. But I suppose that for the project with 20 developers the git history with merge commits everywhere would look like a mess.
Clean commit messages +
amending if necessary + merge - this is all I need.It's not about how it looks like. Rebasing allows backtracking to specific commits when hunting bugs. It makes git-bisect a very powerful tool for pin-pointing buggy commits. When you know which small commit introduced the bug, you are able to fix it more quickly. This is also why smaller commits are way better than large commits.
It's possible to backtrack to specific commits and git-bisect with
mergeas well.Hi! I'm confused. I can create a feature branch, push it, and do rebase (thinking that is my branch) or I have to follow the golden rule in this case too?
Private/public, in this regard, is not about who can see the branch but about who is going to work on it.
If only you push to that feature branch, and others are only reading it to review your code, then it's safe to rebase it. Your peers will not lose their work due to your rebase because they don't have any work inside that branch (except from commits it shares with
master, of course).If more developers other than you have pushed to that branch, you can still rebase - but you have to coordinate the rebase with them to make sure you don't lose any of their work. If there aren't that many of them, and if they only pushed to that branch one specific commit that you have personally requested from them (e.g. - you needed something that's out of your expertise), then it's easy. But if many developers are constantly pushing to that branch, coordinating a rebase becomes much harder, much riskier, and with much more damage potential - so it's best to avoid it and just merge.
Thanks! 😊
Hey forgive me if this question is too newbie, but if you have to do a PR revert (not a GitHub way) it is more easy when you have a merge commit, isn't it?
I used to rebase in my personal projects because I am controlling my code and git push —force isn’t a problem. At work, I prefer use to merge because I think few dangerous use that project that everybody is writing code.
Great Article Kara!
Pretty much the same as everyone else. Rebase up until I push it into the public sphere, then I go to merging.
Thanks so much, Luke!
I basically always rebase if I'm moving changes away from master, and I merge towards master. Unless I'm on a shared branch, then I always merge...
Same here!