独到见解

Git工作流程(阮一峰完整总结版本，各流程变化，且有独到

见解)

Git作为一个源码管理系统，不可避免涉及到多人协作。

协作必须有一个规范的工作流程，让大家有效地合作，使得

项目井井有条地发展下去。"工作流程"在英语里，叫做

"workflow"或者"flow"，原意是水流，比喻项目像水流那样，

顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。

本文介绍三种广泛使用的工作流程：

Gitflow

Githubflow

Gitlabflow

如果你对Git还不是很熟悉，可以先阅读下面的文章。

《Git使用规范流程》

《常用Git命令清单》

《Git远程操作详解》

一、功能驱动

本文的三种工作流程，有一个共同点：都采用"功能驱动式开

发"（Feature-drivendevelopment，简称FDD）。

它指的是，需求是开发的起点，先有需求再有功能分支

（featurebranch）或者补丁分支（hotfixbranch）。完成开

发后，该分支就合并到主分支，然后被删除。

二、Gitflow

最早诞生、并得到广泛采用的一种工作流程，就是Gitflow。

2.1特点

它最主要的特点有两个。

首先，项目存在两个长期分支。

主分支master

开发分支develop

前者用于存放对外发布的版本，任何时候在这个分支拿到的，

都是稳定的分布版；后者用于日常开发，存放最新的开发版。

其次，项目存在三种短期分支。

功能分支（featurebranch）

补丁分支（hotfixbranch）

预发分支（releabranch）

一旦完成开发，它们就会被合并进develop或master，然后

被删除。

Gitflow的详细介绍，请阅读我翻译的中文版《Git分支管

理策略》。

2.2评价

Gitflow的优点是清晰可控，缺点是相对复杂，需要同时维

护两个长期分支。大多数工具都将master当作默认分支，

可是开发是在develop分支进行的，这导致经常要切换分支，

非常烦人。

更大问题在于，这个模式是基于"版本发布"的，目标是一段

时间以后产出一个新版本。但是，很多网站项目是"持续发布

"，代码一有变动，就部署一次。这时，master分支和develop

分支的差别不大，没必要维护两个长期分支。

三、Githubflow

Githubflow是Gitflow的简化版，专门配合"持续发布"。它

是使用的工作流程。

3.1流程

它只有一个长期分支，就是master，因此用起来非常简单。

官方推荐的流程如下。

第一步：根据需求，从master拉出新分支，不区分功能分

支或补丁分支。

第二步：新分支开发完成后，或者需要讨论的时候，就向

master发起一个pullrequest（简称PR）。

第三步：PullRequest既是一个通知，让别人注意到你的请

求，又是一种对话机制，大家一起评审和讨论你的代码。对

话过程中，你还可以不断提交代码。

第四步：你的PullRequest被接受，合并进master，重新

部署后，原来你拉出来的那个分支就被删除。（先部署再合

并也可。）

3.2评价

Githubflow的最大优点就是简单，对于"持续发布"的产品，

可以说是最合适的流程。

问题在于它的假设：master分支的更新与产品的发布是一致

的。也就是说，master分支的最新代码，默认就是当前的线

上代码。

可是，有些时候并非如此，代码合并进入master分支，并

不代表它就能立刻发布。比如，苹果商店的APP提交审核

以后，等一段时间才能上架。这时，如果还有新的代码提交，

master分支就会与刚发布的版本不一致。另一个例子是，有

些公司有发布窗口，只有指定时间才能发布，这也会导致线

上版本落后于master分支。

上面这种情况，只有master一个主分支就不够用了。通常，

你不得不在master分支以外，另外新建一个production分

支跟踪线上版本。

四、Gitlabflow

Gitlabflow是Gitflow与Githubflow的综合。它吸取了

两者的优点，既有适应不同开发环境的弹性，又有单一主分

支的简单和便利。它是推荐的做法。

4.1上游优先

Gitlabflow的最大原则叫做"上游优先"（upsteamfirst），即

只存在一个主分支master，它是所有其他分支的"上游"。只

有上游分支采纳的代码变化，才能应用到其他分支。

Chromium项目就是一个例子，它明确规定，上游分支依次

为：

LinusTorvalds的分支

子系统（比如netdev）的分支

设备厂商（比如三星）的分支

4.2持续发布

Gitlabflow分成两种情况，适应不同的开发流程。

对于"持续发布"的项目，它建议在master分支以外，再建立

不同的环境分支。比如，"开发环境"的分支是master，"预发

环境"的分支是pre-production，"生产环境"的分支是

production。

开发分支是预发分支的"上游"，预发分支又是生产分支的"上

游"。代码的变化，必须由"上游"向"下游"发展。比如，生产

环境出现了bug，这时就要新建一个功能分支，先把它合并

到master，确认没有问题，再cherry-pick到pre-production，

这一步也没有问题，才进入production。

只有紧急情况，才允许跳过上游，直接合并到下游分支。

4.3版本发布

对于"版本发布"的项目，建议的做法是每一个稳定版本，都

要从master分支拉出一个分支，比如2-3-stable、2-4-stable

等等。

以后，只有修补bug，才允许将代码合并到这些分支，并且

此时要更新小版本号。

五、一些小技巧

5.1PullRequest

功能分支合并进master分支，必须通过PullRequest（Gitlab

里面叫做MergeRequest）。

前面说过，PullRequest本质是一种对话机制，你可以在提

交的时候，@相关人员或团队，引起他们的注意。

5.2Protectedbranch

master分支应该受到保护，不是每个人都可以修改这个分支，

以及拥有审批PullRequest的权力。

Github和Gitlab都提供"保护分支"（Protectedbranch）这

个功能。

5.3Issue

Issue用于Bug追踪和需求管理。建议先新建Issue，再新

建对应的功能分支。功能分支总是为了解决一个或多个

Issue。

功能分支的名称，可以与issue的名字保持一致，并且以

issue的编号起首，比如

"15-require-a-password-to-change-it"。

开发完成后，在提交说明里面，可以写上"fixes#14"或者

"clos#67"。Github规定，只要commitmessage里面有

下面这些动词+编号，就会关闭对应的issue。

clo

clos

clod

fix

fixes

fixed

resolve

resolves

resolved

这种方式还可以一次关闭多个issue，或者关闭其他代码库

的issue，格式是urname/repository#issue_number。

PullRequest被接受以后，issue关闭，原始分支就应该删

除。如果以后该issue重新打开，新分支可以复用原来的名

字。

5.4Merge节点

Git有两种合并：一种是"直进式合并"（fastforward），不生

成单独的合并节点；另一种是"非直进式合并"（none

fast-forword），会生成单独节点。

前者不利于保持commit信息的清晰，也不利于以后的回滚，

建议总是采用后者（即使用--no-ff参数）。只要发生合并，就

要有一个单独的合并节点。

5.5Squash多个commit

为了便于他人阅读你的提交，也便于cherry-pick或撤销代码

变化，在发起PullRequest之前，应该把多个commit合并

成一个。（前提是，该分支只有你一个人开发，且没有跟

master合并过。）

这可以采用reba命令附带的squash操作，具体方法请参

考我写的《Git使用规范流程》。

（完）