我目前正在开发一个由多个团队开发的大型项目，共有50多名开发人员。我们正在尝试利用每一小部分已知方法，以使我们的交付流程顺利和可预测（Scrum，代码冻结，计划会议，回顾等）。相反，我们最终得到的是一团糟。最近，我们在产品演示之前遇到了巨大的合并/部署问题，不仅是因为管理层和客户的压力，还因为我们的工作在开发方面的组织方式。
我们使用git与GitLab，我们使用pull请求，我们尝试在将更改合并到生产分支之前检查更改。但事实上，在一天中只有半天（4小时）接近死线的情况下，开发人员倾向于提交超过50 devs * 0.5 day = 25 dev days的工作，使我们的最终分支严重不稳定。问题是大多数分支在隔离时是稳定的，但在合并时会导致问题。由于增量合并，当开发人员正在处理团队分支内的大量功能时，问题变得更加严重，并且这些大型团队分支最终合并到生产分支中。最后，很难精确地回滚特定的小问题，因为有大量代码可以使用它。
我正在寻找一种方法，以便在使用git时使我们的交付流程更具可预测性和透明度。其他大型项目如何在之前描述的方面组织他们的工作。
我不知道从哪里开始，也许有一些关于这个主题的文献，或者你有自己的最佳实践，你可以分享。有关该主题的任何信息表示赞赏。
提前谢谢！
答案 0 :(得分：3)
好的，问题在于合并分支。基本上在任何开发人员推送分支到源之前，开发人员应该从最终分支重新分支分支。它如下
git rebase origin / final_branch_name
此命令使用最终分支重新绑定当前分支，如果一个有问题的区域中有多个开发人员将更改显示为冲突，那么您必须解决该冲突，然后将分支推送到origin并发出pull请求。 这个过程避免了git dashbord的冲突，并允许开发人员轻松地合并分支。
答案 1 :(得分：1)