{"id":2245,"date":"2011-11-21T07:58:11","date_gmt":"2011-11-21T15:58:11","guid":{"rendered":"http:\/\/blog.mozilla.org\/webdev\/?p=2245"},"modified":"2012-06-18T08:46:13","modified_gmt":"2012-06-18T16:46:13","slug":"git-using-topic-branches-and-interactive-rebasing-effectively","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/webdev\/2011\/11\/21\/git-using-topic-branches-and-interactive-rebasing-effectively\/","title":{"rendered":"Git: Using topic branches and interactive rebasing effectively"},"content":{"rendered":"

When I first joined the webdev group at Mozilla I was a Mercurial<\/a> refugee who had never used git<\/a> or github<\/a>. I was always daunted by git and suddenly I had to learn it really fast!\u00a0 Fast forward to today and I can’t imagine working on a highly collaborative project without git or github.\u00a0 Here is the workflow we use for the addons.mozilla.org<\/a> project.\u00a0 I highly recommend it and I’ll summarize exactly why at the end.\u00a0 It’s pretty similar to how I’ve heard a lot of teams work but has some subtle differences.<\/p>\n

Using topic branches<\/h3>\n

The first thing I do is sync up with master and create a topic branch for my new feature or bug fix:<\/p>\n

git checkout master\r\ngit pull\r\ngit checkout -b add-email-to-install<\/pre>\n
Now I have a branch I can commit code into without affecting master.\u00a0 Git checkout makes it super easy to switch between branches in the same repository clone if I’m multi-tasking or applying hot fixes.\u00a0 In addition to git checkout, you can also use git stash<\/a> to switch tasks.<\/p>\n
Commit messages<\/h3>\n
It’s really important to write a well-formed git commit message<\/a>. We always include a ticket number into bugzilla<\/a>, our tracker, so that anyone can get the full back story about a change.<\/p>\n
Ask for a code review<\/h3>\n
Once I’ve added my feature with passing tests I commit my changes, push to my personal fork of the repository, and ask someone on my team to review the code.\u00a0 On addons.mozilla.org<\/a> we just ping each other in IRC with a link to the commit or a link to the compare view<\/a>.\u00a0 If no one is around we submit a pull request<\/a>.<\/p>\n
Github has a sweet interface where you can write comments directly on the diff, like this:<\/p>\n
\"\"<\/a><\/p>\n
Whoops, another change is needed based on feedback from the code review.<\/p>\n
Fixing up the topic branch<\/h3>\n
The nice thing about working in a topic branch is it’s isolated from master and no one else is tracking that branch so I can use git rebase to create the best commit before merging into master.\u00a0 Let’s say I have some commits on my branch like this:<\/p>\n
$ git log --pretty=oneline -2\r\n825d662cc69774e412119e1eb7ae0900c29d89a0 Fix: put code in a transaction\r\n31378788f321b46f5e27f9fb51bdd19365636871 Adds email to the install record (bug #NNNNNN)<\/pre>\n
What I really want is to combine those two commits into one.\u00a0 I can do that with git rebase —interactive<\/a>. I type:<\/p>\n
git rebase -i HEAD~2<\/pre>\n
Then I’ll get a prompt for rebasing my last two changes:<\/p>\n
pick 3137878 Adds email to the install record (bug #NNNNNN)\r\npick 825d662 Fix: put code in a transaction\r\n\r\n# Rebase 194b59d..825d662 onto 194b59d\r\n#\r\n# Commands:\r\n#\u00a0 p, pick = use commit\r\n#\u00a0 r, reword = use commit, but edit the commit message\r\n#\u00a0 e, edit = use commit, but stop for amending\r\n#\u00a0 s, squash = use commit, but meld into previous commit\r\n#\u00a0 f, fixup = like \"squash\", but discard this commit's log message\r\n#\u00a0 x, exec = run command (the rest of the line) using shell\r\n#\r\n# If you remove a line here THAT COMMIT WILL BE LOST.\r\n# However, if you remove everything, the rebase will be aborted.\r\n#<\/pre>\n
If I put the word fixup next to my second commit, it folds it into the first:<\/p>\n
pick 3137878 Adds email to the install record (bug #NNNNNN)\r\nfixup 825d662 Fix: put code in a transaction<\/pre>\n
Now I have one commit (it’s actually a new commit) that contains all of my changes:<\/p>\n
$ git log --pretty=oneline -1\r\nc7846808c8296dd49d49612101aaed7cdfd6d220 Adds email to the install record (bug #NNNNNN)<\/pre>\n
Pretty slick, right?<\/p>\n
Typically you’d want to wait until everyone has had a chance to review your code before you start rebasing.\u00a0 However, git pull requests do handle rebased changes.\u00a0 You can push -f to your own fork and the pull request will remove the old commits from the conversation and add the new ones at the bottom.<\/p>\n
Merge into master<\/h3>\n
When my changes are ready, I can merge my branch back into master.\u00a0 However, I don’t need to make a merge commit if there’s only one commit to merge in.\u00a0 That would clutter up the logs.\u00a0 I can do this with a fast-forward merge:<\/p>\n
git checkout master\r\ngit merge --ff add-email-to-install<\/pre>\n
Now I can close the ticket in our tracker with a direct link to my changes.<\/p>\n
Sometimes I might actually make multiple commits on a single topic branch.\u00a0 In this case I would<\/em> want to retain the automatic merge commit.\u00a0 That is, I wouldn’t do a fast forward merge in the case of multiple commits:<\/p>\n
git merge --no-ff add-email-to-install<\/pre>\n
I can then close the ticket with a link to the single merge commit that shows all changes introduced by the branch.<\/p>\n
Fixups, for ninjas<\/h3>\n
If you follow this pattern you’ll become accustomed to frequently fixing up your topic branch. I created a ninja alias for it in ~\/.gitconfig like this:<\/p>\n
[alias]\r\n\u00a0\u00a0\u00a0 ...\r\n\u00a0\u00a0\u00a0 fix = \"!f() { git commit -a -m \\\"fixup! $(git log -1 --pretty=format:%s)\\\" && git rebase -i --autosquash HEAD~4; }; f\"<\/pre>\n
When on a topic branch with uncommitted changes I can then type:<\/p>\n
git fix<\/pre>\n
That will automatically commit my change and pre-configure the rebase prompt to fold it into the last commit.<\/p>\n
UPDATE:<\/strong> As pointed out in the comments, a quicker and simpler way to fix up and rebase just the last<\/em> commit (i.e. not multiple commits) is:<\/p>\n
[alias]\r\n\u00a0\u00a0\u00a0 ...\r\n\u00a0\u00a0\u00a0 fix = \"commit -a --amend -C HEAD\"<\/pre>\n
Synchronization with master, for ninjas<\/h3>\n
If you’re on a project that has a lot of commit activity you’ll probably want to rebase your feature branch on top of master often.\u00a0 I added a ninja alias to ~\/.gitconfig for that too:<\/p>\n
[alias]\r\n\u00a0\u00a0\u00a0 ...\r\n\u00a0\u00a0\u00a0 sync = \"!f() { echo Syncing $1 with master && git checkout master && git pull && git checkout $1 && git rebase master; }; f\"<\/pre>\n
When I’m on my feature branch and I want to synchronize it with all the latest changes on master, I type:<\/p>\n
git sync add-email-to-install<\/pre>\n
The main benefit to syncing a branch before merging into master is that a fast-forward merge won’t create a new commit.\u00a0 This helps you safely delete work branches later on since it won’t look like you have un-merged changes.\u00a0 It’s also useful to do a last minute spot check before merging into master: do the tests still pass? do I need to adjust my SQL migration script? etc.<\/p>\n
UPDATE:<\/strong> Fernando Takai posted a simpler version of this in the comments using git checkout -<\/code> to go back to the last branch you were on. You can then simply type git sync<\/code> from the branch. Thanks!<\/p>\n
Why resort to all these ninja like git strategies?<\/h3>\n