在使用Git Flow工作模式时，业界普遍遵循的规则：

• 所有开发分支从develop分支拉取。

• 所有hotfix分支从master分支拉取。

• 所有在master分支上的提交都必须要有标签，方便回滚。

• 只要有合并到master分支的操作，都需要和develop分支合并，保证同步。

• master分支和develop分支是主要分支，都是唯一的，其它派生分支每个类型可以同时存在多个。

4. GitHub Flow—探寻敏捷之道

随着软件行业竞争日益激烈，能更快更早的为用户提供新产品特性，俨然成为各企业渴望的核心竞争力之一，敏捷文化随之而生。

当项目经理们在学习、推进敏捷改革时，开发者们也在寻求更简洁的代码托管模式，此时“GitHub Flow”进入了开发者的视线，它上手简单，却非常适配敏捷开发环境，在中小型研发项目中，用“GitHub Flow”刚刚好。

它通常有一个主分支master，随时保持可部署状态，每个新特性或新特性集单独拉一条特性分支，例如feature_1/2/3...，在开发完成后直接在特性分支上进行测试，测试通过的特性分支经过分支合并评审（Merge Request，简称MR）后合并回 master 分支，此模式可以保证 master 分支随时都是可部署状态。

可见，“GitHub Flow”是以DevOps持续交付为中心的工作模式，使用“GitHub Flow”的团队在实际开发中甚至有一天之内会实施几十次部署的，而支撑这一切的，就是这个足够简洁的工作模式以及华为云的代码托管服务、自动化流水线服务。

图2 GitHub Flow工作模式

在使用GitHub Flow工作模式时，业界普遍遵循的规则：

• 让master分支总是保持可以部署的状态。

• 进行新特性或新特性集开发时要从master分支创建新的分支，新分支名称要具有描述性。

• 新特性分支的Commit一般在本地仓库进行，当需要合并回master分支时，推送到远程仓。

• 新特性分支合并回master分支前需要进行测试、评审与充分的交流，要确保合并后的master分支可用且经测试。

• 与master分支合并后，即可立即部署，使线上版本符合预期。

5. Trunk Based—归本固源

Git提供了分支这一开发策略后，各种基于分支的代码管理策略就如同雨后春笋般，纷纷被创造出来以应对各样的研发场景，如前文介绍到的适用于大型项目的Git Flow、适用于敏捷开发的GitHub Flow。

那么如果我是个人开发者，亦或者我们是两三人的小微团队，有没有适合我的Git工作模式呢？

当然有，它叫“Trunk Based”，与GitHub-Flow相同，它只有一条长期分支，叫做Trunk或者master即为主干，开发人员之间通过约定直接向被指定为主干的分支提交代码。“Trunk Based”是一种极简的开发模式，它主张一切开发活动都直接在主干分支完成，彻底根除了分支合并冲突的烦恼，并且项目中不会再有那些“你也说不上是干嘛的”分支存在了。因此在个人项目中，这该是最主流的开发模式了。

可以说“Trunk Based”回归了版本控制工具最本源的功能，很好理解也很好上手，对于项目的新进成员，导师不再需要培训复杂的分支定义，只需要告诉新来的“写好的代码记得Commit一下”。

当“Trunk Based”模式中项目需要发布版本时，可以单独拉出一条release分支，也可以直接在主干上发布。

没有了分支的代码隔离，测试和解决冲突都变得简单，同时也鼓励了项目成员进行更加频繁的代码集成和交互。

图3 Trunk Based工作模式

在DevOps环境中，为了保证正在部署的代码不会被Commit，请灵活使用“锁”，更多了解请前往华为云代码托管锁定代码仓库功能。