开发人员因等待代码使用GitFlow从另一个分支合并而受阻

我们的团队刚刚从FogBugz＆Kiln / Mercurial转到了Jira＆Stash / Git。我们使用Git Flow模型进行分支，从功能分支添加子任务分支（与Jira功能的Jira子任务有关）。当我们创建一个合并到父分支的拉取请求时，我们使用Stash来分配一个审阅者（通常是开发，但是对于子任务来说是返回到功能分支）。

我们发现的问题是，即使对功能用例进行了最佳的规划和分解，当多个开发人员一起使用同一个功能时，例如在前端和后端，如果他们正在使用相互依赖的代码，在一个单独的分支中，一个开发人员最终阻止了另一个。

随着我们的发展，我们尝试在彼此的分支机构之间拉动。我们还尝试了创建本地集成分支，每个开发人员可以从多个分支中提取它们以在开发时测试集成。最后，这似乎到目前为止对我们来说是最好的，尽管开销更大，我们尝试立即从功能分支创建一个集成分支。当子任务分支（不在功能分支中）准备好进行拉取请求和代码检查时，我们还将手动将这些更改集合并到此功能集成分支中。然后，所有感兴趣的开发人员都可以从该集成分支拉到其他依赖的子任务分支。这样可以防止任何人等待他们依赖的任何分支通过代码检查。

我知道这不一定是Git问题-它与在多个分支中处理相互依赖的代码有关，并与我们自己的工作流程和文化相结合。如果我们没有用于开发的严格代码审查策略（真正的集成分支），则开发人员1可以合并以进行开发，以供开发人员2退出。另一个复杂的问题是，在将功能交付给QA之前，我们还需要在代码审查过程中进行一些初步测试，这意味着即使前端开发人员1正从后端开发人员2的分支直接拉出如果后端开发人员2完成并且他/她的拉取请求在代码审查中待了一周，那么前端开发人员2从技术上讲就无法创建他的拉取请求/代码审查，因为他/她的代码审查者无法测试，因为后端开发人员2'

最重要的是，在这种情况下，我们发现自己采用的是串行方式而不是并行方式，这取决于我们走的路线，并希望找到一种避免这种情况的过程。

我要提到的最后一件事是，我们通过在尚未经过代码审查和定稿的分支之间共享代码来实现，但实际上我们是在使用其他Beta代码。在某种程度上，我认为我们无法避免，并且愿意在一定程度上接受这一点。

问题还可能在于后端和前端开发之间的任务过于僵化。

如果前端开发人员需要新的API，那么是否可以允许他或她在后端创建虚拟API（例如，始终返回相同的值）来验证布局？然后使用存根提交该部分实现，第二次，后端开发人员将实现真正的功能。

通过打破依赖性，您将获得更好的流程，并且您不必停止所有等待成为瓶颈的任务。

您的问题：来自Master的开发人员A分支，来自Master的开发人员B分支都在紧密相关的功能上工作，并且由于不可避免的冲突而难以合并到Master分支的不可避免的事实是每个人都无法忍受。

如果可以预见，那么A和B可以首先创建一个公共分支，然后从该公共分支中为各自的工作创建每个分支，将其各自的工作合并到该公共分支中，现在您有了一个无冲突分支，易于集成。

如果开发人员1使用功能A，而开发人员2完成了依赖功能A的功能B，则无法解决它-合并功能B处于保留状态。如果没有功能部件A，您将无法对其进行测试，而且由于功能部件A的进一步发展可能会导致功能部件B的变化，因此对其进行审查尚无意义。

但是，这并不意味着开发人员2处于暂停状态！开发人员2可以开始使用功能C，一旦功能A完成，就可以返回功能B的审阅修复周期。我知道，上下文切换是不是最优的，因为这个时间它会采取以完整功能的一个可能是天计这不是说不好（你是不是15分钟车侧任务拉出来的“区”）

您可以做的一件事来帮助您解决这种情况，那就是仔细研究缩短开发周期的方法。

如果某个开发人员正在等待另一开发人员的功能，是否有办法让部分第一位开发人员的工作可以在整个功能释放之前进行审核和集成，以释放功能块？

是否有办法将功能分解为较小的工作单元，以保持集成周期继续进行？

另外，集成需要多长时间？如果构建或集成需要很长时间，则可能会减慢整个队列。查看您是否可以采取任何措施来加快构建时间，以便更快地释放队列。