代码分支管理方式讨论

现在，我们想象一个场景，公司准备发展一项新的业务，决定你作为研发负责人，开发一套系统，现在系统只有一个主干分支(master)
因为是新的分支，你和你的两个小伙伴就直接在master分支上进行开发了，公司也给了一台服务器，用作系统的开发环境(开发环境-master分支)

分支	用途
master	开发

开发一段时间后，部分功能已符合提测的要求，需要进行提测，但是你们开发还在继续中，所以决定在master拉取分支test提供给测试，公司又拨了一台服务器，用于部署测试环境(测试环境-test分支)

分支	用途
master	开发
test	测试

开发还是在master分支，功能达到自测标准后，合并至test分支进行提测，测试提出bug，先在master进行修改，自测通过再合并至test分支，这样，直到公司签了第一个客户

客户需要部署哪个分支呢？现在已知test分支已测试通过，master分支上存在开发但未测试的代码。经过你深思熟虑，你给test分支加上版本号1.0，拉取一个分支叫formal-1.0，客户部署formal-1.0版本

分支	用途
master	开发
test	测试
formal-1.0	部署

客户对formal-1.0的功能基本满意，但是还是提出了一些优化需求，且比较紧急，你和你的两个小伙伴也被拉去现场出差，领导要求尽快解决客户需求，原来在master分支开发的功能，可以延后开发。很不幸，这期间，你们又合并了一些自测好的功能到test分支。
你当机立断，做出如下部署：
将客户需求进行归类处理，关联性强的进行合并，最后总结出6个合并后的需求，你分别从formal-1.0拉出“dev-20240307-需求名称”6个分支进行开发，拉出formal-1.0-devmain分支，进行开发自测，使用原开发环境服务器(原master开发暂停)
为什么分六个分支进行开发？方便进行合并分支。
奋战两个工作日，你们小团队六个需求均开发完成，合并至test分支，测试经过测试，4个需求验证通过，2个还有瑕疵，为了给客户交代(体现出重视)，决定将4个需求上线，将验证通过的四个分支“dev-20240307-需求名称”合并至formal-1.0，版本修改为formal-1.1，发布至预发环境(客户提供预发和正式两套环境)，测试在客户预发环境进行回归测试，如有问题，立马解决，奋战到晚上12点，终于讲4个需求上线。
次日，客户知道后，验证了四个新需求，基本满足，很高兴，又提了几个小建议，并提出下周三要培训，上次的两个问题和这次的几个需求，都要有。
下午一点，你和产品碰了下头，把客户需求进行归类，又梳理出5个需求，其中4个，能够在下周一开发完，还有一个改动复杂，无法及时完成，由产品和客户沟通后，要求在试运营前做好就行。
所以，又拉出5个开发分支，在下周三之前，出较复杂那个需求外，均测试通过，经过预发环境验证，成功上线。培训时，操作员提建议，领导查看时，也提出建设性建议，终于在运营之前，达到基本的运营标准，此时版本迭代至formal-1.9版本。

分支	用途
master	开发（暂停）
test	测试
formal-1.0	部署
dev-日期-需求名	开发(一次性)

带着你对客户“有问题及时联系我”的承诺，你和俩小弟出差旅程结束了，客户的迭代还是要继续的

刚回公司，领导带来一个好消息，又有两家客户签合同了，让你尽快给客户先部署一个版本上去，经过深思熟虑，你做出决断，master开发彻底暂停，将在客户现场开发的数十个“dev-日期-需求”的分支全部合并至test分支，进行测试，因需求已上线，故测试较顺利
测试通过后，拉取formal分支，版本定位2.0，发布至两家客户现场
现在分支如下：测试分支test、正式分支formal部署至B\C两家客户，正式分支formal-1.0部署至A客户、分支master(存在部分已开发未提测需求，万一后续要改，至少可以用来复制代码)、开发自测分支formal-1.0-devmain(可暂时不用)、数十个开发分支(均可删除)
其中测试分支test和正式分支formal包含需求一致，正式分支formal-1.0缺少部分需求(这些需求A客户均未提及要用)

做出如下规定：
1、formal为正式分支，每次打版后，均拉出新正式版本，版本为formal2.x.0(x自增)
2、代码只有一套，客户需求，经评审确定为普遍需求，还是特殊需求，如为特殊需求，需要在代码中进行参数控制
3、每次新需求，均从formal拉出开发分支“dev-日期-需求名”(尽量细分)，自测成功后，合并至test分支提测，提测成功后，合并至formal(在打版日合并，并当日进行回归测试)
4、客户A择机更新为formal的最新版本，新客户，均部署最新正式版本
5、一般情况客户升级，均升级为最新正式版本，如有紧急修改或客户坚持，可将开发分支合并至，客户当时版本，并进行修改版本(如客户现为formal2.5.2版本，合并开发分支，版本定位formal2.5.3)，如极为紧急且有把握，由负责人直接修改当前正式分支，修改版本后发布，并在现场验证通过后，合并至formal主干

分支	用途
formal	主干
test	测试
formal-2.x.0	部署(陆续迭代)
dev-日期-需求名	开发(一次性)

以上其实就是我在之前公司的规范，即有正式、测试双线，按需求拉分支，从正式拉取，在测试分支测试，测试通过合并至正式分支，优势如下：
1、迭代快，只要有一个需求测试通过，即可发现场，最紧急时候，每天一个版本
2、未测试通过需求，可以延期发布，不影响其他需求
不足：
1、每个分支基本都只能一个人开发，不然容易混乱，如果需求拖延很久，合并时冲入较多
2、可能出现两个需求开发后发现，A需求依赖B需求，此时处理起来麻烦
3、重复测试，正式分支还要进行回归测试，不过还好，一般问题较少

现在公司的规则如下
1、主干分支mater，所有需求先在master开发
2、每月一次发布新版，封版时间约在发布时间前10天，封版即拉出分支，如formal-1.1.0版本，所以封版后的需求，必须在这十天内测试通过，如未能通过，则延期发布或进行回滚
3、一般客户更新，在自己原版本上进行迭代，如：formal-1.1.0迭代至formal-1.1.5
4、一般需求在主干版本验证通过后再合并至分支版本，如客户十分紧急，可先在分支版本测试发布
5、客户版本一般也不会特别多，都会有几个较稳定的版本
以上规则优势如下：
1、同一个需求可以切分成很多小任务，多人一起开发
2、测试只需要测试一次，测试通过即把当前分支发版
不足：
1、上述说的，如果需求就是测试失败，改不好，就只能延期或者回滚
2、迭代慢，很难迅速开发多个需求

出现以上区别，也是有原因的，前一种情况，同时开发不会超过4个，基本都是功能性需求
后一种情况，系统较为稳定，经常会有批量型修改(问题不难，类似东西改好多)，可分多人进行