目录
- 背景和失败经验
-
- 名词定义
- [曾经使用project branch犯的错](#曾经使用project branch犯的错)
- [建立project branch的必要性](#建立project branch的必要性)
- [正确的使用project branch的方法](#正确的使用project branch的方法)
背景和失败经验
我们曾经使用过project branch,但是后来放弃了
名词定义
特性branch(特性分支): 在开发跨越新特性的时候会从主branch(master/trunk/develop)创建而来的一个git branch。经常会以 feature/<特性名>
命名
project branch(子项目分支): 在开发较大功能的时候会由几个程序员组成一个子项目小组。此时可以为这个子项目建立一个较大的开发branch。这个branch可以跨越sprint。改子项目开发人员的提交先提交到该project branch上,到一定时间点,把由project branch合并(merge)到主分支上。project branch可以以feature/<子项目名>-<创建日期>
命名
conflict(代码冲突): 在branch代码merge到另外一个分支的时候,发生了该branch跟原branch修改了同一行代码的情况。git无法自动完成合并,需要开发人员手动解决。
revert(回滚): 取消最近的N个代码改动,恢复到某个之前的版本。
在写这个题目之前我曾经认为是理所应当的。但是自从我们的项目组在使用独立开发分支之后出现了一些问题后,我们开始考虑不使用独立分支。但是带来的问题更多,至此我才真的理解了独立开发分支的重要性。果然是最透彻的领悟还是得靠犯错获得。
曾经使用project branch犯的错
以下是我们放弃project branch的理由。但是这些理由其实是错误的使用了branch而造成的。所以我会写上当时觉得project branch不好的地方,并且写上真正的原因。
- project branch让代码变得混乱,我们在不同的project branch上有不同版本的组件。真正的原因:过多的开发branch导致代码管理混乱,比如大量长期未同步的branch使得全局代码构成复杂

- 每次合并project branch的时候出现了很多conflicts。解决起来很困难。有时候解决冲突的过程中甚至带来了新的bug,比如不小心删除了正确的代码。真正的原因:长时间未同步branch导致合并时冲突过多,增加解决冲突成本。而且正确的同步方向是从主分支同步到开发分支
其实这些并不是project branch本身的问题。
建立project branch的必要性
以下是建立project branch的必要性以及正确使用方法。
- 合并前检查conflict:可以通过pull request的方式在合并前预先查看是否存在冲突。
- 评估测试流程:在合并前事先通知测试团队,并确保他们有足够的测试窗口。
- 极大地减少revert难度:如果一个branch只包含了一个feature,将进一步减少涉及其他功能并存导致的强耦合问题。
- 在project branch上执行自动化测试:使用持续集成工具在project branch上进行sanity测试,确保合并之前功能可靠性。
- 公共的主branch的用户比你想象的多 :其实使用主branch的人不只是某些engineers,别的engineers有可能也会用到。
甚至测试人员和产品经理也会用到。
总结
使用project branchh可以最大化地减少发布风险,提升代码跟踪性和测试效率,实现更高效的团队合作。
正确的使用project branch的方法
-
每日同步:保持每日从主branch同步代码,避免太大冲突
-
保持年轻:该project branch不要保留太久(不能超过3个sprint)
-
压缩合并: 使用
squash & merge
来合并代码
-
保持干净:合并完后删除project branch,防止后续代码提交