Git Branching After the Fact

Posted by Samuel Mullen in Version Control      4 comments

Feb
14

We have a pretty simple Git work flow here at Databasically: Just work in master. There are a couple reasons for this: we’re not a large team, and we have a very rapid (i.e. daily) release cycle. I had been used to creating branches for every new feature, so when I found out we primarily work on the “master” branch, I was a bit shocked.

I know what you’re thinking, “But what if you go down a path and realize you need to branch in order to put in a ‘hotfix’, or you find out the story is more involved than initially thought?”: you just create a branch after the fact. Here’s how to do it in just a few easy steps:

Step 1: Know where you are and where you want to go

The first thing you need to know is where you are and where you want to go.

In the case (completely contrived example) above, I need to add a fix to what is in production (SHA: fa87cd9). So I want to roll everything back and start working from that hash point.

Step 2: Create a new branch

Now that we know where we want to go, we need to first create a new branch. We create a branch in order to force Git to remember our current line of work. In some ways, you can think of Git branches as inodes in Unix/Linux: as long as a file descriptor [branch] is pointing to an inode, it can’t be fully deleted [reset]. To do this, we’re just going to issue the “git branch <branch name>” command.

I should note that before you do this, make sure you’re clean. “Add” and “commit”, or “stash”, what you’re currently working on.

So here, I created the branch “hotfix” and you can see that HEAD, master, and hotfix are all pointing to the same SHA. You can make sure your branch exists, by issuing the “git branch” command. Now, we can make our changes in master and push to production.

Step 3: There is No … step 3

This means you, Bruce.

Step 4: Reset Master

Now that we have a branch (created in step 2) we’ll reset HEAD to our chosen hash. We do that using git’s “reset” command:

git reset --hard fa87cd9

The log will look something like this:

After making our change and committing, our log looks like this:

Now we can push that into production and get back to what we were working on.

Step 5: Rebase and Merge

Step 5a: Rebase Master

In order to get back to what we were working on, we need to first rebase the changes we made in master into production. To do that, first checkout hotfix and run git rebase master

git checkout hotfix
git rebase master

By rebasing master, we replay those changes made in master onto our “hotfix” branch. Our hotfix branch should now look like this:

Notice where HEAD and hotfix are, and notice also where master is. It is now safe to merge everything back to master – and without leaving those unsightly branch paths.

Step 5b: Merge

First things first: check out master. Next: merge hotfix

git checkout master
git merge hotfix

You output will look something like this:

And your log will look like this:

And everything is caught up. At this point you can delete the hotfix branch:

git branch -d hotfix

Conclusion

This model works well for us, but I’m sure as we grow we’ll likely have to adopt more involved models such as the “A successful Git branching model” used by nvie.com. As we grow and modify our processes, we’ll be sure to let you know what we find to work and what we find which doesn’t.

Further Reading

• The Git SCM
• A Successful Git Branching Model
• Pro Git Book
• Git Immersion

Notes:

In this post, I have been calling “git log” with my alias “git lol” here is the details of the alias:

log --graph --decorate --date=local --pretty=format:'%h %cd (%an) %s%d'