将Git子模块更新为最新的原始提交


Update Git submodule to latest commit on origin

我有一个带有Git子模块的项目。 它来自ssh：// ... URL，并且在提交A.提交B已被推送到该URL，我希望子模块检索提交，并更改为它。

现在，我的理解是git submodule update应该这样做，但事实并非如此。 它没有做任何事情(没有输出，成功退出代码)。 这是一个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
$ mkdir foo
$ cd foo
$ git init .
Initialized empty Git repository in /.../foo/.git/
$ git submodule add ssh://user@host/git/mod mod
Cloning into mod...
user@host's password: hunter2
remote: Counting objects: 131, done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 131 (delta 54), reused 0 (delta 0)
Receiving objects: 100% (131/131), 16.16 KiB, done.
Resolving deltas: 100% (54/54), done.
$ git commit -m"Hello world."
[master (root-commit) 565b235] Hello world.
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 .gitmodules
 create mode 160000 mod
# At this point, ssh://user@host/git/mod changes; submodule needs to change too.
$ git submodule init
Submodule 'mod' (ssh://user@host/git/mod) registered for path 'mod'
$ git submodule update
$ git submodule sync
Synchronizing submodule url for 'mod'
$ git submodule update
$ man git-submodule
$ git submodule update --rebase
$ git submodule update
$ echo $?
0
$ git status
# On branch master
nothing to commit (working directory clean)
$ git submodule update mod
$ ...

我也尝试了git fetch mod，它似乎进行了一次获取(但不可能，因为它没有提示输入密码！)，但git log和git show否认存在新的提交。 到目前为止，我只是rm - 模块并重新添加它，但这在原则上是错误的，在实践中是乏味的。

相关讨论

git submodule update命令实际上告诉Git你希望每个子模块检出已经在超级项目的索引中指定的提交。如果要将子模块更新为其远程可用的最新提交，则需要在子模块中直接执行此操作。

总结如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Get the submodule initially
git submodule add ssh://bla submodule_dir
git submodule init

# Time passes, submodule upstream is updated
# and you now want to update

# Change to the submodule directory
cd submodule_dir

# Checkout desired branch
git checkout master

# Update
git pull

# Get back to your project root
cd ..

# Now the submodules are in the state you want, so
git commit -am"Pulled down update to submodule_dir"

或者，如果你是一个忙碌的人：

1
git submodule foreach git pull origin master
相关讨论

Git 1.8.2具有一个新选项--remote，可以实现这种行为。运行

1
git submodule update --remote --merge

将从每个子模块的上游获取最新的更改，将它们合并，并检查子模块的最新版本。正如文档所说：

--remote

This option is only valid for the update command. Instead of using the superproject’s recorded SHA-1 to update the submodule, use the status of the submodule’s remote-tracking branch.

这相当于在每个子模块中运行git pull，这通常正是您想要的。

相关讨论

在项目父目录中，运行：

1
git submodule update --init

或者如果你有递归子模块运行：

1
git submodule update --init --recursive

有时这仍然不起作用，因为在更新子模块时，您在本地子模块目录中以某种方式进行了本地更改。

大多数情况下，本地更改可能不是您要提交的更改。它可能由于子模块中的文件删除等原因而发生。如果是这样，请在本地子模块目录和项目父目录中重置，再次运行：

1
git submodule update --init --recursive
相关讨论

您的主项目指向子模块应该处于的特定提交。 git submodule update尝试检查已初始化的每个子模块中的提交。子模块实际上是一个独立的存储库 - 只是在子模块中创建一个新的提交并推送它是不够的。您还需要在主项目中显式添加新版本的子模块。

所以，在你的情况下，你应该在子模块中找到正确的提交 - 让我们假设这是master的提示：

1
2
3
cd mod
git checkout master
git pull origin master

现在回到主项目，暂存子模块并提交：

1
2
3
cd ..
git add mod
git commit -m"Updating the submodule 'mod' to the latest version"

现在推送您的新版主项目：

1
git push origin master

从这一点开始，如果其他人更新了他们的主项目，那么git submodule update对于他们将更新子模块，假设它已被初始化。

在这个讨论中似乎将两种不同的场景混合在一起：

场景1

使用我的父存储库指向子模块的指针，我想检查父存储库指向的每个子模块中的提交，可能是在首次迭代所有子模块并从远程更新/拉取这些子模块之后。

正如所指出的那样，这是完成的

1
2
git submodule foreach git pull origin BRANCH
git submodule update

场景2，我认为是OP的目标

在一个或多个子模块中发生了新的事情，我想1)拉出这些变化，2)更新父存储库以指向这个/这些子模块的HEAD(最新)提交。

