问题描述
如果我要为此开发创建一个功能分支，那么审阅者将拒绝我的请求请求，因为请求请求太大（没人会检查数百个更改）。
因此，我决定拆分请求。我从开发人员创建了名为my-big-feature的功能分支，在其中将实现我的整个功能。
然后我从subfeature创建了另一个my-big-feature，对其进行处理，然后将PR制作为my-big-feature。
然后，我应该继续研究依赖于subfeature2的{{1}}。但是我的subfeature尚未合并。
这就是为什么我从subfeature创建subfeature2并对其进行处理并决定将PR设为subfeature的原因。
但是它有自己的缺点。当审阅者查看我的subfeature并发现一些错误时，我应该不断地将subfeature合并到subfeature中。
我认为效率不高。那么，我该怎么办？
解决方法
针对简单案例
向您的团队解释您将要做什么。然后明智地前进，然后一次提交到代码库中。提供测试。
考虑“分支”
分支不一定是git问题。有时候，在代码内分支会更有效，例如通过为新功能提供通断开关。这使您可以自由地逐步开发该功能，直到可供公众使用为止。这将导致许多小的提交定期合并到主线中。功能就绪后，您可以删除该开关并删除旧的代码分支。
代码分支策略
如果无法在不破坏现有行为的情况下提供单个提交，那么您可能需要考虑使用Feature Toggles或Branch By Abstraction之类的高级技术。
这些技术必须在团队内部接受并理解，因为它们会暂时增加代码库的复杂性。
但是，遵循它们将会提供一种有效的策略，以将经过测试的代码尽快投入生产。它还将帮助您以受控方式推出/分发软件的新版本。