如何管理与 git 子模块的冲突？

Question

我有一个引用多个子模块的 git 超级项目，我试图锁定一个工作流程，以便我的项目成员的其余部分在其中工作。

对于这个问题，假设我的超级项目名为 supery ，子模块名为 subby 。 （然后是我想做的事情的简化......我实际上并没有使用版本分支，但我认为将其作为一个问题来布局是最简单的。）

我的 supery 的主分支 具有 git 项目 subby 的标签 v1.0 作为子模块引用。 supery 的分支调用了 one.one 并将子模块的引用更改为指向 subby< 的标签 v1.1 /代码>。

我可以在每个分支中顺利工作，但是如果我尝试使用 master 分支的更改来更新 one.one 分支，我会收到一些冲突，但我不这样做不知道如何解决它们。

基本上在运行 git pull 后。 master 而在 subby 分支中，看起来它创建了额外的子模块。

在拉取/合并之前，我从 one.one 分支的 git submodule 获得了所需的响应：

$ git checkout master
$ git submodule
qw3rty...321e subby (v1.0)
$ git checkout one.one
$ git submodule
asdfgh...456d subby (v1.1)

但是在拉取之后，当我运行 时，它会添加其他子模块git submodule：

$ git pull . master
Auto-merged schema
CONFLICT (submodule): Merge conflict in subby - needs qu3rty...321e
Automatic merge failed; fix conflicts and then commit the results.

$ git submodule
qw3rty...321e subby (v1.0)
asdfgh...456d subby (v1.1)
zxcvbn...7890 subby (v1.1~1)

如何删除/忽略不需要的子模块引用并提交我的冲突和更改？ 或者是否有一个参数可以与我原来的 git pull 一起使用，该参数会忽略我的子模块？

Answer 1

好吧，它在技术上并不能管理与子模块的冲突（即：保留这个而不是那个），但我找到了一种继续工作的方法......我所要做的就是注意我的 git 状态 输出并重置子模块：

git reset HEAD subby
git commit

这会将子模块重置为预拉提交。 在这种情况下这正是我想要的。 在其他情况下，我需要将更改应用于子模块，我将使用标准子模块工作流程（签出主模块、下拉所需标签等）来处理这些更改。

Answer 2

我对这个问题的答案有点挣扎，并且对 类似的 SO 帖子 也可以。 所以这对我有用 - 请记住，在我的情况下，子模块是由不同的团队维护的，因此冲突来自主模块和我正在处理的项目的本地分支中的不同子模块版本：

1. 运行 git status - 记下有冲突的子模块文件夹

2. 将子模块重置为当前分支中最后提交的版本：

   git reset HEAD path/to/submodule

3. 此时，您已经有了子模块的无冲突版本，您现在可以将其更新到子模块存储库中的最新版本：

   cd 路径/到/子模块 
     git submodule foreach git pull origin SUBMODULE-BRANCH-NAME

4. 现在您可以提交并返回工作。

Answer 3

我在使用 git rebase -i origin/master 到分支时遇到了这个问题。 我想采用子模块引用的主版本，所以我简单地执行了：

git reset master path/to/submodule

然后

git rebase --continue

这解决了问题我。

Answer 4

我以前没有见过那个确切的错误。 但我对你遇到的麻烦有一个猜测。 看起来是因为 supery 的 master 和 one.one 分支包含 subby 子模块的不同引用，当您合并来自 master 的更改，git 不知道 v1.0 或 v1.1 应该由 保留和跟踪哪个参考supery 的 >one.one 分支。

如果是这种情况，那么您需要选择所需的引用并提交更改以解决冲突。 这正是您使用 reset 命令所做的事情。

这是跟踪项目不同分支中子模块的不同版本的一个棘手方面。 但是子模块引用就像项目的任何其他组件一样。 如果两个不同的分支在连续合并后继续跟踪相同的相应子模块引用，那么 git 应该能够计算出该模式，而不会在将来的合并中引发合并冲突。 另一方面，如果频繁切换子模块引用，您可能不得不忍受大量冲突解决。

Answer 5

首先，找到您想要子模块引用的哈希值。 然后运行

~/supery/subby $ git co hashpointerhere
~/supery/subby $ cd ../
~/supery $ git add subby
~/supery $ git commit -m 'updated subby reference'

它，这对我有用，使我的子模块获得正确的哈希引用，并继续我的工作，而不会出现任何进一步的冲突。

Answer 6

从这次讨论中得到了帮助。
就我而言，这

git reset HEAD subby
git commit

对我有用:)

Answer 7

以上所有内容对我都不起作用......
我将子模块放在“未合并路径”下，然后我被卡住了......

最终经过多次尝试后，有效的是：
从子模块中手动删除合并冲突文件而不是在主存储库中：

git Restore --staged submodule_path 
  

（这将其移至“未暂存提交的更改：”）

<前><代码> git clean -df

然后

git子模块更新--init

Answer 8

好吧，在我的父目录中，我看到：

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)

所以我只是这样做了

git reset HEAD linux

Answer 9

如何解决与 git 子模块的冲突，在包含它们的外部存储库中

选项 1：

像 主要答案：

# run this for each conflicting submodule
git reset -- path/to/submodule

然后，完成后通过冲突解决，手动cd进入每个子模块，拉取或检查您想要的最新更改，然后cd备份到上层存储库，并运行git为每个子模块添加路径/到/子模块。

选项 2：

在上部（最外层）存储库中执行交互式变基：

# pull latest upstream main repo
git fetch origin main:main

# do interactive rebase onto it
git rebase -i main

在交互式变基文件编辑器中，手动删除更新子模块的所有提交。 完成变基。

完成后，手动cd进入每个子模块，拉取或检查您想要的最新更改，然后cd备份到上层存储库，并运行git add path /to/submodule 对于您想要更新为最新更改的每个子模块。

完毕。

另请参阅：

1. 我对 如何更新存储库中的所有 git 子模块的回答（两种方法可以执行两个非常不同的东西！）

Answer 10

如果你想使用上游版本：

rm -rf <submodule dir>
git submodule init
git submodule update

Answer 11

如果有人重新定位并在子模块存储库中进行了 git push --force ，则

git submodule update --remote --checkout -f