s0n*_*uth 4 git conflict git-rebase merge-conflict-resolution git-branch
我有兴趣学习解决大团队冲突的最佳方法。
例如，我有一个主分支，团队在其中进行了相当多的更改，然后我正在重新调整来自上游的最新更改（主分支和上游未连接）。我也遇到了冲突。问题在于团队中的某个人更了解如何解决一个文件中的冲突，而其他人则更了解另一个文件中的冲突。
所以问题是：是否可以将未解决的分支推送到远程，等待同事解决本地环境中的冲突并将其推回，然后进行 git rebase --continue。
如果不是，解决这个问题的最佳方法是什么？
简短的答案是否定的，您不能推送冲突的合并。
稍微长一点的答案是，合并发生在（并通过）git 的索引（也称为暂存区）中。索引具有双重作用，既充当下一次提交的暂存区域，又充当加速扫描工作树的缓存。出于合并目的，缓存方面大多可以被忽略。
在索引中，对应于工作树文件的每个条目最多有四个“槽”（最多三个正在使用中），称为阶段：
如果文件没有冲突，则阶段 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 的基本设计限制。