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.
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.
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
What we have instead are
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
staging. This last bit is still a bit clunky as we have to issue another PR for that merge.
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.
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.