📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）
📝 职场经验干货：
团队的研发本质不是团队规模越大，研发效率就越高；相反随着团队规模的扩大，反而逐渐增加项目的管理成本，协作成本也越来越高，代码冲突变多，导致研发效率越来越慢。
测试过程中，是否有出现过以下情况：
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 是目前主流的分布式版本控制系统。起源于 Linus Torvalds 为了帮助管理 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、利用 Pull Requests 进行代码审查：
通过 PR 机制邀请同事审查代码，确保质量并促进知识共享。
6、自动化测试和持续集成：
尽可能多地自动化测试过程，并将它们集成到 CI/CD 管道中，以保证每次提交都能经过充分验证。
7、保护主分支：
设置权限限制，只有通过特定检查（如成功构建和测试）后才能合并到 main 分支。
8、清理过期分支：
定期删除不再需要的分支，保持仓库整洁有序。
每种分支管理方式都有其使用场景和优缺点。团队应该根据自身的项目需求、团队规模和协作方式，选择最合适的分支管理策略。此外，良好的分支命名规范、权限管理和合并策略也是确保代码质量和团队协作效率的重要因素。
最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
