Get it All
Together

Those of us who remember suffering through Subversion repository woes will remember our elation at finding Git. Things Subversion promised but never quite delivered were handled with ease when we got to Git. Merging changes? Updating branches? Rolling back changes?? All a snap.

But there are some subjects on which I confess I have adopted the “we’ll get to that particular voodoo later” attitude. One of those was figuring out what the difference between git merge and git rebase. I shan’t bore you with that whole story: Google answer-seekers, rejoice! Instead, here goes:

The difference between git rebase vs merge is the commit history.

If you rebase a branch from it’s source (feature branch from master, let’s say), none of the commits from the source branch will show up in the feature branch’s history. If you merge the two branches, you will have both branch’s commits in the source branch.

The result of merging therefore is a commit history that includes a lot of work that did not happen in the current branch. The result of rebasing is a commit history that does not include changes that have recently been added to the current branch from elsewhere. Both of these scenarios have advantages and disadvantages.

Rebase feature branches, merge master

Sure. There’s lots of nuance to this kind of broad-strokes pronouncement. I encourage you to read this article, which has so far been the best tutorial on the subject that I have read. But for brevity’s sake, in probably 90% of cases, the above statement is your best guide.

Feature branches should presumably have lots and lots of commits. Personally, every time I think I’ve got a feature or bug “fixed,” I end up committing that new change right away. Yes, it makes for a lot of logs. But it also means the exact moment when a file got changed is much more reliably pinpointed.

If I were to merge my master branch into my feature branch, I’d also have all the commits to master from other developers mixed up among my branch’s commits. File changes that have nothing to do with my feature would appear as their own logs. For this reason, I’d rather just have my feature branch focus on the work that I did, with commits that match.

When I bring changes from a feature branch into master, I actually¬†do want the small changes and logs to appear in the master branch. I may need to track a specific file change, and the feature branch will soon be either destroyed or archived. Incorporating a feature branch’s commits helps me do that.

Git rebase vs merge: the advantage

I’m assured that feature branches contain logs that only concern that branch by rebasing changes from master into them. I am assured that all that work from all branches will be reflected in the master branch’s logs by merging changes into master.

Hopefully, this discussion of why you would use git rebase vs. merge was helpful. Do you have another theory for managing these two features? Please comment below!!