In honor of my new license plate, I decided I wanted to do a quick, little post on rebase vs merge, how each one works, and how I choose to use each one. Let's first look at how each one works.

How Rebase and Merge Work

To start we have two branches. We have our master branch and we have a Feature 2 branch that we just cut from master. Both are shown below. Since we just cut our Feature 2 branch it is the exact same as master, nothing has changed yet.

After a couple of days, our Feature 2 branch has some new commits on it with the new feature work that has been done.

During that same couple of days, the master branch also had a couple of new commits added from another developer who is also working on the project.

Now we are ready to test our Feature 2 branch but before we test it we want to make sure it is updated with all of the new code that is now in master. In order to update our Feature 2 branch with the new changes in master we have two options, we can merge or we can rebase.

Merging

The merge command will let us take all of the development changes present on the master branch and integrate them into the Feature 2 branch with a single merge commit.

That single merge commit encompasses all of the changes from the master branch. One downside to merging is that if your master branch is very active it can pollute your feature branchs history quite a bit. If you prefer to not have merge commits in your feature branch history then you might want to consider rebasing.

Rebasing

We can use the rebase command to integrate changes from the master branch into our Feature 2 branch by rewriting the commit history in order to produce a straight, linear succession of commits. Rebasing moves the entire Feature 2 branch to begin on the tip of the master branch.

As you can see there are no extra commits and everything is lined up as if we had just added the Feature 2 commits right on top of the new master branch.

My Rebase vs Merge Strategy

When it comes to rebasing vs merging, I use both in different scenarios. When I need to update a feature branch I am working on with master I will ALWAYS rebase. I choose to do this because I like my branch history clean. If all the commits are new code it is easier for me to read and follow. I use merging when it comes time to put my branch changes into master. I like to do this because then I get a single commit that is easy to find with all my branch changes in it.

In my experience, merging when incorporating a feature branch into a master branch is the most common practice when you are working on a repo with a team. How you choose to handle updating your own personal feature branches is usually left up to you and leads me to my next point.

There Is No "Right" Way

Rebasing vs Merging is one of those age-old debates that exist in the dev community much like tabs vs spaces. Also, like tabs vs spaces, when it comes to rebasing vs merging there is no right way to do things. Some people are adamant that you must always merge. Others believe the only correct way to do things is by rebasing. Guess what, neither are right or wrong! How you choose to use rebase vs merge is really up to you and your workflow.

The same concept applies to MANY common dev debates like how many characters a single line should be, how many lines a method should have, etc. Often when you are learning something new all you want to know is the "right" way to do things. You are constantly looking for someone to tell you what to do. Unfortunately, it is not always that easy. When you are starting out, don't look for the right way, look for the way that works best for you. Everyone has their own style and way they work most efficiently. Look around you, soak in what other devs are doing, but in the end decide for yourself what works best.

What other "dev debates" can you think of where both ways work and it's simply personal preference as to which one you choose?