【问题标题】：Best practices for using git in large project在大型项目中使用 git 的最佳实践
【发布时间】：2015-08-18 09:32:18
【问题描述】：

摘要

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

问题

我们将 git 与 GitLab 一起使用，我们使用拉取请求，我们正在尝试在将更改合并到生产分支之前对其进行审查。但碰巧在接近截止日期的半天（4 小时）内，开发人员往往会提交超过50 devs * 0.5 day = 25 dev days 的工作，从而使我们的最终分支严重不稳定。问题是大多数分支在隔离时是稳定的，但在合并时会导致问题。由于增量合并，问题变得更加严重，当开发人员在团队分支内处理大量功能时，这些大型团队分支最终会合并到生产分支中。最后，很难精细地回滚特定的小问题，因为有大量的代码在上面。

问题

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

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

提前谢谢你！

【问题讨论】：

标签： git merge

【解决方案1】：

好的，所以问题在于合并分支。基本上在任何开发人员将分支推送到源之前，开发人员应该从最终分支重新建立分支。如下

git rebase origin/final_branch_name

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

【讨论】：

您能否添加一个 git 操作，该操作在每次提交中对 final_branch_name 具有拉取规则的所有分支上执行此变基

【解决方案2】：

好问题。以下是我发现有用的一些注释：

【讨论】：