徐磊老师在 IDCF FDCC 认证公益训练营中提出，需求管理、配置管理、版本管理是研发管理的三大基石。而 Git 是当前最棒的版本控制系统，是事实的业界标准。可见熟悉 Git 操作, 设计合适的分支策略对于研发人员非常重要。

目前，已有很多文章介绍 Git 操作，也有很多文章介绍分支策略的选择。本文以华为云软件开发平台 DevCloud 为例，基于常见的研发场景，介绍分支策略和对应的操作方法，方便开发团队设计和实施适合自己的分支策略。其中一些示例参考徐磊老师的课程 IDCF 训练营 - DevOps 持续交付，徐磊老师在课程中详细介绍了分布式配置管理系统 Git 的特点和优势，以及如何为团队设计简单高效的配置管理策略（分支策略），推荐大家学习。

图1. IDCF 训练营 - DevOps 持续交付

开发库、受控库和产品库

开发库、受控库和产品库的提法可能来源于 CMMI V1.0 （或更早的版本）的一个配置管理系统的例子，然后就成了一些组织的过程资产，沿用至今。开发库是开发人员修改代码的地方，开发人员可以随意修改；受控库是测试版本代码存放的地方，需要开发组长提交测试申请修改；产品库是测试通过版本存放的地方，需要测试报告来驱动修改。

Examples of configuration management systems include the following:

