在大型项目中使用git的最佳实践 摘要

我目前正在从事一个大型项目，该项目由几个团队开发，总共有50多名开发人员。我们正试图利用已知的每一点方法，以使我们的交付过程平滑且可预测（Scrum、代码冻结、计划会议、回顾等）。相反，我们最终得到的是一片混乱。最近，在我们的产品演示之前，我们遇到了巨大的合并/部署问题，这不仅是因为管理层和客户的压力，还因为我们在开发方面的工作组织方式

问题 我们在GitLab中使用git，我们使用pull请求，我们试图在将更改合并到生产分支之前检查这些更改。但是，开发人员往往在半天（4小时）内就接近死线，投入超过

50个dev*0.5天=25个dev天的工作，这使得我们的最后一个分支非常不稳定。问题是大多数分支在隔离状态下是稳定的，但在合并时会导致问题。由于增量合并，当开发人员在团队分支中处理一大块功能时，问题变得更加严重，这些大型团队分支最终合并到生产分支中。最终很难精确地回滚特定的小问题，因为有大量的代码在上面

问题:
我正在寻找一种方法，使我们的交付过程在使用git时更加可预测和透明。其他大型项目如何组织他们在上述方面的工作

我不知道从哪里开始，也许有一些关于这个主题的文献，或者你有你自己的最佳实践可以分享。任何关于这个主题的信息都将不胜感激

提前谢谢你
 好问题。以下是一些我觉得有用的注释：



好的，所以问题在于合并分支。基本上，在任何开发人员将分支推到原点之前，开发人员应该从最终分支重新设置分支的基础。具体如下:

git重新基准来源/最终分支机构名称

此命令将当前分支重新划分为最终分支，如果一个有问题的区域中有1个以上的开发人员进行了更改，则显示为冲突，因此您必须解决该冲突，然后将分支推送到原始分支并发出请求。
此过程避免了git dashbord的冲突，并允许开发人员轻松合并分支。
您是否可以添加一个git操作，在每个提交中都对最终分支名称具有pull regust的所有分支执行此重定基