问题描述
我们有一个带有一堆子模块的仓库，我们目前正在开发 develop 分支。
从同一共同提交开始，两名开发人员 A 和 B 对某些文件进行了一些更改（我认为在这里不重要），并添加了一个新修订版子模块，然后致力于开发。 现在， develop 拥有开发人员 A 提交的 subm 的 rev1 ，而 B develop 分支保存 subm 的 rev2 ，因此当 B 尝试提取所做的更改时会产生冲突。
在合并冲突后，git status会给 B ：
Your branch and 'origin/develop' have diverged,and have 1 and 1 different commits each,respectively.
(use "git pull" to merge the remote branch into yours)
All conflicts fixed but you are still merging.
(use "git commit" to conclude merge)
Changes to be committed:
modified: path/to/another/submodule
modified: path/to/file/file.html
现在，每当 B 尝试提交时，它就会得到：
U path/to/subm
error: Committing is not possible because you have unmerged files.
hint: Fix them up in the work tree,and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
我试图寻找解决方案，它们似乎都建议将有冲突的文件添加到舞台上，以将其标记为已解决，但是git status没有列出任何未合并的文件。
我似乎在这里缺少任何东西，我们将不胜感激。
解决方法
您需要在这里实现的是，一个Git子模块是另一个Git存储库。
在这里标记所有正在使用的存储库。我将假设两个开发人员都有他们自己的克隆，以便在第三个位置（也许是GitHub，也许是公司服务器，不管它是什么）有另一个Git：
- CentralSuper：这是两个开发人员都克隆的存储库。
- CentralSubmod1：这是子模块＃1，将被克隆到
path/to/another/submodule中。 - CentralSubmod2：这是子模块＃2，将被克隆到
path/to/subm中。 - DevASuper：这是开发人员A的超级项目克隆。
- DevASubmod1：这是开发人员A使用的子模块＃1的副本。
- DevASubmod2：这是开发人员A正在使用的子模块＃2的克隆。
- DevBSuper：这是开发人员B的超级项目克隆。
- DevBSubmod1：这是开发人员B的子模块＃1克隆。
- DevBSubmod2：这是开发人员B的子模块＃2克隆。
开发人员A在DevASuper中进行某些工作时，他：
- 修改或不修改某些文件-并不是那么重要；
- 进入他的DevASubmod2存储库并修改一些文件；
- 在DevASubmod2中提交以进行新的 commit ，该提交将获得新的唯一哈希ID；我们称之为
X; - 返回DevASuper并使用
git add在DevASubmod2中添加新提交作为更新的 gitlink 条目；和 - 在DevASuper中提交。
DevASuper中的新提交包含一个gitlink，内容为“在子模块＃2中使用提交X”。
开发人员A可以将此新提交推送到中央超级项目（可能在分支上）。在执行此操作之前，他还应该将新的DevASubmod2提交推送到CentralSubmod2（也可能在分支上）。谁将这些合并到CentralSuper上名为develop的分支，应确保首先对每个人都可用CentralSubmod2中的子模块存储库提交，大概是通过首先合并。 （合并它们的人可能是开发人员A本人。这只是一个通用模式：必须首先提供子模块提交。）
让我们在CentralSuper的develop分支上调用最终提交，提交SX，其中S代表Super，X代表commit {{1 }}（commit SX使用/引用从子模块2提交X）。
现在我们去看开发者B
在此之前或此时，开发人员B可以在其三个存储库中的任何一个中进行新的提交。根据您发布的内容，看来他已经在DevBSubmod2中进行了新提交。我们将此提交称为X。就像提交Y一样，它也是一个丑陋的哈希ID。
像开发人员A一样，开发人员B现在应该并且显然已经使用X和git add在他的DevBSuper存储库中进行新提交。我们将此提交称为git commit。
因此，现在，开发人员B希望将他的新提交与合并开发人员A的提交者的最终结果合并。但是提交SY说使用哈希X ，而SX说使用哈希Y 。
这是您看到的子模块冲突：
SY B正在/正在使用的超级项目有一个提交U path/to/subm
error: Committing is not possible because you have unmerged files.
hint: Fix them up in the work tree,and then use 'git add/rm <file>'
hint: as appropriate to mark resolution and make a commit.
fatal: Exiting because of an unresolved conflict.
，表示为 use Y ，还有一个提交SY，其表示为 use X 。这些“使用”的东西是这两次提交中的 gitlinks 。
Git 不能自行解决。如果正确的解决方案是使用SX ，则开发人员B应将其放入其超级项目的索引中。如果正确的解决方案是使用X ，则开发人员B应将 that 放入其超级项目的索引中。但是，提交Y或提交X都不是在开发人员B的超级项目存储库中用于新提交的正确提交。
如果这最后一个是正确的，那么开发人员B现在必须做的是：
- 输入他的DevBSubmod2存储库。
- 在此存储库中进行工作，以合并提交
Y和X。 - 测试结果（独立运行，并在开发人员B的DevBSuper存储库中使用建议的新提交）。一旦一切顺利，进行一些新的提交
Y。确保这是DevBSubmod2中的当前提交。 - 返回到他的超级项目DevBSuper，并告诉他的Git使用
Z将path/to/subm添加为提交Z。这样可以解决合并冲突，并说正确的gitlink会提交git add path/to/subm。提交Z和提交X都不正确；Y是正确的。 - 使用此gitlink在DevBSuper中进行新的合并提交。我们将此提交称为
Z。
这时，开发人员B现在可以将它们发送回各个中央存储库，再次记住，在使提交SZ对所有人可用之前，新的子模块提交必须对所有人都可用，因为 using SZ要求他们获得提交SZ。