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

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以进行发布。

希望这种观点能帮助您解决分支策略。