A couple months ago I found an article that explained how one company uses git branches to manage their software deployment process.  They use a branch off their development branch for each feature and then when the feature was done they merged it back into their development branch.  During my last project I used something similar to this (mostly so I could fix bugs as they were reported) but the feature branches usually only lasted a few hours or at most a couple days.

In the comments, someone linked to the following YouTube video which explains why it's a bad idea to do this in the long term.

The video isn't super long but the TL;DR version of it is that when you perform a merge there is a cost to doing the merge.  The longer you go between merges the more it costs to merge two branches together because of how far they diverge (makes sense when you think about it).  In the video they suggest practicing Continuous Integration and merging your code back to the mainline branch daily.  The suggestion from the video is to instead use feature/code toggling or branching by abstraction to get the same feature.  That way new features are only launched when you're ready for them.  It turns on that lots of people use this approach even Flickr. I really liked the blog post Experience Report: Feature Toggling by Sarah Taraporewalla explaining her experience with feature toggling.

The basic idea behind code toggling is very simple:

  1. Create a flag in your code for a new feature/change.
  2. As you add the new feature you wrap the new code in an if block so it's inaccessible if the feature isn't turned on.
  3. Turn the feature on in testing, production, x % of your servers.
  4. See if anything breaks.  If it does turn the feature back off.
  5. After the feature has been deployed for a long time (you'll have to determine what's best for your company) go back through and remove the toggle point and the old code.

It seems simple but really powerful.  I'm going to start looking into implementing it on one of my upcoming projects so hopefully there will be a future article on how that worked out.