制定一套适合自己团队的GITflow标准化工作流

Git作为分布式代码管理的“当红炸子鸡”，被越来越多团队使用。当团队多个人员在同一个Git仓库上进行代码开发，没有一套标准化流程，将会引起代码管理的混乱，上线流程的迷茫，影响工作效率。制定一套适合自己团队的Gitflow标准化工作流势在必行！

 

 

写在前面的话

Git，作为分布式代码管理软件中的“当红炸子鸡”，被越来越多的开发人员在使用，也被越来越多的开发人员在赞美，是因为它杰出的“分布式”特性，大大方便了团队人员间互相合作。我们火锅管理系统最近也采用Git作为我们代码的管理软件。看着大家每天在Git仓库上建分支，拉代码，合代码，干得不亦乐乎，甚是感染。但是，分支一多，参与人员对Git的掌握程度不一致，难免会出现分支代码管理混乱，上线流程不清晰，从而影响开发效率。正所谓，有规则圆，有矩则方，没有规矩难成方圆。这就是为啥我们需要把Git工作流进行标准化处理，统一的拉分支规则，统一的上线流程，让整个团队所有人员按照统一的标准来干活，从而提高我们代码管理及其上线的效率。

目前的GIT Flow工作流

对Git工作流进行标准化处理咋们可并不是第一家。目前已经有很多人对Git工作流的标准化进行过处理。大概有以下几种：功能开发工作流，Gitflow工作流，Forking工作流，GitHub工作流等。下面我们主要介绍Gitflow工作流。

Git Flow工作流

Gitflow工作流是目前非常流行的一种比较成熟的工作流。该工作流的具体实例图形如下图所示。

如上图所示，我们可以看到，Gitflow工作流把整个代码分支分成了以下几种：Master分支，Hotfix分支，Release分支，Develop分支，Feature分支。各个分支的作用及其交互为：
        Feature分支：我们每当要迭代一个新功能，就需要来创建一个feature分支。该功能的所有代码都在该feature分支上维护。feature分支代码从Develop分支上拉取；并且，代码也会push回Develop分支；
        Develop分支：是我们的开发分支。所有的开发人员在一个迭代周期中，都是从develop分支去拉取代码，然后功能开发完成，就check in回develop分支。当某个迭代周期完成，我们需要从develop分支上把可以发布上线的功能拉取到Release分支进行上线；
        Release分支：当一个迭代周期完成，我们需要从develop分支拉取可以上线的功能到release分支。一旦release分支拉取功能确定，在上线之前，任何人都不可以再往release分支上提交代码。在release分支上进行提测，上线后，合并到master分支；
        Master分支：对应上线功能的代码版本，它是最稳定的代码分支。
HotFix分支：如果线上系统出现了bug，我们需要从master分支拉取一个新分支，也就是hotfix分支，在该分支上解决bug，并且校验bug，然后从该分支上线；

腾讯很多的团队都在采用Gitflow工作流。我们团队也想直接采用Gitflow工作流严格执行，但是我们团队有我们团队的特点，比如，我们没有一个固定的迭代周期，每个功能是直接分配给某一个人来单独开发，单独估计开发时间，单独上线，并且迭代周期很短；前端和后台的代码不在同一个Git仓库中来管理，是分开管理的。以上原因，导致如果我们严格采用Gitflow工作流，有些分支并不需要，有些冗余。针对以上情况，经过小组讨论，我们把gitflow工作流根据自己组的特定情况，更改为如下流程：具体如下图所示：

由于我们没有整体迭代周期的概率，每个功能都是分配给每个具体的人员，由每个具体的人员来分别估计工作时间，并单独开发，然后单独上线，所以，我们去掉了develop分支和release分支，但是增加了merge request过程来做代码review。具体流程如下：
        1）开发人员接到一个新功能需求开发，从master上拉取一个新功能分支，命名规则为：feature-XXX，其中，XXX为功能模块的名字，尽量通俗易懂；
        2）在本地Git仓库也创建一个feature-XXX分支，对应远程的feature-XXX分支。开发人员就在本地的feature-XXX分支上进行功能的开发；
        3）当功能开发完成，需要进行提测，提测之前，跟master分支进行一次代码合并，然后Push代码到远程的feature-XXX分支，在该分支上进行提测，上测试机，并进行问题的修复；
        4）当测试完成，进行预发布测试，从feature-XXX分支拉代码部署到预发布机，在线上环境进行校验，并进行问题的修复；
        5）预发布测试完成，开始提交merge request，做code review。然后，将代码从feature-XXX合并到master分支。
        6）从master分支将代码部署到灰度机器进行灰度，灰度完成没有问题，直接全量；发现问题，回退代码，到步骤5）重新进行；
        7）如果发现线上系统有bug，需要从master分支直接拉取一个bug fixing分支，在该分支上做bug fixing。bug fixing分支的命名规则：bugfixing-XXX-YYY,其中，XXX为功能名称，YYY为分支创建日期。例如：bugfixing-imageurl-0821。所有问题，都在bug fixing分支上修改，并且提测，预发布。当问题解决，准备上线，同理，提交一个merge request，做code review。然后合并代码回Master。在master分支上灰度，并全量上线；
        8）功能全量上线后，对应的分支即可删除。
        9）尽量不要重复用同一个分支来进行多个不同功能的开发，这样很容易让人引起误解。

写在后面的话

没有放之四海而皆准的真理，也没有完美无瑕的流程，只有适合自己团队的流程，才是合理的好流程。在上面流程中，我们没有固定的迭代周期，故而我们去掉了develop分支和release分支。但是，一旦我们的开发流程发生了改变，工作模式发生了变化，那么我们的Gitflow工作流也会随之进行调整。