git 克隆_Git克隆一个带子模块的项目

这里你将克隆一个带子模块的项目。当你接收到这样一个项目，你将得到了包含子项目的目录，但里面没有文件：

$ git clone git://github.com/schacon/myproject.gitInitialized empty Git repository in /opt/myproject/.git/    remote: Counting objects: 6, done.    remote: Compressing objects: 100% (4/4), done.    remote: Total 6 (delta 0), reused 0 (delta 0)Receiving objects: 100% (6/6), done.    $ cd myproject    $ ls -l    total 8-rw-r--r-- 1 schacon admin 3 Apr 9 09:11 README    drwxr-xr-x 2 schacon admin 68 Apr 9 09:11 rack    $ ls rack/    $

rack目录存在了，但是是空的。你必须运行两个命令：git submodule init来初始化你的本地配置文件，git submodule update来从那个项目拉取所有数据并检出你上层项目里所列的合适的提交：

$ git submodule initSubmodule 'rack' (git://github.com/chneukirchen/rack.git) registered for path 'rack'    $ git submodule updateInitialized empty Git repository in /opt/myproject/rack/.git/    remote: Counting objects: 3181, done.    remote: Compressing objects: 100% (1534/1534), done.    remote: Total 3181 (delta 1951), reused 2623 (delta 1603)Receiving objects: 100% (3181/3181), 675.42 KiB | 173 KiB/s, done.Resolving deltas: 100% (1951/1951), done.Submodule path 'rack': checked out '08d709f78b8c5b0fbeb7821e37fa53e69afcf433'

现在你的rack子目录就处于你先前提交的确切状态了。如果另外一个开发者变更了 rack 的代码并提交，你拉取那个引用然后归并之，将得到稍有点怪异的东西：

$ git merge origin/masterUpdating 0550271..85a3eeeFast forward    rack | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)[master*]$ git status# On branch master# Changes not staged for commit:# (use "git add ..." to update what will be committed)# (use "git checkout -- ..." to discard changes in working directory)## modified: rack#

你归并来的仅仅上是一个指向你的子模块的指针；但是它并不更新你子模块目录里的代码，所以看起来你的工作目录处于一个临时状态：

$ git diff    diff --git a/rack b/rack    index 6c5e70b..08d709f 160000--- a/rack+++ b/rack@@ -1 +1 @@-Subproject commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433

事情就是这样，因为你所拥有的指向子模块的指针和子模块目录的真实状态并不匹配。为了修复这一点，你必须再次运行git submodule update：

$ git submodule update    remote: Counting objects: 5, done.    remote: Compressing objects: 100% (3/3), done.    remote: Total 3 (delta 1), reused 2 (delta 0)Unpacking objects: 100% (3/3), done.From git@github.com:schacon/rack08d709f..6c5e70b master -> origin/masterSubmodule path 'rack': checked out '6c5e70b984a60b3cecd395edd5b48a7575bf58e0'

每次你从主项目中拉取一个子模块的变更都必须这样做。看起来很怪但是管用。

一个常见问题是当开发者对子模块做了一个本地的变更但是并没有推送到公共服务器。然后他们提交了一个指向那个非公开状态的指针然后推送上层项目。当其他开发者试图运行git submodule update，那个子模块系统会找不到所引用的提交，因为它只存在于第一个开发者的系统中。如果发生那种情况，你会看到类似这样的错误：

$ git submodule update    fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0Unable to checkout '6c5e70b984a60b3cecd395edd5ba7575bf58e0' in submodule path 'rack'

你不得不去查看谁最后变更了子模块

$ git log -1 rack    commit 85a3eee996800fcfa91e2119372dd4172bf76678Author: Scott Chacon <schacon@gmail.com>Date: Thu Apr 9 09:19:14 2009 -0700    added a submodule reference I will never make public. hahahahaha!

然后，你给那个家伙发电子邮件说他一通。

！爆享折扣！

▼▼▼ 原价129， 今日拼团仅需 ¥99！ 新人专享首单限时优惠 ¥19.9！！！ 但！ 仅限前100个名额！ ???