git git子模块提交/推/拉

git submodule commit/push/pull

提问by eugene

I'd like to use git submodule.

我想使用 git 子模块。

The steps I need to take to push my changes to my project are

我需要采取的步骤将我的更改推送到我的项目是

1. add/commit/push from submodule directory
2. add/commit/push from parent directory

1. 从子模块目录添加/提交/推送
2. 从父目录添加/提交/推送

Steps I need to take to pull changes of my project.

我需要采取的步骤来拉动我的项目的更改。

1. git pull from parent directory
2. git submodule update from parent directory

1. 从父目录git pull
2. 来自父目录的 git 子模块更新

Steps for updating the submodule from its original repo

从原始存储库更新子模块的步骤

1. git pull from submodule directory

1. 从子模块目录中 git pull

What worries me is the following exerpt from http://git-scm.com/book/en/Git-Tools-Submodules

让我担心的是以下摘录自http://git-scm.com/book/en/Git-Tools-Submodules

The issue is that you generally don't want to work in a detached HEAD environment, because it's easy to lose changes. If you do an initial submodule update, commit in that submodule directory without creating a branch to work in, and then run git submodule update again from the superproject without committing in the meantime,(?? update/commit/update will lose change?) Git will overwrite your changes without telling you. Technically you won't lose the work, but you won't have a branch pointing to it, so it will be somewhat difficult to retrieve.

To avoid this issue, create a branch when you work in a submodule directory with git checkout -b work or something equivalent. When you do the submodule update a second time, it will still revert your work, but at least you have a pointer to get back to.

问题是您通常不想在分离的 HEAD 环境中工作，因为很容易丢失更改。如果您进行初始子模块更新，请在该子模块目录中提交而不创建要工作的分支，然后从超级项目再次运行 git submodule update 而不在此期间提交，（?? update/commit/update 将丢失更改？） Git 会在不通知您的情况下覆盖您的更改。从技术上讲，您不会丢失工作，但是您不会有指向它的分支，因此检索起来会有些困难。

为避免此问题，请在使用 git checkout -b work 或等效命令在子模块目录中工作时创建一个分支。当您第二次更新子模块时，它仍然会恢复您的工作，但至少您有一个可以返回的指针。

I'm going to modify submodules and don't wanna mess up, the doc above briefly mentions the possibility of losing change, and I don't understand what might cause the loss.

我要修改子模块，不想搞砸，上面的文档简要提到了丢失更改的可能性，我不明白可能导致丢失的原因。

I wonder what additional steps more than I listed above I need to take to prevent the loss. Especially several team members modify submodules, what do they need to do not to mess up?

我想知道除了上面列出的之外，我还需要采取哪些额外的步骤来防止损失。尤其是几个团队成员修改子模块，需要怎么做才不会乱？

回答by Aaron Newton

I'd like to share my experiences with you as someone who works with external projects in Visual Studio solutions trying to solve a similar problem. I'm relatively new to git, so if anyone has any constructive criticism I would appreciate that.

作为在 Visual Studio 解决方案中处理外部项目并试图解决类似问题的人，我想与您分享我的经验。我对 git 比较陌生，所以如果有人有任何建设性的批评，我将不胜感激。

If you're using Visual Studio, the Git Source Control Provider extension is free (http://visualstudiogallery.msdn.microsoft.com/63a7e40d-4d71-4fbb-a23b-d262124b8f4c), and seemed to recursively commit submodules when I tested it out.

如果您使用的是 Visual Studio，则 Git 源代码控制提供程序扩展是免费的（http://visualstudiogallery.msdn.microsoft.com/63a7e40d-4d71-4fbb-a23b-d262124b8f4c），并且在我测试时似乎递归提交子模块出去。

HOWEVER I'm using VS Web Developer Express at home for development, so I don't want to rely on an extension (I also think it's good to have some idea of what's happening under the hood). Therefore I've been forced to figure out the commands, and I've added some notes below.

然而，我在家里使用 VS Web Developer Express 进行开发，所以我不想依赖扩展（我也认为了解幕后发生的事情很好）。因此，我被迫弄清楚命令，并在下面添加了一些注释。

NOTES

笔记

If you haven't done already, have a thorough read through http://git-scm.com/book/en/Git-Tools-Submodules. There are quite a few caveats, and I will refer back to this page. If you try to work with submodules without reading this, you will give yourself a headache very quickly.

如果您还没有完成，请仔细阅读http://git-scm.com/book/en/Git-Tools-Submodules。有很多警告，我会回到这个页面。如果你在没有阅读本文的情况下尝试使用子模块，你会很快让自己头疼。

My approach follows this tutorial, with a few added extras: http://blog.endpoint.com/2010/04/git-submodule-workflow.html

我的方法遵循本教程，并添加了一些额外内容：http: //blog.endpoint.com/2010/04/git-submodule-workflow.html

Once you have your superproject initialised (e.g. git init&& git remote add origin ...), start adding your submodules like so:

初始化超级项目（例如git init&& git remote add origin ...）后，开始添加子模块，如下所示：

git submodule add git://github.com/you/extension1.git extension
git submodule init
git submodule update

Check that your .gitmodules file reflects this addition, e.g.

