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.
Modified from Scott Chacon, with minor adjustments based on my preferences:
masterbranch is deployable
git checkout -b new-oauth2-scopes
git commit git checkout master git pull origin master git checkout new-oauth2-scopes git rebase master git push origin new-oauth2-scopes
git rebase master git checkout master git merge new-oauth2-scopes
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!