针对单个环境的小频繁特征的Git分支策略

Question

我们的开发过程与描述的in this question相似，需要创建许多小的特性。通常每天有4-8个特征。所有特性都应该部署到同一个测试环境中，因此应该有一个test分支。

我们应该采取什么样的分支战略？创建独立的特性分支似乎是一个很大的开销，同时基于主干的开发缺乏灵活性。将这些方法混合使用是否可以(对于小特性直接提交test，对于相对较大的特性单独使用分支)。

我们对Git和常见的分支策略(如git-flow)非常陌生，并试图找到最适合于小型频繁特性的策略。

我们将非常感谢任何帮助或指向正确的方向，因为没有很多文章描述分支的小功能。谢谢!

Answer 1

考虑到你至少有两个主要分支：

1. production或master分支，即将发布的分支
2. test或工作分支，在其中测试所有新特性

考虑直接在test上开发所有新特性的方法，然后将这些新特性合并到production (合并test到production)。在某种程度上，您将开发出不希望发布到production的特性。然后，您将被迫reset您的test分支继续工作，否则您将以许多不必要的特性发布到production中结束。或者，您需要丢弃test分支和production中的分支，以便有一个干净的副本来处理。然后，如果许多团队成员都在test分支上工作，并且都将他们的更改合并到test中，那么每个团队成员将很难跟踪其他团队成员正在进行的功能，因此冲突解决将变得更加困难。

我认为最好的选择是将每个特性作为一个不同的分支，直接从production分支。因此，例如，在一天内，您需要3个新特性，您将从production分支并创建：features/one、features/two和features/three。当每个特性都准备就绪时(在不同的时间，不同的团队成员)，它们都被合并到test中(每个团队成员只需要知道他为解决冲突所做的更改，因为他在一个受控分支上工作，不了解他对项目所做的更改)，然后向客户或团队负责人展示。也许所有的功能都被批准了，但也许其中一个功能被拒绝了。使用这种分支策略，现在很容易丢弃所有不想要的特性并发布已批准的特性:您只需合并已批准的特性并丢弃其他功能即可。

使用不同的分支来处理不同的特性将为您的项目提供一个更细粒度的控制，在这里，您将每个特性分开工作，它们永远不会混合。

在您的示例中，您可能对项目做了一些小的修复(可能项目是一个网站，您只需修复排版)，然后您可以有一个hotfix/quick-fixes分支(从production中分支)，您可以在其中处理所有这些小的更改(这些更改肯定会被发布)，然后将这些更改合并到test以快速查看这些更改，或者直接合并到production进行发布。

希望这个观点能帮助你解决你的分支策略。