我们公司采用按功能分支的方法。因此，每个开发人员都会创建一个新的分支，破解并推送到服务器上的共享存储库。服务器repos的post-receive挂钩将触发pull-request！
在我允许用户推送到服务器之前，我想检查他/她的分支是否与服务器上任何未合并的主分支发生冲突！
目前，我提供了一个canned命令，从服务器获取所有pull-request分支，并针对每个em重新启动开发人员分支，并查找是否存在冲突！
问题：
1.与每个分支进行变基/合并的过程需要很长时间
2.它不断改变工作树
我做错了还是有其他方法可以找到开发人员分支是否会与服务器上的任何拉请求分支冲突！
答案 0 :(得分：2)
在我允许用户推送到服务器之前，我想检查他/她的分支是否与服务器上任何未合并的主分支发生冲突！
在我看来，这是一个非常错误的策略。你必须意识到冲突是git的一个正常部分，它们没有什么不圣洁的，无论你多么努力避免它们，它们都会发生一次或另一次。
例如，如果有两个功能，两个功能都使用不同的代码行修改同一行号的文件，git肯定会最终引发冲突 - 你无法避免这种情况。
现在因为你将有检查没有冲突脚本，除非合并第一个分支，否则你永远无法推送第二个分支。绝对浪费时间和开发人员的工作效率。
此外，你忘记了开发人员可能会推动他们的分支，即使分支没有合并就绪，你最终也无法做到这一点。如果两个或更多的开发人员正在合作，那么他们就不会因为他们的分支与其他分支发生冲突而无法推动它们
如果你有一个足够大的开发团队（比如说10），拥有足够多的分支（比如说100），你基本上会在每次开发的每次推送时与100个分支进行比较。想象一下，10个开发人员每天只进行两次，你已经在不同的开发人员之间进行了2000次可能的冲突点。人们可能很容易花费更多的时间过早地解决冲突，然后继续发展。
那么如何以一种有礼貌的方式做到这一点？
基本上，不要试图过早地避免未来的冲突。
将其中一个分支作为引用 - 仅针对master分支进行检查，并确保在合并时与此分支完全没有冲突。
每次要完成合并时，请检查与主服务器的冲突，并仅在没有冲突时进行合并。如果存在冲突，请求请求/分支所有者获取更新的主服务器，重新分配其分支，解决冲突并再次推回。