检查您的 .gitmodules 文件是否反映了此添加，例如

[submodule "extension1"]
        path = extension
        url = git://github.com/you/extension1.git

Switch to your submodule directory (i.e. cd extension). Run:

切换到您的子模块目录（即cd extension）。跑：

git fetch #I use fetch here - maybe you can use pull?
git checkout -b somebranchname #See the Git-Tools-Submodules link above for an explanation of why you need to branch

I made a change here to README.txt so I could commit it (also so I would have a record of what I was doing in this commit), then commited the module to apply the branch (still within the submodule directory):

我在这里对 README.txt 进行了更改，以便我可以提交它（也因此我会记录我在此提交中所做的事情），然后提交模块以应用分支（仍在子模块目录中）：

git add .
git commit -a -m "Branching for extension submodule"

Now go into the superproject (i.e. cd ..). You will also need to commit here (if you look at the git submodule page I mentioned it explains why this is necessary):

现在进入超级项目（即cd ..）。您还需要在此处提交（如果您查看我提到的 git 子模块页面，它解释了为什么这是必要的）：

git status #will show you that your submodule has been modified
git commit -a -m "Commiting submodule changes from superproject"

Now we can recusively push our projects like so if required:

现在，如果需要，我们可以像这样递归地推送我们的项目：

git push --recurse-submodules=on-demand

You will need to run through the above steps once for all your submodules.

您需要对所有子模块执行一次上述步骤。

Once you have done this for all your submodules and started making changes you want to commit and push, you can use:

为所有子模块完成此操作并开始进行要提交和推送的更改后，您可以使用：

git submodule foreach 'git add .' #recursively add files in submodules

Unfortunaly I haven't found a way to recursively commit without using something like git-slave(anyone?), so you then need to go into each submodule directory and run a regular commit for the files you just added. In the superproject:

不幸的是，我还没有找到一种不使用git-slave（任何人？）之类的东西来递归提交的方法，因此您需要进入每个子模块目录并为您刚刚添加的文件运行常规提交。在超级项目中：

git status #tells you that `extension` submodule has been modified
cd extension
git commit -a -m "Commiting extension changes in superproject edit session"

Once the submodule is commiting, you'll also need to commit the superproject (again), so:

一旦子模块提交，您还需要（再次）提交超级项目，因此：

cd ..
git add .
git commit -a -m "Altered extension submodule"
git status #should now show 'working directory clean', otherwise commit other submodules in the same manner

This can get slightly annoying (because you end up committing twice), but once you're aware of it it's actually not so bad (as it forces you to check what you're committing in each project). Just my opinion - if you've isolated some of your superproject's functionality into submodules, it should work in isolation from the rest of your projects anyway (so commiting them at different times while annoying is not the end of the world).

这可能会有点烦人（因为你最终提交了两次），但是一旦你意识到它实际上并没有那么糟糕（因为它迫使你检查你在每个项目中提交的内容）。只是我的意见 - 如果你已经将你的超级项目的一些功能隔离到子模块中，它应该与你的项目的其余部分隔离开来（所以在不同的时间提交它们而烦人并不是世界末日）。

Now we can push once more...

现在我们可以再推一次...

git push --recurse-submodules=on-demand

If you then descend into your submodule and try and push again, you'll find it won't do anything as the latest commit has already been pushed.

如果你随后进入你的子模块并再次尝试推送，你会发现它不会做任何事情，因为最新的提交已经被推送了。

Cloning (or using a remote origin) for a superproject can also be quite confusing - such as the need to run git submodule updatetwice after git submodule init. Read the 'Cloning a Project with Submodules' section of http://git-scm.com/book/en/Git-Tools-Submodules.

超级项目的克隆（或使用远程源）也可能非常混乱 - 例如需要git submodule update在git submodule init. 阅读http://git-scm.com/book/en/Git-Tools-Submodules 的“使用子模块克隆项目”部分。

Something that caught me out when cloning my superproject was getting the latest changes for the submodules. See Easy way pull latest of all submodules

克隆我的超级项目时让我感到惊讶的是获取子模块的最新更改。请参阅简单的方法拉取所有子模块的最新版本

My variant of this is to use a 'development' branch for checked out submodules (but you can call it whatever you want) and then use this in the superproject:

我的变体是使用“开发”分支来检出子模块（但你可以随意调用它），然后在超级项目中使用它：

git submodule foreach git pull origin development

When I set this up I also swap to the branch I want to push my changes to on the checked out submodule like so:

当我设置它时，我也会切换到我想将我的更改推送到签出的子模块的分支，如下所示：

cd extension
git checkout -b development #This will tell you this is a new branch, but I believe this means a new branch of the local git repository - this will get pushed to the 'development' branch
#Make your changes, commit etc.

I can confirm that when I follow the above steps, changes to the submodules in a clone/remote origin project (when pushed) showed up in other clones/remote origins of the same project (not forgetting that last submodule pull command).

我可以确认，当我按照上述步骤操作时，克隆/远程源项目（推送时）中子模块的更改出现在同一项目的其他克隆/远程源中（不要忘记最后一个子模块 pull 命令）。

I hope that was of some use to you.

我希望这对你有用。