The archive · Work & Ways of Doing · Technical decision · 2011
GitHub's 2011 GitHub Flow reduces branching to six rules; teams worldwide adopt it
Frustrated with git-flow's complexity, GitHub published its own six-step branch-and-deploy workflow in 2011 — simple enough that no helper script is needed.
GitHub
What it had to solve
By 2011 GitHub deployed to production several times a day, but the popular git-flow model was built around formal releases and needed a wrapper script to enforce it, which GUIs could not do.
How it works
In 2011 Scott Chacon, who taught Git professionally, kept hearing the same question: what did he think of git-flow? His honest answer became a work idea. git-flow was well tested but more complicated than most teams needed, and its wrapper script could only be enforced on the command line — exactly where the people who needed help were not.
GitHub itself did not use git-flow. The company deployed to production several times a day through a chat bot, so release-oriented branching made no sense. Chacon replaced it with six rules: master is always deployable, new work gets a descriptively named branch, pushes are constant, a pull request opens as soon as feedback is wanted, someone else must sign off before merging, and merging means deploying.
The idea caught on because it removed ceremony instead of adding it: branches became a visible TODO list, review became a conversation, and a one-line fix went through the same simple path as a two-week feature. GitHub's engineering blog linked the post the same day, and GitHub Flow spread far beyond GitHub as the default mental model for continuous-deployment teams.
Why it lands
- It solved a real pain: complexity that only experts could enforce
- It aligned process with the company's actual cadence of many daily deploys
- It made review a natural early step instead of a final gate
- It was published openly, so any team could copy it without buying anything
What it did
GitHub's own blog promoted the post the same day, and GitHub Flow grew into an industry-standard workflow still documented in GitHub's official docs for thousands of teams.
What you can take
Process simplicity is a feature: a workflow so light it needs no scripts or ceremony survives because people can follow it without being forced.
Since then
GitHub Flow became one of the most widely adopted development workflows of the decade; GitHub's documentation still describes it as the recommended flow, and books such as 'Git in Practice' cite Chacon's 2011 post as its origin. It also helped popularize the pull request as a collaboration tool inside companies, not just for open source.
Sources
spotted an error? The archive wants to know.
Your turn
You just read one. Describe the brief you are staring at, and see who has been given the same problem.
Free account · 3 free questions · no card