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

创意是什么Publish the simplest workflow that works: master stays deployable, work happens on short-lived branches reviewed via pull requests, and merging means deploying.脱胎换骨

当时的题目

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.

它是怎么成立的

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.

妙在哪

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

做出来什么

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.

可以借走的

Process simplicity is a feature: a workflow so light it needs no scripts or ceremony survives because people can follow it without being forced.

后来

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.

资料来源

发现哪里写错了？告诉我们。

轮到你了

你刚读完一个点子。把你手上的题目说出来，看看谁接过同样的题。

免费账号 · 3 次免费提问 · 不用绑卡