如何避免过时的个人分支被推送并合并到主分支

Question

目前我们的开发团队正在使用以下 git 流程：我们有一个主分支、一个发布分支和几个个人分支。个人分支（远程和本地）由开发人员自己创建和管理，以保存未完成的工作。主分支和发布分支受到保护，没有开发人员可以将其个人分支合并到主分支或发布分支，除非他创建拉取请求并获得通过。目前，这种方法对我们来说效果很好，但仍然存在一个问题：

开发人员应该在开始工作之前拉取更改并将主分支合并到他自己的分支，以防他们的分支变得过时。但时不时，总会有人忘记做这件事，造成一些麻烦。例如，一些文件在 master 上的实现已经改变，但是忘记更新他们的分支的人可能仍然在旧版本上工作。当他完成工作并想要将更改合并到 master 时，他意识到分支已经过时，最终，当他从 master 拉取更改并合并时，会发生繁琐的合并冲突，他必须修复它们。

因此，对于这个问题，我正在寻找一些可以帮助我们消除此类问题的自动工具。如果有人对此有想法，或者有想法改进我们当前的 git 流模型，请在下面留下答案，谢谢！

Answer 1

解决这个问题的一个简单方法是指示所有开发人员永远不要签出任何共享分支！换句话说，永远不要查看master 或release（或develop，如果有的话）。然后，任何时候你想从master 分支出来，取而代之的是从origin/master 分支出来。与变基相同。经常变基到origin/master 而不是本地master。这种方式也更快、更高效（与切换到共享分支的本地副本并不断更新它们相比）。

我指示开发人员做的另一件事是，在他们处理分支时，始终查看打开的分支日志。每次他们提交、修改、变基等时，都应该刷新。这样，如果事情看起来不对劲，他们会立即发现。而且，如果从旧版本的 master 开始，他们也会从一开始就看到这一点，甚至在他们第一次提交之前，因为他们分支的顶部提交会是旧的。

作为旁注，我同意matt's comment，“那又怎样？”因为即使你从一个真正旧版本的origin/master 分支出来（可能是因为你在 6 个月前开始在功能分支上工作，现在又回到了它），只需重新定位到最新的 origin/master 并修复任何合并冲突你有。合并冲突是编程团队中经常发生的事实，只要双方的意图都很明显，通常可以由 1 个人快速解决。

Answer 2

首先，您所描述的不是 gitflow。在 gitflow 中有 2 个持久分支； master（又名主）和develop。只有 hotfix 分支应该从 master 分支，而 feature（和 release）分支应该从 develop 分支。请参阅here 以获得对 gitflow 的良好描述。以下是该链接中的图表来说明其工作原理：

为了解决您的特殊问题（使用 gitflow），使 master 和 develop 需要 PR（合并代码）并禁用强制推送。这意味着如果“master”（用于修补程序）和“develop”（用于功能）中有新代码不在被合并的修补程序/功能分支中，开发人员将需要分别在 master 或 development 之上重新调整他们的更改。 注意：此方法也可用于其他分支策略，以防止您的团队遇到问题。

最后，还有一个 gitflow 扩展 here 可以帮助您的团队正确实施 gitflow。