这将通过以下方式完成

1
2
3
4
5
6
git submodule foreach git pull origin BRANCH
git add module_1_name
git add module_2_name
......
git add module_n_name
git push origin BRANCH

不太实用，因为你必须硬编码所有n个子模块的n个路径。用于更新父存储库的提交指针的脚本。

通过每个子模块进行自动迭代，更新父存储库指针(使用git add)指向子模块的头部将会很酷。

为此，我制作了这个小的Bash脚本：

git-update-submodules.sh

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#!/bin/bash

APP_PATH=$1
shift

if [ -z $APP_PATH ]; then
  echo"Missing 1st argument: should be path to folder of a git repo";
  exit 1;
fi

BRANCH=$1
shift

if [ -z $BRANCH ]; then
  echo"Missing 2nd argument (branch name)";
  exit 1;
fi

echo"Working in: $APP_PATH"
cd $APP_PATH

git checkout $BRANCH && git pull --ff origin $BRANCH

git submodule sync
git submodule init
git submodule update
git submodule foreach"(git checkout $BRANCH && git pull --ff origin $BRANCH && git push origin $BRANCH) || true"

for i in $(git submodule foreach --quiet 'echo $path')
do
  echo"Adding $i to root repo"
  git add"$i"
done

git commit -m"Updated $BRANCH branch of deployment repo to point to latest head of submodules"
git push origin $BRANCH

要运行它，请执行

1
git-update-submodules.sh /path/to/base/repo BRANCH_NAME

精

首先，我假设所有存储库中都存在名为$ BRANCH(第二个参数)的分支。随意使这更复杂。

前几节是检查参数是否存在的一些部分。然后我拉出父存储库的最新东西(我更喜欢使用--ff(快速转发)，每当我做拉动时。我已经关闭了，BTW)。

1
git checkout $BRANCH && git pull --ff origin $BRANCH

如果新的子模块已添加或尚未初始化，则可能需要进行一些子模块初始化：

1
2
3
git submodule sync
git submodule init
git submodule update

然后我更新/拉取所有子模块：

1
git submodule foreach"(git checkout $BRANCH && git pull --ff origin $BRANCH && git push origin $BRANCH) || true"

请注意以下几点：首先，我使用&&链接一些Git命令 - 意味着上一个命令必须执行而不会出错。

在可能的成功拉动之后(如果在远程上找到了新的东西)，我会进行推送以确保在客户端上不会留下可能的合并提交。再一次，它只会在拉动实际引入新东西时发生。

最后，最后的|| true确保脚本继续出错。为了实现这一点，迭代中的所有内容都必须用双引号括起来，Git命令用括号括起来(运算符优先级)。

我最喜欢的部分：

1
2
3
4
5
for i in $(git submodule foreach --quiet 'echo $path')
do
  echo"Adding $i to root repo"
  git add"$i"
done

迭代所有子模块 - 使用--quiet，这将删除'Entering MODULE_PATH'输出。使用'echo $path'(必须使用单引号)，子模块的路径将写入输出。

这个相对子模块路径列表在一个数组($(...))中捕获 - 最后迭代它并执行git add $i来更新父存储库。

最后，提交一些消息，说明父存储库已更新。如果没有做任何事情，默认情况下将忽略此提交。把它推到原点，你就完成了。

我有一个在Jenkins工作中运行它的脚本，之后链接到计划的自动部署，它就像一个魅力。

我希望这会对某人有所帮助。

相关讨论

简单明了，要获取子模块：

1
git submodule update --init --recursive

现在继续将它们更新到最新的主分支(例如)：

1
git submodule foreach git pull origin master

1
git pull --recurse-submodules

这将提取所有最新提交。

注意，虽然更新子模块提交的现代形式是：

1
git submodule update --recursive --remote --merge --force

