关于git:git-经验谈三团队分支管理

2次阅读

共计 1450 个字符，预计需要花费 4 分钟才能阅读完成。

这篇文章是 git 系列第三篇，想介绍一下团队分支的治理。在咱们的开发工作中，为了对流程进行更好的治理，更好地交付产品，应该充沛地利用分支这个性能。这里我想介绍一下本人认为比拟齐备的、通用的 git 分支管理策略。开始之前，要先阐明一下我认为的“通用”是针对什么样的开发流程的，它的特点如下：

有固定的迭代周期，个别是两周。
每个迭代完结后进行一次产品公布。迭代周期中不公布产品，除非是 hotfix / 紧急问题。
产品只有一个主版本。大多数基于 web 的产品都是这样的，不合乎这个条件的产品个别是针对不同客户、国家等条件同时保护着多个正式版本。

上面就列一个表格来说一下具体的分支划分：

分支名	阐明
`dev`	开发工作的主分支。迭代开始时，每个开发人员从这个分支创立本人开发工作的 feature 分支；迭代周期的开发工作完结时，用这个分支的代码进行产品公布。（你可能感觉从 dev 分支公布产品有点问题，我在前面做解释）
`master`	线上产品代码的分支。产品公布后，dev 分支的代码被 merge 到这个分支。当线上呈现紧急问题，须要进行 hotfix 时，从这个分支创立 hotfix 分支。
`f_xxx`	以“f_”结尾的开发工作分支，也叫 feature 分支。从 dev 分支创立，开发工作实现后 merge 到 dev 分支。
`hotfix_xxx`	以“hotfix_”结尾的 hotfix 分支。从 master 分支创立；通过公布此分支修复线上紧急问题。问题修复后，要把以后 hotfix 分支的代码 merge 到 master 和 dev 分支。

依据表格中的形容，理论开发中的 git 流程会是这个样子：

那么依照这个治理形式，测试是如何进行的呢？首先是随着 feature 分支的开发实现，测试工程师在 dev 分支上进行对应的功能测试；hotfix 的测试要在 hotfix 分支上进行，不能在合并后的 dev 分支上进行；feature 分支和 hotfix 分支都合并到 dev 分支后在 dev 分支进行针对用户体验和产品流程的测试。

最初，产品 / 紧急修复公布后，别忘了在 master 分支打 tag。

这个治理形式有一个问题，那就是没有预公布分支（release），或者说开发分支和预公布分支没有离开，只用了一个 dev 分支。下面表格的括号中要解释的也是这个问题。应用 release 和 dev 分支离开的形式有以下劣势：

把针对性能的测试和针对操作流程的测试隔离开
dev 分支的代码合并到 release 分支后能够更早地用于后续的开发工作

我为什么没有选用 dev 和 release 拆散的形式呢？一方面我对以上两个劣势没有强烈的需要，另外就是这样做须要频繁地合并代码，太麻烦了。结构复杂的产品和对测试工作投入较大的团队会因为劣势 1 而抉择 dev / release 拆散。如果想理解 dev / release 拆散的形式具体是怎么工作的，能够参考这篇攻略：Git 分支治理最佳实际，我就不在这里 copy 了。实际上这是一个老外提出的经典的版本控制系统工作模式，大而强，且麻烦 … 原文在这里：A successful Git branching model。

我这篇文章提出的分支管理策略是依据本人的实际经验总结的，能满足根本的要求。但这也只是个通用的模板，如何制订团队的 git 分支治理应该依据本人的具体情况而定，产品状态、团队人员配置都会影响到版本控制系统的应用。谢谢浏览，欢送提出你的认识！

本文的原文链接：git 经验谈（三）：团队分支治理