我有以下存储库布局：
Repo
|-- Folder1
| |-- file1
| |-- file2
| ...
|-- Folder2
| |-- file3
| |-- file4
| ...
|-- file5
|-- file6
...
其中'Repo'是主存储库，'Folder1'和'Folder2'是两个子模块。
使用根目录（示例中的file5，file6）是直截了当的，但我对如何正确推送您在子模块中修改的项目有疑问。
现在我正在编辑每个子模块中的文件，提交每个更改并将其推送到本地：
[Repo]$ cd Folder1
[Folder1]$ vi file1
... do some changes ...
[Folder1]$ git add file1
[Folder1]$ git commit -m "Some changes"
[Folder1]$ git push
如果我直接检查子模块上的git状态，它会输出它是最新的：
[Folder1]$ git status
# On branch master
nothing to commit, working directory clean
但是如果我检查根文件夹中的状态，它会告诉我我已经推送的子模块有新的提交。
[Folder1]$ cd ..
[Repo]$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: Folder1 (new commits)
#
no changes added to commit (use "git add" and/or "git commit -a")
如果我错了，请纠正我，但我想上面是由于git检查当前本地repo提交ID与我推送到的git服务器中的信息。所以，我现在实际做的是全部提交并在主回购中推送它。这是使用子模块的正确方法吗？
答案 0 :(得分：1)
[Repo]$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: Folder1 (new commits)
#
no changes added to commit (use "git add" and/or "git commit -a")
以上是由于父存储库Repo指向较早的Folder1子模块提交。
对于您的另一个问题，是的，这是使用子模块的正确方法。
通过这种方式，您不会冒险将悬空子模块引用（即父存储库中的引用）推送到未被推送的子模块中的提交。
请注意，在父存储库中，您不必强制提交并推送每个子模块更新。其他用户可以在子模块的master分支中工作，并执行标准git fetch / git pull下载新修订。
当我要发布该子模块的新版本时，我个人只提交对子模块的引用，以在父存储库中标记该版本。我的子模块是应用程序，父存储库是共享库。
答案 1 :(得分：0)
我现在实际做的是提交所有内容并将其推送到主回购中。
如果你的意思是“将每个子模块添加到根的索引并提交/推根”，那么你是对的。
原因是子模块被认为是与主模块完全独立的项目。 Git允许您指定子模块应该处于的确切提交哈希值;这允许您严格控制主项目使用的子项目的版本。更新子项目时，必须手动更新主项目中引用的提交（并推送该提交）。
注意，不提交并推送对您不打算公开的子模块提交的引用！这将通过引用他们无法访问的工作来阻碍其他开发人员。另外，正如已经指出的那样，每次对子模块进行更改时，只有当子模块达到新的稳定状态时，才需要将子模块提交并推送到主项目。
答案 2 :(得分：0)
通过这种方式，您不会冒险推送悬空的子模块引用，即父存储库中的引用到尚未推送的子模块中的提交。
更确切地说，您可以在 Git 2.31（2021 年第一季度）中使用 git fsck：出于性能原因，在“index-pack”中“fsck”传入对象的方法很有吸引力（我们已经将它们放在核心中，膨胀并准备好接受检查），但是当我们接收到多个包流时，从根本上不能完全应用，因为一个包中的树对象可能会将另一个包中的 blob 对象称为“.gitmodules”，当我们想要例如，检查用作“.gitmodules”文件的 blob。
教“index-pack”发出稍后必须检查的对象，并在调用“fetch-pack”过程中检查它们。
请参阅 commit 5476e1e 的 commit b664e9f、commit 27e35ba、commit 726b25a、Jonathan Tan (jhowtan)（2021 年 2 月 22 日）。
（由 Junio C Hamano -- gitster -- 于 commit 6ee353d 合并，2021 年 3 月 1 日）
fetch-pack：打印并使用悬空的 .gitmodules签字人：Jonathan Tan
<块引用>教 index-pack 在“keep”或“pack”行之后打印悬空的 .gitmodules 链接而不是声明错误，并教 fetch-pack 检查打印的这些行。
这允许 .gitmodules 链接的树侧位于一个包文件中，而 blob 侧位于另一个包文件中，而不会使 fsck 检查失败，因为现在是 fetch-pack 在所有包文件都具有后检查此类对象已下载并编入索引（而不是在单个包文件上进行索引包，就像这次提交之前一样）。
git index-pack 现在包含在其 man page 中：
仅供内部使用。
如果包里有破损的东西，就会死。如果包中包含一棵树
指向一个不存在的 .gitmodules blob，打印散列
进入哈希后的那个 blob（供调用者检查）
pack/idx 文件的名称（请参阅“注释”）。
Git 2.32（2021 年第 2 季度）使这一点更加强大：
见commit 3745e26、commit c96e184、commit 462f5ca、commit c15087d、commit 53692df、commit 394d5d3、commit 44e07da、{{3} }, commit 901f2f6, commit b549502, commit c72da1a, commit 30cf618, commit 1b32b59, commit e35d65a, commit 35af754, commit 034a7b7, commit f1abc2d、commit a1aad71（2021 年 3 月 28 日）和 commit d385784（2021 年 3 月 17 日）由 commit fb79f5b.
（由 Ævar Arnfjörð Bjarmason (avar) 于 Junio C Hamano -- gitster -- 合并，2021 年 4 月 7 日）
签字人：Ævar Arnfjörð Bjarmason
<块引用>重构 fetch-pack ("fetch-pack: print and use dangling .gitmodules", 2021-02-22, Git v2.31.0-rc1 -- {{3} }) 利用我们现在将 "msg_id" 传递给用户定义的 "error_func"。
我们现在可以与 FSCK_MSG_GITMODULES_MISSING 进行比较，而不是解析生成的消息。