我有兴趣学习解决大团队冲突的最佳方法。
例如，我有一个主分支，其中团队进行了大量的更改，然后我重新定义了来自上游的最新更改（主连接和上游未连接）。我遇到了冲突。问题是团队中的某个人更了解如何在一个文件中解决冲突，而另一些人则更了解另一个文件。
所以问题是：是否有可能将未解决的分支推送到远程等待，直到同事解决其本地环境中的冲突并推回它们然后进行git rebase - 继续。
如果不是解决这个问题的最佳方法是什么？
答案 0 :(得分：4)
简短的回答是否定的，你不能推动冲突的合并。
稍微长一点的答案是合并发生在（并通过）git的索引（也称为临时区域）。该索引具有双重角色，可充当 next 提交的暂存区域，也可用作加速扫描工作树的缓存。出于合并目的，缓存方面通常可以忽略。
在索引中，与工作树文件对应的每个条目最多有四个“插槽”（最多三个正在使用中），称为阶段：
如果文件没有冲突，则阶段1-3为空;如果文件有合并冲突，则阶段0为空，并且填充部分或全部插槽1-3（取决于特定的合并冲突，一些可能是空的，例如，可能冲突是“两个都创建”在这种情况下没有共同的祖先，或者它可能是“被他们修改但被我们删除”，在这种情况下，没有第二阶段的进入。
要将文件标记为已解决，您的路径为git add或git rm;这将删除阶段1-3条目并放入阶段0条目（对于git rm，阶段0条目是“一旦我们进行提交，该文件将被删除”）。
在进行新提交时，git将暂存区域转换为一组“树”对象，这些对象将描述该提交中的所有文件。要从暂存区域创建树，它只能有stage-0条目;只有那些条目进入树中。
使用git push或git fetch时，您会在存储库之间传输提交。只有整个提交（以及它们的树和其他相关对象）才能以这种方式转移。因此，在索引中发生并使用阶段1-3的冲突的进程内合并不能跨机器传输。这是git的基本设计限制，因为它在今天实现。
答案 1 :(得分：1)
Git的工作方式使您的服务器永远不会发生冲突。
如果在本地项目中，当您提取远程新提交时，您在一个文件上存在冲突，那是因为您更改了此文件。所以你就是知道如何解决冲突的人。
这就是为什么git希望你在推送服务器之前解决冲突的原因。