当前位置：文江博客话题详情

我如何“承诺”？ git 子模块发生变化？

发布于 2024-10-30 01:30:32 字数 153 浏览 1 评论 0原文

我天真地设置了一个 git 子模块并将其视为 Subversion 外部 - 即它现在充满了我刚刚意识到尚未提交或推送到任何地方的更改。

是否有一些简单的方法可以将子模块更改提交/推送回上游存储库？ Git 中推荐的以这种方式在单独（但链接）存储库上进行同步开发的技术是什么？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

痞味浪人 2024-11-06 01:30:32

子模块是它自己的存储库/工作区，有自己的.git 目录。

因此，首先提交/推送您的子模块更改：

$ cd path/to/submodule
$ git add <stuff>
$ git commit -m "comment"
$ git push

然后，更新您的主项目 跟踪子模块的更新版本：

$ cd /main/project
$ git add path/to/submodule
$ git commit -m "updated my submodule"
$ git push

A submodule is its own repo/work-area, with its own .git directory.

So, first commit/push your submodule's changes:

$ cd path/to/submodule
$ git add <stuff>
$ git commit -m "comment"
$ git push

Then, update your main project to track the updated version of the submodule:

$ cd /main/project
$ git add path/to/submodule
$ git commit -m "updated my submodule"
$ git push

回复收藏 0 原文

习惯那些不曾习惯的习惯 2024-11-06 01:30:32

请注意，如果您在各个子模块中提交了一系列更改，您可以（或很快能够）一次性推送所有内容（即来自父模块的一次推送repo），其中：

git push --recurse-submodules=on-demand

git1.7.11（[公告] Git 1.7.11.rc1) 提到：

“git push --recurse-submodules”学会了选择性地查看绑定到超级项目的子模块的历史并将它们推出。

可能是在此补丁和 --on-demand 选项：

--recurse-submodules=<check|on-demand|no>::

确保要推送的修订版本使用的所有子模块提交在远程跟踪分支上可用。
如果使用check，则会检查要推送的修订版本中更改的所有子模块提交是否在远程上可用。
否则推送将被中止并以非零状态退出。
如果使用on-demand，则将推送要推送的修订版本中更改的所有子模块。
如果 on-demand 无法推送所有必要的修订，它也将被中止并以非零状态退出。

此选项仅适用于一层嵌套。对另一个子模块内部的子模块的更改不会被推送。

Note that if you have committed a bunch of changes in various submodules, you can (or will be soon able to) push everything in one go (ie one push from the parent repo), with:

git push --recurse-submodules=on-demand

git1.7.11 ([ANNOUNCE] Git 1.7.11.rc1) mentions:

"git push --recurse-submodules" learned to optionally look into the histories of submodules bound to the superproject and push them out.

Probably done after this patch and the --on-demand option:

--recurse-submodules=<check|on-demand|no>::

Make sure all submodule commits used by the revisions to be pushed are available on a remote tracking branch.
If check is used, it will be checked that all submodule commits that changed in the revisions to be pushed are available on a remote.
Otherwise the push will be aborted and exit with non-zero status.
If on-demand is used, all submodules that changed in the revisions to be pushed will be pushed.
If on-demand was not able to push all necessary revisions it will also be aborted and exit with non-zero status.

This option only works for one level of nesting. Changes to the submodule inside of another submodule will not be pushed.

回复收藏 0 原文

绿萝 2024-11-06 01:30:32

$ git submodule status --recursive

在这种情况下也是救命稻草。您可以使用它和 gitk --all 来跟踪您的 sha1 并验证您的子模块是否指向您认为的内容。

$ git submodule status --recursive

Is also a life saver in this situation. You can use it and gitk --all to keep track of your sha1's and verify your sub-modules are pointing at what you think they are.

回复收藏 0 原文