Our Github workflow

Posted in: Development

We are only 10 months into adopting Github Enterprise for our version control system and have many things still to learn. Near the start of that period we needed a workflow for managing the contributions that our team of devs, designers and editors make to our projects.

We decided to have a look at what was out there first and adapt something to our needs, taking into consideration our relative inexperience with Git in general.

Pick one

This helpful guide by Atlassian to some workflows was good at giving us an intial overview. We were able to discount the various workflows for either being to complicated for us (Gitflow) or too basic (Forking workflow).

We looked at the Github Workflow as well and found it suitable for our level of experience and how we wanted to work.

Change it

There are a couple of minor things we do differently though in our team. First of all we don't work against a branch called master.

What we have instead are staging and production branches. These reflect our platforms that we deploy to. staging is actually the default branch of all our project repos.

We always branch from staging to work on our features. Our Pull Requests are for merging back into staging. We then merge into production from staging. This last bit is still a bit clunky as we have to issue another PR for that merge.

Push it

Salt n Peppa - Push It


The staging branch for a project deploys automatically. Changes to repos send triggers from Github to Bamboo (using the built in Bamboo Service Hook) to run build and deploy plans. For production we'd rather have control over when this happens. So while builds are still automatic for production, we manually trigger deployments at the push of a button.

We are using mina to push our apps to our servers, executed by Bamboo. Bamboo has an official Ruby plugin which we are using. This includes running Bundler tasks.

More polish?

What we have so far is a little bit rough still on some edges (the PR to production for example), but overall we are finding that this workflow model is working well.

This is not to say that as we gain more experience we won't revisit the various models of workflow in the future.

Posted in: Development


  • (we won't publish this)

Write a response