无法解决与 git submodule 文件夹的合并冲突

Question

我有两个 git 分支，开发和重新设计需要合并。我有一个名为 library 的子模块，其更新正在由开发跟踪。当我运行 ' git merge' 时，它说库已被两者修改，即使我没有触及库子模块。当我单击 VS Code 中的库以查看冲突的更改时，我看到了以下内容：

diff --cc library
index 749618f9,589a7ae5..00000000
--- a/library
+++ b/library

我尝试删除库文件夹并git submodule update在重新设计分支中运行“ ”，然后再合并没有成功。我在重新设计中将 ignore = all 添加到 .gitmodules 文件中，但没有用。如何摆脱与此子模块的合并冲突？

Answer 1

我解决了这个问题。我从类似 StackOverflow 问题的回复中找到了答案：/sf/answers/2098038421/。当我跑到'git add'图书馆并提交它时，问题就消失了。我团队中的另一位开发人员更改了与库子模块关联的哈希值。

Answer 2

将 vscode 与子模块结合使用：UI 可以很好地处理大多数事情。

但是，由于子模块合并冲突，我找不到解决方法。

所需要做的就是在 cli 中运行它：

git add submodule-name

Answer 3

的问题是，library 已经在两个分支被修改，相对于所述的合并基础提交。这里的技巧是理解子模块被“修改”意味着什么。

请记住，任何子模块的本质是您的超级项目指的是其他一些 Git 存储库。其他Git仓库，一个被用来作为一个子模块，不知道它被用来作为一个子模块。它只是一个普通的旧 Git 存储库。¹ 它有提交。任何一个提交的真实名称是它的哈希 ID。使用这个子模块的超级项目在子模块中运行 Git 命令，通过哈希 ID告诉它git checkout某个特定的提交，这导致子模块 Git 处于分离的 HEAD模式。

同时，回到超级项目：这个仓库是一个普通的 Git 仓库。它有提交。每个提交的真实名称是一些哈希 ID，但通常您会使用git checkout一些分支名称。分支名称将解析为某个特定的哈希 ID，并且您的超级项目 Git 将通过该分支名称检查该提交——例如，develop——现在处于某个特定的提交上，例如，a123456...。所以让我们说你在 commit a123456。

在commit 的某个地方a123456，有一个类似文件的对象，它实际上不是一个文件，而是一个gitlink。提交中的这个 gitlink 对象包含子模块中存在的某个提交的原始哈希 ID。在您的情况下，此 gitlink 是名称的条目library，它包含，例如589a7ae5. 这是子模块的提交：如果您运行git submodule update，您的超级项目 Git 将进入子模块 Git 并命令它执行git checkout 589a7ae5.

所以：超级项目中的每个提交都有一个名为的“文件” library，它实际上是一个 gitlink，并存储了一些哈希 ID。你现在已经运行：

git checkout develop
git merge redesign

（或者反之亦然）。该git merge命令已找到由分支名称develop和指定的提交redesign，以及作为其他两个提交的合并基础的第三个提交。

所有这三个提交都有（或缺少：你的一个是00000000）一个名为 .gitlink 的条目library。这些 gitlink 中的三个哈希 ID 都是不同的。Git 现在正在尝试合并两个差异：

• 一个差异说从合并基础中的 gitlink X 开始，用哈希 ID Y 替换那个 gitlink。
• 另一个差异表示从合并基础中的 X 开始，用 Z 替换它。

这两个指令——用 Y 替换，和用 Z 替换——相互冲突。Git 不知道哪一个是正确的（如果实际上哪一个是正确的）。

为了解决这个特定的合并冲突，您的工作是为子模块选择正确的哈希 ID。一旦你知道正确的哈希 ID——你如何找到这取决于你^2——你只需暂时切换到子模块 Git 存储库并运行，然后返回超级项目并运行。您的超级项目 Git 现在会在将进入合并提交的 gitlink 中记录新的哈希 ID，并且合并冲突已解决。git checkout hashgit add library

当您解决了所有合并冲突（包括普通文件冲突，如果有的话）并准备提交合并时，运行git merge --continue或git commit完成合并。合并提交将具有您添加的哈希 ID作为其gitlink library。

（如果正确的做法是完全停止使用子模块，您可以git rm library先检查正确的子模块哈希，然后再检查git add名称。）

¹这跳过了一些技术细节，通过这些细节可以发现这个子模块存储库存在于某个超级项目中。重要的是，大多数 Git 完全不知道这些细节：子模块认为它是独立的，就像它一样。此外，典型的子模块的Git回购是一些其他的Git回购的克隆，而其他的Git回购是完全不知道克隆的，所以即使你的克隆子模块的使用，都知道，这是一个子模块，其 origin仍然不会知道。

²查找正确哈希 ID 的典型示例方法如下：

cd library

其次是各种git log和/或git show和/或git checkout命令，或者可能gitk --all或您喜欢用来查看 Git 存储库的任何内容。最终，您会发现一些看起来不错的哈希 ID 并git checkout在其上运行，以便更新此存储库中的工作树，然后cd退出子模块并构建和测试项目。这个过程很自然地将子模块留在正确的提交上，这样你就不必重新git checkout正确的哈希 ID。