制作装饰公司网站百度营销大学

背景和失败经验

我们曾经使用过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，防止后续代码提交