We’ve been using Git for quite a while now. We don’t have a single SVN repository. This makes for happy developers!

For a while we’ve been using Git Flow as our preferred workflow. It’s been pretty good, certainly from the point of having some sort of a recognised workflow/process. The only problem is, it’s turned out to be a bit heavyweight for what we want.

We love agile development, and for us, this means:

  • Short sprints of development
  • Regular releases (minimising serious issues)
  • Flexibility to experiment and throw away bad ideas
  • Team spirit and collaboration

The problem with git flow is it’s far better suited to a fairly fixed release cycle. We’ve found the release mechanism is cumbersome for quick/regular releases, and… it’s all a bit heavyweight for the entire team. We want all of our team to feel they can commit and contribute without feeling they might break something in the process. We also want to encourage communication, collaboration and experimentation!

So, the solution is, we’ve simpleweb.co.ukitched to Github Flow way of working. So what is it? The basic principles are this (stolen from http://scottchacon.com/2011/08/31/github-flow.html):

  • Anything in the master branch is deployable
  • To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
  • Commit to that branch locally and regularly push your work to the same named branch on the server
  • When you need feedback or help, or you think the branch is ready for merging, open a pull request
  • After someone else has reviewed and signed off on the feature, you can merge it into master
  • Once it is merged and pushed to ‘master’, you can and should deploy immediately

Here’s an excellent presentation that explains it:

What about clients reviewing code before it might be production ready? Well, we simply push a given feature branch to our stage server. If two developers are working on a separate feature branch, they can either merge each other’s feature branches or create a new shared branch for the purpose of a client reviewing code.

We’ve dropped all our develop branches and the team have been merrily discussing pull requests and getting stuff done. So far so good, we are liking the shift a lot.

Related Stories