我们公司采用按功能划分分支的方法。因此，每个开发人员都会创建一个新分支，破解并推送到服务器上的共享存储库。服务器 repos 的 post-receive 钩子会触发 pull-request！
在我允许用户推送到服务器之前，我想检查他/她的分支是否与服务器上的任何 unmerged-with-master 分支发生冲突！
目前我给出了一个固定命令，它从服务器获取所有拉取请求分支，并针对每个 em 重新设置开发人员分支并查找它是否产生冲突！
问题：
1. 与每个分支进行变基/合并的过程需要很长时间
2. 不断更换工作树
是我做错了吗，还是有其他方法可以确定开发人员分支是否会与服务器上的任何拉取请求分支冲突！
【问题讨论】：
标签： git conflict git-merge git-rebase pull-request
在我允许用户推送到服务器之前，我想检查他/她的分支是否与服务器上的任何 unmerged-with-master 分支发生冲突！
在我看来，这是一个非常错误的策略。你必须意识到冲突是 git 的一个正常部分，它们并没有什么不圣洁的地方，而且无论你如何避免它们，它们总会发生。
例如，如果有 2 个特性，两个特性都用不同的代码行修改同一行号的文件，那么 git 肯定会最终引发冲突 - 你无法避免这种情况。
现在因为您将拥有这个 检查无冲突 脚本，所以除非合并第一个分支，否则您将永远无法推送第二个分支。绝对浪费时间和开发人员的生产力。
此外，您忘记了即使分支尚未准备好合并，开发人员也可以推送他们的分支，您最终也无法这样做。如果两个或多个开发人员正在协作，他们将无法推送，因为他们的分支与其他分支发生冲突
如果你有一个足够大的开发团队（比如 10 个），有足够多的分支（比如 100 个），那么在每个开发者的每次推送中，你基本上最终都会与 100 个分支进行比较。想象一下 10 位开发人员一天只推入两次，而您已经遇到了 2000 个不同开发人员组之间可能的冲突点。人们可能很容易最终花更多的时间过早地解决冲突然后发展。
那么如何以一种理智的方式做到这一点呢？
基本上，不要试图过早地避免未来的冲突。
将其中一个分支作为参考 - 仅检查 master 分支并确保在合并时与此绝对没有冲突。
每次要进行合并时，检查与主服务器的冲突，只有在没有冲突时才合并。如果存在冲突，请请求请求/分支所有者获取更新后的 master，rebase 他的分支，解决冲突并再次推送。
【讨论】：