Improving workflow with git rebase

git merge and git rebase

In the previous post, we talked about git branches and saw how one could work parallelly with multiple branches in git, and this is what makes git a goto tool when it comes to version control.

So once you’re done working with a feature/branch/topic (i.e. the new feature that you were trying out alongside the master branch), you’d be pretty much excited to merge it with the master branch and see the desired results. You can accomplish this by using git merge or git rebase, although both of them give different results. In this post, we’ll be majorly focusing on git rebase; What it is? How does it work? Etc.

What is rebase in git?

In Git, the rebase command integrates changes from one branch into another. It is an alternative to the better known “merge” command.

Most visibly, rebase differs from merge by rewriting the commit history in order to produce a straight, linear succession of commits.

How is it different from git merge?

Git merge

Let’s say that I have a branch structure that resembles the branch structure in the picture below. As you can see, I’ve split off my feature branch at the second commit and have done a little bit of work in the new feature branch. Now if I want to combine these changes with the main branch, then I would have to run a git merge.

git merge

Doing so, git groups together all the changes made in the feature branch into one large commit that contains all the changes and then place this special merge commit onto the master branch. Once I’ve performed git merge onto the master branch, the tree will show your feature branch as well as the master branch.

But if I was working on a team with other developers, my git tree could become very complex displaying everybody else’s branches and merges, thereby becoming very difficult to manage.

This is where git rebase comes to the rescue !! Let’s have a look at how rebase would handle the same situation.

Git rebase

git rebase

What rebase does is that it takes all the commits from the feature branch and moves them on top of the master branch commits. Behind the scenes what git actually does is that it blows away all the feature branch commits and duplicates them as new commits on top of the master branch.

So how do we benefit from rebasing instead of merging?

What you get with this approach is a nice clean tree with all our commits laid out nicely in a row, like a timeline which is much easier to trace.

Are there any caveats associated with rebasing? Yes !!

• Rebase doesn’t work well with open source projects or pull requests since it becomes hard to trace the changes in case of any conflicts especially when small changes are introduced into the master branch.
• It can also be dangerous if you’re working on a shared branch with other developers because git completely rewrites commits on rebasing. However, we can overcome this problem by following a simple rule that we’ll discuss in a short while.

Having talked so much about the theory and working of rebasing, let’s get to the commands.

Before you start development, make sure that the code on your local machine is in line with the remote master.

Local master out of sync with the remote master

If you want your local master to be in sync with your remote master :

git pull

This command pulls all the changes from the remote master to your local master branch.

Local master in sync with the remote master

Now checkout a new_feature branch that so that you can add some commits to this branch, keeping it separated from the local master branch.

git checkout -b new_feature
git add file1.txt
git add file2.txt
git commit -m 'This is my first commit'

Branch structure after making 2 commits

In the meanwhile, it’s quite possible that your teammates who were also working along with you on their local master might have made some changes into the remote master, so you need to take care of that too. This sort of situation is illustrated in the diagram below :

Local master out of sync with the remote master

For such cases, you need to switch back to the local master and pull back the latest changes. This will ensure that your local master is up to date with the new changes made by your teammates into the remote master.

git checkout master
git pull

Local master in sync with the remote master

Your local master is now in synch with the remote master. You can now checkout from the feature branch and rebase against your local master. This will update your local master with the latest changes made in the feature branch.

git checkout feature_branch
git rebase master

Rebasing feature_branch against the local master

Now you need to switch back to the local master and place the new changes in line with the local master branch.

git checkout master
git rebase feature_branch

Local master updated with the new features

Now all you need to do is to push these changes into the remote master and then you’ll be good to go.

git push

Remote master now updated with the new features

There you go !!

Your remote master is now updated with all the new features that you wanted to have in your project and good to go.

So now you know what is git rebase and how is it different from git merge, what are the pros and cons related to rebasing in a workflow. In the next post, we’ll be talking about more about rewriting history using git.

I’d love to hear about your suggestions if any in the comments section.

Thanks for sticking by. There a lot more to come. Thank you and have a nice day !!