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

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

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

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

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

解决方法

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

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

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

,

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

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

顺便说一句，我同意 matt's comment 的“那又怎样？”因为即使你从一个非常旧版本的 origin/master 分支（也许是因为你在 6 个月前开始在功能分支上工作，现在又回到了它），只需重新建立到最新的 origin/master 和修复您遇到的任何合并冲突。合并冲突是编程团队中经常发生的事情，通常可以由一个人快速解决，只要双方的意图都很明显。