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

Question

摘要

我目前正在从事一个大型项目，该项目由多个团队共同开发，总共有超过 50 名开发人员。我们正在尝试利用已知方法的每一点，以使我们的交付过程顺畅且可预测(Scrum、代码卡住、计划 session 、回顾等)。相反，我们最终得到的是一团糟。最近，我们在产品演示之前遇到了巨大的 merge/部署问题，这不仅是因为来自管理层和客户的巨大压力，还因为我们在开发方面的工作组织方式。

问题

我们将 git 与 GitLab 结合使用，我们使用 pull 请求，我们试图在将更改 merge 到生产分支之前审查这些更改。但碰巧在半天(4 小时)接近截止日期时，开发人员往往会提交超过 50 devs * 0.5 day = 25 dev days 的工作，使我们的最终分支严重不稳定.问题在于大多数分支在隔离时是稳定的，但在 merge 时会出现问题。由于增量 merge ，问题变得更加严重，当开发人员在团队分支内处理大量功能时，这些大型团队分支最终会 merge 到生产分支中。最后，很难精细地回滚特定的小问题，因为有大量的代码覆盖在它上面。

问题

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

我不确定从哪里开始，也许有一些关于这个主题的文献，或者您有自己的最佳实践可以分享。感谢您提供有关该主题的任何信息。

提前致谢!

Answer 1

好的，问题出在 merge 分支上。基本上，在任何开发人员将分支推送到 origin 之前，开发人员应该将分支从最终分支 rebase 。如下

git rebase origin/final_branch_name

此命令将您当前的分支重新设置为最终分支，如果超过 1 位开发人员进行更改的问题区域显示为冲突，因此您必须解决该冲突，然后将分支推送到原点并发出 pull 请求。 此过程避免了 git dashbord 的冲突，并允许开发人员轻松 merge 分支。