Git Branching After the Fact
Posted by Samuel Mullen in 
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
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'
Capistrano deploy error "fatal: unable to create '.git/index.lock': File exists"
This isn’t specific to capistrano, necessarily, but I ran into it deploying.
fatal: unable to create '.git/index.lock': File exists
read more
git: You asked me to pull without telling me which branch …
Received this error when trying to pull from a remote origin:
You asked me to pull without telling me which branch you want to merge with, and 'branch.master.merge' in your configuration file does not tell me either.
git: failed to push some refs
I’m really digging git, but its error messages are less than helpful at times.
git push origin master error: failed to push some refs to origin
Most likely, there are changes in the remote repo that you need to pull first:
git pull origin master
Resolve any conflicts, then you can push to the remote git repo.
I’m not sure why “failed to push some refs” couldn’t include “(do you need to pull?)”