摘要：团队的研发本质不是团队规模越大，研发效率就越高；相反随着团队规模的扩大，反而逐渐增加项目的管理成本，协作成本也越来越高，代码冲突变多，导致研发效率越来越慢。
团队的研发本质不是团队规模越大，研发效率就越高；相反随着团队规模的扩大，反而逐渐增加项目的管理成本，协作成本也越来越高，代码冲突变多，导致研发效率越来越慢。
测试过程中，是否有出现过以下情况：
1、已修复的bug，某次更新后又复现
2、某些问题仅在UAT环境上出现，测试环境却没有
3、同一个项目的不同版本，代码相互覆盖，导致测试进度受阻
软件交付过程，本质是开发者围绕代码库的写作过程。无论是产品代码、配置、环境和发布流程，都可以通过代码来描述，并保存到代码库里。因此，研发模式的目的就是约束我们在围绕代码库工作时的行为，本质是一种围绕代码库的行为约束。
作为测试人员，了解并熟悉代码分支管理，协助研发搭建代码分支的管理规范，有利于提升研发的工作效率，帮助测试人员控制测试范围，制定对应的测试策略，促进整体测试质量的提升。
分支其实就有点像一个树的枝杈，每个分支上可以有不同的文件的版本，并且不会互相干扰。
分支功能有什么用？在工作中，我们经常是需要和别人一起开发一个项目的，此时可能你开发A功能，别人开发B功能；如果只有一个分支的话，那么所有人都得在这个分支上干活；如果你开发完了功能，但是别人没有开发完，那么还得等其他人开发完。
图示分支的概念
每提交一个新版本，GIT就会把他们自动串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。
一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master,就能确定当前分支，以及当前分支的提交点：
当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：
Git创建一个分支很快，因为除了增加一个dev指针，该HEAD指向，工作区的文件都没有任何变化！
从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：
所以Git合并分支也很快！就改改指针，工作区内容也不变！
合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：
代码版本控制系统，常用的有SVN和GIT，目前多数都喜欢使用GIT。很多企业会考虑私有化部署，也常见使用云代码的方式，比如：阿里云效、腾讯云、华为云、码云、gitlab、github等，github受限于网络的限制，所以国内很少企业会选择使用他来进行代码的管理，但在代码开源上，github还是拥有丰富的资源。
我们先来了解主流版本管理系统（集中式版本控制系统和分布式版本控制系统）
2.1、集中式版本控制系统
Subversion简称SVN，是集中式版本控制系统的典型代表。版本控制系统的出现，解决了多人如何进行协同修改代码的问题。这类版本控制系统，都有一个单一的集中管理的版本控制管理服务器，保存所有文件的历史修订版本记录。团队成员之间的代码交换必须通过客户端连接到这台服务器，获取自己想要的文件。每个人如果想要获取其他人最新提交的修订记录，就必须从集中式版本控制系统中获得。
集中式版本控制系统有两点劣势：
·网络不佳的情况下，同步大量文件时会经常失败；
· 集中式版本控制系统有单点故障的风险。
2.2、分布式版本控制系统
Git是目前主流的分布式版本控制系统。起源于LinusTorvalds为了帮助管理Linux内核开发而开发的一个开源的版本控制软件。它与集中式版本控制系统的区别在于多个服务器共存，每个人的节点都是一个代码仓库，所有的节点都是平等的。在团队协作过程中，通常会指定某个节点作为团队的中央服务器。
分布式版本控制系统的优势：
· 分布式版本控制系统提交操作都是在本地进行而无须经过服务器，因此提交速度更快。仅当需要向其他人或远程服务器做文件提交或同步时，才通过网络将其推送到远程仓库或从远程仓库拉取。
· 分布式版本控制系统避免了单点故障的风险
master：
· master分支代码只能被release分支分支合并，且合并动作只能由特定管理员进行此操作。
· master分支是保护分支，开发人员不可直接push到远程仓库的master分支。
release：
· 命名规则：release/*，“*”一般是标识项目、第几期、日期等
· 该分支是保护分支，开发人员不可直接push，一般选定某个人进行整体的把控和push
· 该分支是生产投产分支
· 该分支每次基于master分支拉取
dev
· 这个是作为开发分支，大家都可以基于此分支进行开发
· 这个分支的代码要求是本地启动没问题，不影响其他人的代码
hotfix
· 这个分支一般是作为紧急修复分支，当前release发布后发现问题后需要该分支
· 该分支一般从当前release分支拉取
· 该分支开发完后需要合并到release分支以及dev分支
feat
· 该分支一般是一个长期的功能需要持续开发或调整使用
· 该分支基于release创建或者基于稳定的dev创建也可以
· 一般开发完后需要合并到dev分支
四、分支管理方式
4.1主干开发，主干发布
工程师直接拉去主干进行开发，开发后向主干上提交代码，并用主干代码进行软件测试和交付交付：
·优势：分支方式简单，管理工作量较少
· 不足：会有等待时间，存在一定的资源浪费，若高频交付，可能存在未完成功能的代码
4.2主干开发，分支发布
工程师拉去主干分支进行开发，当新版本功能全部开发完成后，拉去新的分支，并使用这个新分支进行集成测试，修复bug，待质量达标后，对外发布版本。
· 优势：与将要发布的新功能无关的人员可以持续工作在开发主干上，不受版本发布的影响。新发布的
版本出现缺陷后，可以直接在其自己的版本发布分支上进行修复。即使主干代码发生了变化，该分支也不会受到影响。
· 不足：主干代码通常只能针对下一个新发布版本的功能开发；若发布分支的数量不加约束，并且分支周期较长，可能出现分支地狱倾向。
4.3分支开发，主干发布
主干上拉取分支，进行新功能的开发或修复缺陷，当某个分支功能开发完成后对外发布版本时，才合入主干，在主干上进行缺陷修复，质量达标后，再将主干代码打包并发布。
优势：分支合并钱，每个分支间的开发活动互不影响；团队可以自由选择发布某个分支的特性；若新版本出现缺陷，可以直接在主干上进行修复，无须考虑其他分支
不足：推迟发现代码冲突的时间，不利于及时进行代码的重构
其实这种方式，还有另一种比较常见的处理。在某个分支开发完成后，会先提交到test分支，进行测试，当质量达标后，再从开发分支合入主干分支，并在主干分支进行打包，进行灰度测试，测试完成后发布正式环境。
五、总结
无论采用哪种分支策略，都要做好：
1.保持简洁的分支结构：不要创建过多的长期分支，以免增加复杂性和维护成本。
2.定期合并到主分支：避免长时间不合并分支，防止出现难以解决的合并冲突。
3.使用有意义的分支名称：遵循一致的命名规范，如feature/user-authentication或bugfix/login-issue。
4.编写详细的提交信息：每次提交都应附带简明扼要的描述，解释所做的更改及其原因。
5.利用PullRequests进行代码审查：通过PR机制邀请同事审查代码，确保质量并促进知识共享。
6.自动化测试和持续集成：尽可能多地自动化测试过程，并将它们集成到CI/CD管道中，以保证每次提交都能经过充分验证。
7.保护主分支：设置权限限制，只有通过特定检查（如成功构建和测试）后才能合并到main分支。
8.清理过期分支：定期删除不再需要的分支，保持仓库整洁有序。
每种分支管理方式都有其使用场景和优缺点。团队应该根据自身的项目需求、团队规模和写作方式，选择最合适的分支管理策略。此外，良好的分支命名规范、权限管理和合并策略也是确保代码质量和团队写作效率的重要因素。
AI测试涨薪交流群，内含银行业务、车载、互联网、游戏更多行业测试实战和面试题库 &【软件测试专用AI提示词包】等各种好用的
来源：柯昊教育
