Git 协做流程

Git 协做流程5

 

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

协做必须有一个规范的流程，让你们有效地合做，使得项目层次分明地发展下去。"协做流程"在英语里，叫作"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、天然地向前流动，不会发生冲击、对撞、甚至漩涡。

本文介绍三种普遍使用的协做流程：

• Git flow

• Github flow

• Gitlab flow

若是你对Git还不是很熟悉，能够先阅读下面的文章。

• 《Git 使用规范流程》

• 《经常使用 Git 命令清单》

• 《Git 远程操做详解》

所有回复

实验楼管理员 L64

1、功能驱动

本文的三种协做流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。

它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，而后被删除。

2、Git flow

最先诞生、并获得普遍采用的一种协做流程，就是Git flow 。

2.1 特色

它最主要的特色有两个。

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

• 主分支master

• 开发分支develop

前者用于存放对外发布的版本，任什么时候候在这个分支拿到的，都是稳定的分布版；后者用于平常开发，存放最新的开发版。

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

• 功能分支（feature branch）

• 补丁分支（hotfix branch）

• 预发分支（release branch）

一旦完成开发，它们就会被合并进develop或master，而后被删除。

Git flow 的详细介绍，请阅读我翻译的中文版《Git 分支管理策略》。

2.2 评价

Git flow的优势是清晰可控，缺点是相对复杂，须要同时维护两个长期分支。大多数工具都将master看成默认分支，但是开发是在develop分支进行的，这致使常常要切换分支，很是烦人。

更大问题在于，这个模式是基于"版本发布"的，目标是一段时间之后产出一个新版本。可是，不少网站项目是"持续发布"，代码一有变更，就部署一次。这时，master分支和develop分支的差异不大，不必维护两个长期分支。

2015-12-25 15:05

实验楼管理员 L64

3、Github flow

Github flow 是Git flow的简化版，专门配合"持续发布"。它是 Github.com 使用的协做流程。

3.1 流程

它只有一个长期分支，就是master，所以用起来很是简单。

官方推荐的流程以下。

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

第二步：新分支开发完成后，或者须要讨论的时候，就向master发起一个pull request（简称PR）。

第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，你们一块儿评审和讨论你的代码。对话过程当中，你还能够不断提交代码。

第四步：你的Pull Request被接受，合并进master，从新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）

3.2 评价

Github flow 的最大优势就是简单，对于"持续发布"的产品，能够说是最合适的流程。

问题在于它的假设：master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上代码。

但是，有些时候并不是如此，代码合并进入master分支，并不表明它就能马上发布。好比，苹果商店的APP提交审核之后，等一段时间才能上架。这时，若是还有新的代码提交，master分支就会与刚发布的版本不一致。另外一个例子是，有些公司有发布窗口，只有指定时间才能发布，这也会致使线上版本落后于master分支。

上面这种状况，只有master一个主分支就不够用了。一般，你不得不在master分支之外，另外新建一个production分支跟踪线上版本。

2015-12-25 15:05

实验楼管理员 L64

4、Gitlab flow

Gitlab flow 是 Git flow 与 Github flow 的综合。它吸收了二者的优势，既有适应不一样开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的作法。

4.1 上游优先

Gitlab flow 的最大原则叫作"上游优先"（upsteam first），即只存在一个主分支master，它是全部其余分支的"上游"。只有上游分支采纳的代码变化，才能应用到其余分支。

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

• Linus Torvalds的分支

• 子系统（好比netdev）的分支

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

4.2 持续发布

Gitlab flow 分红两种状况，适应不一样的开发流程。

对于"持续发布"的项目，它建议在master分支之外，再创建不一样的环境分支。好比，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。

开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。好比，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。

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

4.3 版本发布

对于"版本发布"的项目，建议的作法是每个稳定版本，都要从master分支拉出一个分支，好比2-3-stable、2-4-stable等等。

之后，只有修补bug，才容许将代码合并到这些分支，而且此时要更新小版本号。

2015-12-25 15:06

实验楼管理员 L64

5、一些小技巧

5.1 Pull Request

功能分支合并进master分支，必须经过Pull Request（Gitlab里面叫作 Merge Request）。

前面说过，Pull Request本质是一种对话机制，你能够在提交的时候，@相关人员或团队，引发他们的注意。

5.2 Protected branch

master分支应该受到保护，不是每一个人均可以修改这个分支，以及拥有审批 Pull Request 的权力。

Github和Gitlab 都提供"保护分支"（Protected branch）这个功能。

5.3 Issue

Issue 用于 Bug追踪和需求管理。建议先新建 Issue，再新建对应的功能分支。功能分支老是为了解决一个或多个 Issue。

功能分支的名称，能够与issue的名字保持一致，而且以issue的编号起首，好比"15-require-a-password-to-change-it"。

开发完成后，在提交说明里面，能够写上"fixes #14"或者"closes #67"。Github规定，只要commit message里面有下面这些动词 + 编号，就会关闭对应的issue。

• close

• closes

• closed

• fix

• fixes

• fixed

• resolve

• resolves

• resolved

这种方式还能够一次关闭多个issue，或者关闭其余代码库的issue，格式是username/repository#issue_number。

Pull Request被接受之后，issue关闭，原始分支就应该删除。若是之后该issue从新打开，新分支能够复用原来的名字。

2015-12-25 15:06

实验楼管理员 L64

5.4 Merge节点

Git有两种合并：一种是"直进式合并"（fast forward），不生成单独的合并节点；另外一种是"非直进式合并"（none fast-forword），会生成单独节点。

前者不利于保持commit信息的清晰，也不利于之后的回滚，建议老是采用后者（即便用--no-ff参数）。只要发生合并，就要有一个单独的合并节点。

5.5 Squash 多个commit

为了便于他人阅读你的提交，也便于cherry-pick或撤销代码变化，在发起Pull Request以前，应该把多个commit合并成一个。（前提是，该分支只有你一我的开发，且没有跟master合并过。）

这能够采用rebase命令附带的squash操做，具体方法请参考我写的《Git使用规范流程》。

做者：阮一峰

文章地址：http://www.ruanyifeng.com/blog/2015/12/git-workflow.html

2015-12-25 15:07