【Git】关于分支策略的一些思考

Love The Way You Lie 2021-12-13 13:25 328阅读 0赞

**【引言】**

在正文之前，先给大家抛一个问题，自己所在公司上线的分支是如何规划和管理的？可以在脑海中梳理一下。

不同的团队，有着不同的管理方式。开发过程中，对于分支的管理也有不同的策略；上线过程中，也有不一样的流程。

本篇博客内容就结合自己工作以来，所在团队管理方式的经验，来分享一下不同的分支策略，对比看看各有着什么样的优缺点，而自己所在团队，究竟更适合于哪种策略，可以想想，在此给大家一个参考。

**【说明】**

在介绍分支策略之前， 先说明一下分支的命名规范，几家公司都是类似的，也就是下面博客内容中会提及到的新需求或bug独立分支的命名规范。

如果是新需求，以feature\_需求编号\_日期格式命名；如果是测试通过后，在预发环境发现的bug，以bugfix\_需求编号\_日期格式命名；如果是生产环境的bug，以hotfix\_需求编号\_日期格式命名。

**【分支策略一】**

*  分支

持久化分支两个，develop和master。新需求或bug独立分支开发。

*  环境

develop代码对应测试环境，master代码对应生产环境。

*  流程

在需要开发新需求或改bug的时候，从master拉分支，在新拉的分支上开发需求或解决bug。开发自测完成，将分支代码合并到develop，develop测试完成，将develop代码合并到master.

*  优点

此种分支策略管理简单，工作量小，快速地保证了开发部署的持续性与集成性。

*  问题

各自分支的代码都合并到develop分支，但可能因为需求变更或测试出问题，短时间内解决不了，就直接影响到了上线。因为此时的develop分支是有问题的分支，不解决问题就无法将代码合并到master分支，就会导致其他人开发没问题的分支代码也需要等到有问题的分支代码解决了才能一同上线。

*  冲突

在团队开发过程中，提交代码难免会有冲突。而在此种分支策略下，解决冲突的方式都是直接将develop分支的代码拉取到自己分支上，解决后重新提交。

*  使用

此种分支策略是自己在小公司小团队中的使用经验，迭代更新要求快，开发四五个人左右。测试环境合并代码也不发起请求，开发自己合并，上线一般由运维或开发负责人合并。

**【分支策略二】**

*  分支

持久化分支两个，develop和master。新需求或bug独立分支开发。

*  环境

develop代码对应测试环境，master代码对应预发环境和生产环境。

*  流程

在需要开发新需求或改bug的时候，从master拉分支，在新拉的分支上开发需求或解决bug。开发自测完成，将分支代码合并到develop，develop测试完成，将自己分支的代码合并到master.

*  优点

主干master代码是稳定的，只有在测试环境和预发环境测试通过，才能将自己分支代码合并。在团队开发过程中，每个人的任务上线互不影响，因为不再通过develop分支代码合并。

*  问题

此种分支策略问题在于合并代码，不仅需要和develop合并一次，还需要和master合并一次，可能两次合并过程中自己分支的代码有不同，也可能合并有冲突，两次解决冲突选择的也不同。

*  冲突

刚进入公司，使用的是之前公司解决冲突的方式，但其实这样的解决冲突的方式，就使得自己的分支代码不干净了，就不能直接上线master。所以公司采用的是git的cherry-pick命令，这样就可以避免整个分支代码的合并，而挑选自己需要合并的代码进行合并。

*  使用

此种分支策略同样是自己在小公司小团队中的使用经验，合并代码也不需要发起请求，直接合并到develop和master。

**【分支策略三】**

*  分支

持久化分支：develop、releases、master。新需求或bug独立分支开发。

*  环境

develop代码对应测试环境，releases代码对应预发环境，master分支代码对应生产环境。

*  流程

在需要开发新需求或改bug的时候，从master拉分支，在新拉的分支上开发需求或解决bug。开发自测完成，将分支代码合并到develop。在上预发环境，运维从master分支拉取一个作为releases，将没问题的分支合并到该releases分支。预发环境测试通过，最后上线前，运维将可以上线的开发分支合并至master.此分支策略也称为gitflow.

*  优点

通过合并请求以及运维人员的参与，可以很大程度上保证线上环境的稳定。

*  问题

合并代码同样也是该分支策略的问题，从测试-预发-生产环境，整个过程需要合并三次，如果有冲突，也意味着要解决三次，这样不仅就导致了很大程度上的重复性工作，无疑增加了开发与运维人员工作量。另外，预发和测试环境，上线前，开发通知运维，最后统一上线就要求运维保证上线分支，没有遗漏的，也没有多余的。

*  冲突

若存在冲突，是不能直接将develop或master代码拉取到本地分支的，还是之前说过的，这样导致自己分支代码不干净，从而上线时没有一个完整干净的分支可以合并。所以，解决冲突，是需要单独拉取develop或master分支到本地，将自己分支代码合并到此分支，解决冲突后，提交，这样就能保证自己分支代码是干净的。

*  使用

此种分支策略是自己在大公司大团队中开发的使用经验，对于开发来说，需要做的事就是拉取自己的分支，在解决完冲突的前提下提交合并develop代码，也就是测试环境的代码是开发自己可以经手的。预发和生产环境的代码合并工作，都交由专门的运维负责。

**【分支策略四】**

*  分支

持久化分支一个master。新需求独立分支开发。

*  环境

master分支代码对应测试环境，releases代码对应预发环境和生成环境。

*  流程

在需要开发新需求的时候，从master拉取一个分支作为自己的需求分支，自测通过后，合并代码到master分支，进行测试。测试通过后，就从master分支上拉取releases分支在pre环境上测试，在releases分支上测出的bug，直接从releases上拉取新分支进行修改，修改完成后，将代码合并回master分支；最后直接将releases分支代码上线即可。

*  优点

减少了分支策略三中重复合并代码，解决冲突的问题，在保证了稳定性的同时也减少了很大的工作量。

*  问题

此种策略也会有分支策略一中提及的问题，若是有问题的分支或者提交了又确定不上线的分支已经合并至master分支，这个时候上线的代码就增加了很大的不确定性。但此问题可以通过合并请求处理，不需要上线分支的合并请求可以使用revert进行还原，或者在大多数分支出现问题的情况下，可以重新拉取master分支作为替换。

*  冲突

解决冲突的方式和分支策略三中提到的方式一致，禁止将master代码拉取到自己的分支，从而导致自己分支的污染。

*  使用

此种分支策略也是大公司大团队中开发的使用经验，流程上具有一定的约束性，但也保证了一定的灵活性，从而避免了团队开发、项目上线过程中的各种问题，提高了一定的管理效率。

**【总结】**

上面简述的几种分支策略，都是自己在不同团队中不同管理方式下的经验总结，每一种方式都有各自的优点及问题。就实际工作中来说，还是需要根据自己的团队制定合适自己的管理策略，在保证稳定性的前提下，也需要提升其灵活性，从而高效开发。