当我拉出一个Git子模块repo及其封闭的repo时,为什么我要进行本地更改?

时间:2016-10-19 06:23:51

标签: git version-control git-submodules

假设我有一个Git repo R,它的子目录是子模块rep,SR。

在机器A上,我对SR进行了更改。我承诺/推他们。如果我向上移动到父目录,git status将显示存在本地更改。这(据我所知)是因为gitlink已更新,因为subrepo已更改,这需要提交并签入。所以我执行提交并推送。

在机器B上,我转到SR目录并执行git pull。然后我转到repo R中的封闭文件夹(也在机器B上)并执行git pull。

尽管在机器B上没有进行本地更改,但git status将报告subrepo具有(新提交),即它似乎期望我提交这些新的更改。但为什么?这些“变化”对谁有利?我可以理解SR的变化构成R的变化。但是如果我把两者都拉到B上,为什么我不能100%更新,为什么我显然有自己的局部变化需要承诺?

2 个答案:

答案 0 :(得分:1)

  

我可以理解SR的变化构成R的变化。

这是因为R将SR引用为父代表的 gitlink special entry in the index),代表SR的新SHA1。

如果您希望其他人克隆R以在右侧SHA1返回SR,则需要添加,提交和推送该新条目。

这意味着在B上,您不必从SR执行git pull:它应该已经在正确的提交中检出。

  

如果我执行拉R,为什么这不会自动执行子模块更新?为什么这需要单独行动?当我执行拉动时,SR的gitlink不是R状态的一部分会更新吗?

因为R的拉动只会更新SR gitlink,而不是实际签出的子模块SR

注意:如果您总是需要在子模块中进行拉动,则可以改为make sure SR follows its own master branch

cd /path/to/your/parent/repo
git config -f .gitmodules submodule.<path>.branch <branch>

这样,一个简单的git submodule update --remote足以从SR提取和更新R。 像往常一样,如果SR更新其HEAD,则需要添加,提交并从R推送新的gitlink。

答案 1 :(得分:0)

子模块功能允许您不仅依赖于另一个git仓库,而且还依赖于此仓库的某个提交。

当您拉动子模块时,您执行的操作严格限于子模块的git clone。 当您执行git pull时,您需要将子模块更新为最新版本。

回到封闭的仓库,即使用较旧版本的子模块,git会认为你想要将子公司更新到最新版本(因为你用git pull做了什么)。

进入封闭式仓库后,您需要执行以下操作:

$ git submodule update

将子模块重置为封闭git repo的HEAD所依赖的状态。

这也是每次在封闭式仓库中切换分支时可能需要做的事情,因为每个分支可能依赖于子模块的不同版本。

相关问题