较旧的形式是：

1
git submodule foreach --quiet git pull --quiet origin

除了......这第二种形式并不是真的"安静"。

见Nguy？nTháiNg？c Duy(pclouds)提交a282f5a(2019年4月12日)。
(由Junio C Hamano合并 - gitster - 在提交f1c9f6c，2019年4月25日)

submodule foreach: fix" --quiet" not being respected

Robin reported that

1
git submodule foreach --quiet git pull --quiet origin

is not really quiet anymore.
It should be quiet before fc1b924 (submodule: port submodule subcommand 'foreach' from shell to C, 2018-05-10, Git v2.19.0-rc0) because parseopt can't accidentally eat options then.

"git pull" behaves as if --quiet is not given.

This happens because parseopt in submodule--helper will try to parse
both --quiet options as if they are foreach's options, not git-pull's.
The parsed options are removed from the command line. So when we do
pull later, we execute just this

1
git pull origin

When calling submodule helper, adding"--" in front of"git pull" will
stop parseopt for parsing options that do not really belong to
submodule--helper foreach.

PARSE_OPT_KEEP_UNKNOWN is removed as a safety measure. parseopt should
never see unknown options or something has gone wrong. There are also
a couple usage string update while I'm looking at them.

While at it, I also add"--" to other subcommands that pass"$@" to
submodule--helper."$@" in these cases are paths and less likely to be
--something-like-this.
But the point still stands, git-submodule has parsed and classified what are options, what are paths.
submodule--helper should never consider paths passed by git-submodule to be options even if they look like one.

并且Git 2.23(Q3 2019)修复了另一个问题：当使用"--recursive"选项时，"git submodule foreach"不保护传递给命令的命令行选项在每个子模块中正确运行。

参见由Morian Sonnet(momoson)提交的30db18b(2019年6月24日)。
(由Junio C Hamano合并 - gitster - 在提交968eecb，2017年7月9日)

submodule foreach: fix recursion of options

Calling:

1
git submodule foreach --recursive <subcommand> --<option>

leads to an error stating that the option -- is unknown to
submodule--helper.
That is of course only, when is not a valid option for git submodule foreach.

The reason for this is, that above call is internally translated into a
call to submodule--helper:

1
2
git submodule--helper foreach --recursive \
    -- <subcommand> --<option>

This call starts by executing the subcommand with its option inside the
first level submodule and continues by calling the next iteration of
the submodule foreach call

1
2
git --super-prefix <submodulepath> submodule--helper \
   foreach --recursive <subcommand> --<option>

inside the first level submodule. Note that the double dash in front of
the subcommand is missing.

This problem starts to arise only recently, as the PARSE_OPT_KEEP_UNKNOWN flag for the argument parsing of git submodule foreach was removed in commit a282f5a.
Hence, the unknown option is complained about now, as the argument parsing is not properly ended by the double dash.

This commit fixes the problem by adding the double dash in front of the subcommand during the recursion.

@Jason在某种程度上是正确的，但并非完全正确。

update

Update the registered submodules,
i.e. clone missing submodules and
checkout the commit specified in the
index of the containing repository.
This will make the submodules HEAD be
detached unless --rebase or --merge is
specified or the key
submodule.$name.update is set to
rebase or merge.

因此，git submodule update执行checkout，但它是在包含存储库的索引中的提交。它根本不知道上游的新提交。因此，转到您的子模块，获取所需的提交并在主存储库中提交更新的子模块状态，然后执行git submodule update。

相关讨论

就我而言，我希望git更新到最新版本，同时重新填充任何丢失的文件。

以下恢复了丢失的文件(感谢--force，这里似乎没有提到)，但它没有提取任何新的提交：

git submodule update --init --recursive --force

这样做：

git submodule update --recursive --remote --merge --force

如果您不知道主机分支，请执行以下操作：

1
git submodule foreach git pull origin $(git rev-parse --abbrev-ref HEAD)

它将获得主Git存储库的一个分支，然后为每个子模块将拉动相同的分支。

这是一个很棒的单行程序，可以将所有内容更新为最新的主服务器：

1
git submodule foreach 'git fetch origin --tags; git checkout master; git pull' && git pull && git submodule update --init --recursive

感谢Mark Jaquith