我们的开发过程与此问题中描述的类似，需要创建许多小功能。通常每天 4-8 个功能。所有功能都应该部署到同一个测试环境，所以应该有一个test分支。
我们应该采用哪种分支策略？创建单独的功能分支似乎是一个很大的开销，同时基于主干的开发缺乏灵活性。混合这些方法是否可以（对于小功能直接提交，test对于相对大的功能单独分支）。
我们对 Git 和常见的分支策略（如 git-flow）完全陌生，并试图找到最适合小频繁功能的策略。
我们将非常感谢任何帮助或指出正确的方向，因为没有很多文章描述小功能的分支。谢谢！
考虑到您至少有两个主要分支：
production或master分支，要发布的分支test或工作分支，您可以在其中测试所有新功能考虑您直接开发所有新功能test然后将这些新功能合并到production（合并test到production）的方法。在某些时候，您将拥有不想发布到production. 然后你将被迫在reset你的test分支上继续工作，否则你会以许多不需要的特性发布到production. 或者您将需要丢弃test分支并再次从分支production中获得一个干净的副本来处理。那么如果很多团队成员都在test分支上工作，并且都将他们的更改合并到test，那么每个团队成员都很难跟踪其他团队成员正在处理的功能，因此冲突解决将变得更加难以完成。
我认为最好的选择是将每个功能视为一个不同的分支，直接从production. 因此，例如在一天中您想要 3 个新功能，您将从中分支production并创建features/one：features/two和features/three. 当这些功能中的每一个都准备好时（在不同的时间，由不同的团队成员），它们都会被合并到test（每个团队成员只需要知道他为解决冲突所做的更改，因为他在受控分支上工作，其中包含他对项目所做的更改），然后向客户或团队负责人展示。也许所有的功能都被批准了，但也许其中一个功能被拒绝了。使用这种分支策略，现在很容易丢弃所有不需要的功能并发布已批准的功能：您只需合并已批准的功能并丢弃其他功能。
为不同的功能在不同的分支上工作将使您对项目的控制更加精细，您可以在其中分开处理每个功能并且它们永远不会混合在一起。
In your case maybe you do small fixes to the project (maybe the project is a website and you just fix typos), you could then have a hotfix/quick-fixes branch (branched from production) where you work all those small changes (that will be published for surely) and then merge those changes to test to make a quick review of those changes or you merge directly to production for publishing.
Hope this point of view help you solve your branching strategy.