Dynamic (or developer's) systems contain components currently being created or revised.
They are in the developer's workspace and are controlled by the developer.
Configuration items in a dynamic system are under version control.

Master (or controlled) systems contain current baselines and changes to them.
Configuration items in a master system are under full configuration management as described int ths process area.

Static systems contain archives of various baselines released for use.
Static systems are under full configuration management as described in this process area.

使用 Git 可以使用 dev, test 和 prod 三个分支分别对应开发库、测试库和产品库，而不需要建 3 个库 (repo)，这样通过简单的合并操作就可以实现从开发库到测试库、从测试库到开发库的代码复制，而且可以从合并记录中看出 3 个分支之间的关系。当然，作为分布式配置管理系统，每克隆一个新库，就相当于新建了一个或一组分支，如果建 3 个库，可以实现更严格的权限控制。

如果通过分支进行权限控制，打开 DevCloud , 进入要管理的代码仓库，在分支页签下建好所需的分支，然后在设置页签的仓库管理 » 保护分支管理菜单下，点击新建保护分支，按照提示进行操作，可以实现只允许管理员向这些分支提交/合并，也就实现了测试库和产品库受控。注意 DevCloud  保护分支管理界面中的合并指的是合并请求的批准权限，与 git-merge 并不是一回事。

图2. 保护分支管理

开发库、受控库和产品库看起来可以满足瀑布式开发的需要，在这种场景下，开发完成再测试，测试完成再进行生产发布，没有合并时的冲突。实际上，冲突会体现在 dev 分支上。即使是远端的中心仓库只有一个 dev 分支，但其实中心仓库的 dev 分支和开发人员本地仓库的 dev 分支并不是一回事，即使用的是同一个名字，并且有跟踪关系。

$ git checkout dev
Switched to a new branch 'dev'
Branch 'dev' set up to track remote branch 'dev' from 'origin'.

所以只要有团队中有多位开发人员，就可能出现合并时的冲突，也就需要开发团队对分支策略达成共识。在开发开始前，以及向中心仓库推送修改，及时拉取 dev 分支的最新改动，可以有效减少合并时的冲突。当然，减少冲突的根本还是应从管理粒度和工程解耦两方面考虑，这是徐磊老师在IDCF 训练营 - DevOps 持续交付中提出的研发效能提升的核心秘籍。

至于 test 和 prod 两个受控分支，因为只有被授权的配置管理员才能进行提交/合并操作，不太可能出现冲突，反而管理相对简单。如果 test 和 prod 两个受控分支不允许存在无关的提交记录，在从 dev 或 test 分支进行合并操作时，可使用 --squash 选项，然后再进行提交操作。当然如果使用 --squash, 从分支图谱上看不出两个分支之间的关系，最好使用标签功能在这几个分支上进行标记。而且在下一次使用这种方式进行合并时，虽然当前的 HEAD 指向的文件内容与被合并分支的某个父节点指向的的文件内容完全相同，但两者却是不同的提交，所以很可能会出现合并冲突，此时指定合并策略可以避免处理合并冲突的麻烦。

$ git checkout test
Switched to branch 'test'
Your branch is up to date with 'origin/test'.
$ git merge dev --squash --strategy-option=theirs
Auto-merging README.md
Automatic merge went well; stopped before committing as requested
Squash commit -- not updating HEAD
$ git commit -m "test-v2"
[test 8d9b6a4] test-v2
 1 file changed, 5 insertions(+)
$ git log --oneline --graph
* 8d9b6a4 (HEAD -> test) test-v2
* 0e9357a test-v1
* d226468 init
$ git push
...
Writing objects: 100% (3/3), 285 bytes | 285.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote:
remote: To create a merge request for test, visit:
remote:   https://codehub.devcloud.huaweicloud.com/codehub/nnnnnn/newmerge
...

如果对 git 命令行不熟悉，又没有熟悉的客户端工具支持较为复杂的合并选项，这些操作看起来有些复杂。所以如果不是执着于清除一些敏感（silly）的提交记录，使用 DevCloud 的合并请求可能更为有效。具体操作在后面的章节中会有介绍。

合并请求及评审

曾经有位同事说他们团队中的新人向代码仓库中提交的代码太乱，问能不能从服务器中撤销这些提交。虽然不是不可以，但撤销总是比较麻烦。对于有新人加入团队的情况，结对编程可能可以让新人快速融入团队，进行高质量的开发和提交。如果条件不具备，可以参考 Martin Fowler 写的 Reviewed Commits 这种分支模式，团队非核心人员提交的代码经过评审后，才能被合并到受控分支。这种分支模式可与特性分支结合使用，比如开发人员小王在开始一项工作任务时，首先基于现有的开发分支 dev 建立一个特性分支 feature-w2, 在开发完成后，拉取 dev 的最新提交合并入 feature-w2, 解决完可能出现的合并冲突，将 feature-w2 推送到中心仓库，然后发起从 feature-w2 向 dev 分支的合并请求。评审人收到合并请求后，进行代码审查和意见反馈。在评审通过后，具有权限的人员执行合并操作，并删除不再使用的分支 feature-w2。DevCloud 可以对这种模式提供很好的支持。

小王在将 feature-w2 推送到中心仓库时，会收到一个提示信息，内含为 feature-w2 新建合并请求的 URL 链接，详见上节 git push 的返回信息。打开此链接就可以在 DevCloud 中新建合并请求。在 DevCloud 代码仓库的合并请求页签下，可以查看现有的合并请求，也可以从此页面新建合并请求。

图3. 合并请求页签

图4. 新建合并请求

在新建合并请求的过程中, DevCloud 会检查准入条件，比如分支之间是否有差异，是否有冲突等。

图5. 新建合并请求详细信息

在新建合并请求页面，点击标题编辑框, DevCloud 会基于历史提交信息生成一个默认的标题，修改标题（可选），然后添加合并人和评审人（可选）后，单击确定按钮完成合并请求的创建。

评审人在合并请求页签下可以查看所有的合并请求，对选定的合并请求进行评论，包括其他评论信息和反馈信息、文件变更和提交记录，从而决定关闭或拒绝合并请求。合并人单击页面右上角的“普通合并” 或 “删除源分支合并” 完成合并操作。其中 “删除源分支合并” 很好地支持了短特性分支实践，可以避免留存过多不再使用的分支，减少混乱。

图6. 评审合并请求

Reviewed Commits 分支模式要求反馈要足够迅速，如果反馈时间过长，小王就可能需要重新回想原先进行的工作，而且可能会因为 dev 分支上有了新的提交，出现合并冲突，造成不必要的浪费。

（未完待续）