开发人员因等待代码使用GitFlow从另一个分支合并而受阻
我们的团队刚刚从FogBugz＆Kiln / Mercurial转到了Jira＆Stash / Git。我们使用Git Flow模型进行分支，从功能分支添加子任务分支（与Jira功能的Jira子任务有关）。当我们创建一个合并到父分支的拉取请求时，我们使用Stash来分配一个审阅者（通常是开发，但是对于子任务来说是返回到功能分支）。 我们发现的问题是，即使对功能用例进行了最佳的规划和分解，当多个开发人员一起使用同一个功能时，例如在前端和后端，如果他们正在使用相互依赖的代码，在一个单独的分支中，一个开发人员最终阻止了另一个。 随着我们的发展，我们尝试在彼此的分支机构之间拉动。我们还尝试了创建本地集成分支，每个开发人员可以从多个分支中提取它们以在开发时测试集成。最后，这似乎到目前为止对我们来说是最好的，尽管开销更大，我们尝试立即从功能分支创建一个集成分支。当子任务分支（不在功能分支中）准备好进行拉取请求和代码检查时，我们还将手动将这些更改集合并到此功能集成分支中。然后，所有感兴趣的开发人员都可以从该集成分支拉到其他依赖的子任务分支。这样可以防止任何人等待他们依赖的任何分支通过代码检查。 我知道这不一定是Git问题-它与在多个分支中处理相互依赖的代码有关，并与我们自己的工作流程和文化相结合。如果我们没有用于开发的严格代码审查策略（真正的集成分支），则开发人员1可以合并以进行开发，以供开发人员2退出。另一个复杂的问题是，在将功能交付给QA之前，我们还需要在代码审查过程中进行一些初步测试，这意味着即使前端开发人员1正从后端开发人员2的分支直接拉出如果后端开发人员2完成并且他/她的拉取请求在代码审查中待了一周，那么前端开发人员2从技术上讲就无法创建他的拉取请求/代码审查，因为他/她的代码审查者无法测试，因为后端开发人员2' 最重要的是，在这种情况下，我们发现自己采用的是串行方式而不是并行方式，这取决于我们走的路线，并希望找到一种避免这种情况的过程。 我要提到的最后一件事是，我们通过在尚未经过代码审查和定稿的分支之间共享代码来实现，但实际上我们是在使用其他Beta代码。在某种程度上，我认为我们无法避免，并且愿意在一定程度上接受这一点。