, , , ,

One of the many things I like about Git is how easy it is to create and work on topic branches. A topic branch is a short lived branch that is used to perform a particular unit of work and which usually lives in the users local copy of the repository. These branches become very handy specially when working on experimental features, trying out different approaches to a problem or those (more than occasional) high-priority, ultra-urgent, critical-blocker (i.e. typo somewhere in the copyright notice which nobody notices) pops up.

The purpose of this post is to provide a quick guide on working with topic branches and using rebase to merge the changes.

Rebase vs Merge

Git provides two ways in which you can get all the commits made on one branch onto another; git-merge or git-rebase.

The problem I have with the git-merge approach is that you end up polluting the commit history in the remote repository with information about topic branches which doesn’t make sense to anyone but yourself. These merge commit messages can become a bit of a problem specially when using git as a front end to other version control systems such as SVN, in which case merge commit messages look quite abnormal.

With git-rebase you basically apply all the changes you committed in the topic branch on top of the target branch and so it appears as if you made all the changes on the current branch itself. Therefore, the commit history becomes linear and no one aside from yourself will know that you worked on a topic branch or that one even existed.

Working on topic branches

Creating a new topic branch

You can create a new branch using:

$ git branch topic1

Although we’ve created a new branch, we’re still currently on the original branch we started on. To switch to the new branch, we use:

$ git checkout topic1

Instead of the two commands above, we can create and switch to the new branch using the single following command:

$ git checkout -b topic1

Rebasing with master

Let’s assume that we’ve made some changes which we’ve committed to the topic branch, and we now want to get these across to our master branch.

Before doing this, lets first checkout the master branch and update it to the latest remote version:

$ git checkout master
$ git pull

Now lets rebase the topic branch with the master. This is done by:

$ git checkout topic1
$ git rebase master

We can again combine the two commands above into one and issue the following instead:

$ git rebase master topic1

If git discovers any conflicts while trying to rebase, it will stop and wait for you to resolve any conflicts. After you fix any conflicts, you need to add (but not commit) the fixed files, and then issue the git rebase command with the --continue option:

$ git add .
$ git rebase --continue

Resolve any further conflicts you may encounter and issue the above commands until git says its done with the rebasing.

Merging rebased topic branch with master

Now that we’ve rebased our topic branch with the master branch, we still need to get all those extra commits in the topic branch onto master. We do this by checking out the master and merging with the topic branch:

$ git checkout master
$ git merge topic1

If you now take a look at the commit history on the master branch, you will see a nice linear commit history in which it appears as if you had performed all your commits after the latest commit on master. You’ll also notice that all the usual merge commits are no longer there.

About these ads