Feature branch development

I remember when I had lunch with a friend, back when I was using SVN and he was using git.  He said “it’ll change your life”.  I had read about darcs years ago and had read Joel’s post about distributed version control systems.  I was still like “meh.  SVN does what I need it to do–tag releases, keep track of changes, and I can branch if I need to”.

Boy, was I wrong.

I’ve been using git since around 2014, and it’s great.  I don’t remember where I heard it, but someone said “branching in SVN is easy, it’s the merging that is difficult”.  Git takes the pain out of merging (mostly, of course you can still hose yourself pretty well).  I have to also reference this classic XKCD comic whenever I talk about git.

Regardless, one of the things I’m loving about working with git is that if you always use feature branches, use story numbers in your branch name (like story-update-123), and you set up your prepare-commit-msg script, you can track back every change to a story.  Here’s my prepare-commit-msg script:

#!/bin/sh

# from http://stackoverflow.com/a/16061192/203619

if story_id=`git branch |grep '*'|sed 's/.*-//'`
then
    echo "[#$story_id]" >> "$1"
fi

Another nice feature of the branch handling is that you can roll forward and backward branches. I use bitbucket, so I use the GUI revert command, which creates a nice revert PR. (I then immediately revert the revert PR so that I can apply the intended changes in the future by merging the second PR.) This makes it possible to push a feature to staging, realize it isn’t fully baked, and revert it so you can get out another feature release. Perhaps you could do this with SVN or another centralized VCS, but I was never comfortable enough with branches to do it.

All in all, git has been life changing as a developer. Thanks Russ, you were right!