The Ever-Deployable Github Workflow

Scott Chacon from Github wrote a post describing the workflow that Github uses internally to manage projects, and I found that it cleared some issue up for some projects that I’ve been working on, specifically, how to keep your project deployable.

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day – often several times a day.

His article describes a workflow based on working in branches and using pull requests before merging into master. I’ve used pull requests before, of course, but never thought to use them internally on a project.

Because I have a couple teams that this workflow would help, and because I tend to like rebasing on branches instead of merging, I thought I’d describe my slightly modified workflow in my own words as a way to formalize it for my teams.

Github Workflow

Modified from Scott Chacon, with minor adjustments based on my preferences:

  • Anything in the master branch is deployable
  • To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
git checkout -b new-oauth2-scopes
  • Commit locally and rebase your branch to master regularly. Push your branch to the server often- so we all know what’s being worked on
git commit
git checkout master
git pull origin master
git checkout new-oauth2-scopes
git rebase master
git push origin new-oauth2-scopes
  • 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 rebase the branch to master, then merge it into master
git rebase master
git checkout master
git merge new-oauth2-scopes
  • By rebasing your branchto master, you put all of your changes on top of the master branch. This allows your commits to be grouped (not interwoven by date), reduces the ubiquitous (merge) commit to something that never needs to be explored, pushes all requirement to fix merge conflicts onto the branch, and always results in a clean merge to master.
  • Once it is merged and pushed to ‘master’, you can and should deploy immediately


I really like the Github mentality of having the master branch always deployable. It forces good development practice in so many ways. I also love the idea of using pull requests to have an at least cursory code review before merging that code into master. Finally, I like the idea of pushing all the branches to the server- although I’ve always been hesitant to do that before. It always seemed like it was making things messy, but as Scott points out, it gives an easy way to look at, and track, what’s being worked on.

This Github workflow is my new “gold standard” for development. Thanks Scott!

3 thoughts on “The Ever-Deployable Github Workflow”

Comments are closed.