按功能特性创建分支

《持续交付：发布可靠软件的系统方法》

按功能特性创建分支的主要原因是保证主干的可发布状态。创建分支之后，开发团队所有的功能或者特性开发都在分支上进行，不会被其他人或者其他团队打扰。这种模式对于在功能完成前，不愿意公开其代码的团队也有一定帮助。如果每个分支合并为一次提交，那么从主干的提交记录上，每一次提交都是一个完整的特性或者缺陷修复，这样的提交记录具有更完整的语义性。

这是一种分支的策略，如果能满足相应的条件，并且真正的理解这种模式的一些约束与准则后，经过团队的充分讨论并达成一致，就可以使用这种分支模式。

应该做充分的估计，确保采用这种模式的收益远比其客观的开销更大，而且要确保在发布日期来临之际，不会引起灾难性的后果。

需要强调的一点是，按照功能特性创建分支与持续集成是相对立的，所有的原则与准则只是为了在合并的时候情况不会太糟糕。如果能从源头避免痛苦，那就会简单很多。

需要提醒的是，当采纳这种模式时，就是“在刀尖上跳舞”。

要想这种模式有效果，需要遵从如下一些准则：

1. 每天要把主干上的所有变更合并到每一个功能分支。

2. 每个功能分支都应该只具有很短的生命周期，理想情况下只有几天，绝对不能超过一个迭代周期。

3. 活跃分支的数量在任意时刻都应该少于或者等于正在开发中的用户故事的数量。在一个迭代中，除非已经把开发中的用户故事合并回主干，否则不可以创建新的分支。

4. 在合并回主干之前，必须确保该分支已经经过了完备的测试，没有完全通过测试的用户故事不可以合并回主干。

5. 重构必须即时合并，从而使合并冲突最小化。这个约束非常重要，也可能非常痛苦，从而也限制了此模式的使用。

6. 技术负责人的一部分职责是保证主干的可发布性，他应该检查每一次合并，也有权拒绝可能破坏主干的合并。

在开源世界，这种模式非常有效。同时，这种模式适合那种核心团队很小且由经验丰富者组成的商业项目中。在大型的商业项目中，这种模式也可能发挥作用，但是需要注意以下几点：

1. 代码基被合理分解为多个模块。

2. 交付团队被分成几个小团队，每个小团队由以为经验丰富者领导。

3. 整个团队承诺频繁地向主干提交合并，并持续集成。

4. 交付团队不会屈从于交付压力而达成未达标准的发布决策，例如向主干合并没有经过充分测试的用户故事等。

不过采用这种模式应该谨慎，因为它与商业软件开发中的一个反模式紧密相关。这个反模式既邪恶又常见。这个反模式就是：开发人员通过分支创建特性，而这个特性分支会独立存续很长时间，同时其他开发人员也会创建其他分支。只有在接近发布时间点，所有分支才会合并回主干。

1. 要确保按照功能特性分支模式的有效性，最重要的事情是哪些？

* 首先，所有的分支应该是短生命周期的。

* 其次，所有分支在合并回主干之前需要经过充分的测试。

* 最后，分支合并需要经过review。

2. 这种模式与持续集成是对立的吗？

在没有k8s等工具出现之前，持续集成的资源耗费导致了无法对每一个分支进行持续集成，所以有这种说法。如果可以对每一个分支都进行持续集成，那么这种对立也就自然消失了。

https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow