2.10. Git 克隆

到现在为止，读者已经零略到Git的灵活性以及健壮性。Git可以通过重置随意撤销提交，可以通过变基操作更改历史，可以随意重组提交，还可以通过reflog的记录纠正错误的操作。但是再健壮的版本库设计，也抵挡不了存储介质的崩溃。还有一点就是不要忘了Git版本库是躲在工作区根目录下的.git目录中，如果忘了这一点直接删除工作区，就会把版本库也同时删掉，悲剧就此发生。

“不要把鸡蛋装在一个篮子里”，是颠扑不破的安全法则。

在本章会学习到如何使用git clone命令建立版本库克隆，以及如何使用git push和git pull命令实现克隆之间的同步。

2.10.1. 鸡蛋不装在一个篮子里

Git的版本库目录和工作区在一起，因此存在一损俱损的问题，即如果删除一个项目的工作区，同时也会把这个项目的版本库删除掉。一个项目仅在一个工作区中维护太危险了，如果有两个工作区就会好很多。

上图中一个项目使用了两个版本库进行维护，两个版本库之间通过拉回（PULL）和/或推送（PUSH）操作实现同步。

• 版本库A通过克隆操作创建克隆版本库B。
• 版本库A可以通过推送（PUSH）操作，将新提交传递给版本库B；
• 版本库A可以通过拉回（PULL）操作，将版本库B中的新提交拉回到自身（A）。
• 版本库B可以通过拉回（PULL）操作，将版本库A中的新提交拉回到自身（B）。
• 版本库B可以通过推送（PUSH）操作，将新提交传递给版本库A；

Git使用git clone命令实现版本库克隆，主要有如下三种用法：

用法1: git clone <repository> <directory>
用法2: git clone --bare   <repository> <directory.git>
用法3: git clone --mirror <repository> <directory.git>

这三种用法的区别如下：

• 用法1将<repository>指向的版本库创建一个克隆到<directory>目录。目录<directory>相当于克隆版本库的工作区，文件都会检出，版本库位于工作区下的.git目录中。
• 用法2和用法3创建的克隆版本库都不含工作区，直接就是版本库的内容，这样的版本库称为裸版本库。一般约定俗成裸版本库的目录名以.git为后缀，所以上面示例中将克隆出来的裸版本库目录名写做<directory.git>。
• 用法3区别于用法2之处在于用法3克隆出来的裸版本对上游版本库进行了注册，这样可以在裸版本库中使用git fetch命令和上游版本库进行持续同步。
• 用法3只在 1.6.0 或更新版本的Git才提供。

Git的PUSH和PULL命令的用法相似，使用下面的语法：

git push [<remote-repos> [<refspec>]]
git pull [<remote-repos> [<refspec>]]

其中方括号的含义是参数可以省略，<remote-repos>是远程版本库的地址或名称，<refspec>是引用表达式，暂时理解为引用即可。在后面的章节再具体介绍PUSH和PULL命令的细节。

下面就通过不同的Git命令组合，掌握版本库克隆和镜像的技巧。

2.10.2. 对等工作区

不使用--bare或者--mirror创建出来的克隆包含工作区，这样就会产生两个包含工作区的版本库。这两个版本库是对等的，如下图。

这两个工作区本质上没有区别，但是往往提交是在一个版本（A）中进行的，另外一个（B）作为备份。对于这种对等工作区模式，版本库的同步只有一种可行的操作模式，就是在备份库（B）执行 git pull 命令从源版本库（A）拉回新的提交实现版本库同步。为什么不能从版本库A向版本库B执行 git push 的推送操作呢？看看下面的操作。

执行克隆命令，将版本库/path/to/my/workspace/demo克隆到/path/to/my/workspace/demo-backup。

$ git clone /path/to/my/workspace/demo /path/to/my/workspace/demo-backup
Cloning into /path/to/my/workspace/demo-backup...
done.

进入 demo 版本库，生成一些测试提交（使用--allow-empty参数可以生成空提交）。

$ cd /path/to/my/workspace/demo/
$ git commit --allow-empty -m "sync test 1"
[master 790e72a] sync test 1
$ git commit --allow-empty -m "sync test 2"
[master f86b7bf] sync test 2

能够在 demo 版本库向 demo-backup 版本库执行PUSH操作么？执行一下git push看一看。

$ git push /path/to/my/workspace/demo-backup
Counting objects: 2, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 274 bytes, done.
Total 2 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
To /path/to/my/workspace/demo-backup
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to '/path/to/my/workspace/demo-backup'

翻译成中文：

$ git push /path/to/my/workspace/demo-backup
...
对方说: 错了:
              拒绝更新已检出的分支 refs/heads/master 。
              缺省更新非裸版本库的当前分支是不被允许的，因为这将会导致
              暂存区和工作区与您推送至版本库的新提交不一致。这太古怪了。

              如果您一意孤行，也不是不允许，但是您需要为我设置如下参数：

                  receive.denyCurrentBranch = ignore|warn

              到 /path/to/my/workspace/demo-backup

 ! [对方拒绝] master -> master (分支当前已检出)
错误: 部分引用的推送失败了, 至 '/path/to/my/workspace/demo-backup'

从错误输出可以看出，虽然可以改变Git的缺省行为，允许向工作区推送已经检出的分支，但是这么做实在不高明。

为了实现同步，需要进入到备份版本库中，执行git pull命令。

$ git pull
From /path/to/my/workspace/demo
   6e6753a..f86b7bf  master     -> origin/master
Updating 6e6753a..f86b7bf
Fast-forward

在 demo-backup 版本库中查看提交日志，可以看到在 demo 版本库中的新提交已经被拉回到 demo-backup 版本库中。

$ git log --oneline -2
f86b7bf sync test 2
790e72a sync test 1

为什么执行 git pull 拉回命令没有像执行 git push 命令那样提供那么多的参数呢？

这是因为在执行git clone操作后，克隆出来的demo-backup版本库中对源版本库（上游版本库）进行了注册，所以当在 demo-backup 版本库执行拉回操作，无须设置上游版本库的地址。

在 demo-backup 版本库中可以使用下面的命令查看对上游版本库的注册信息：

$ cd /path/to/my/workspace/demo-backup
$ git remote -v
origin  /path/to/my/workspace/demo (fetch)
origin  /path/to/my/workspace/demo (push)

实际注册上游远程版本库的奥秘都在Git的配置文件中（略去无关的行）：

$ cat /path/to/my/workspace/demo-backup/.git/config
...
[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = /path/to/my/workspace/demo
[branch "master"]
        remote = origin
        merge = refs/heads/master

关于配置文件[remote]小节和[branch]小节的奥秘在后面的章节予以介绍。

2.10.3. 克隆生成裸版本库

上一节在对等工作区模式下，工作区之间执行推送，可能会引发大段的错误输出，如果采用裸版本库则没有相应的问题。这是因为裸版本库没有工作区。没有工作区还有一个好处就是空间占用会更小。

使用--bare参数克隆demo版本库到/path/to/repos/demo.git，然后就可以从 demo 版本库向克隆的裸版本库执行推送操作了。（为了说明方便，使用了/path/to/repos/作为Git裸版本的根路径，在后面的章节中这个目录也作为Git服务器端版本库的根路径。可以在磁盘中以root账户创建该路径并设置正确的权限。）

$ git clone --bare /path/to/my/workspace/demo /path/to/repos/demo.git
Cloning into bare repository /path/to/repos/demo.git...
done.

克隆出来的/path/to/repos/demo.git目录就是版本库目录，不含工作区。

• 看看/path/to/repos/demo.git目录的内容。

  $ ls -F /path/to/repos/demo.git
  branches/  config  description  HEAD  hooks/  info/  objects/  packed-refs  refs/
  

• 还可以看到demo.git版本库core.bare的配置为true。

  $ git --git-dir=/path/to/repos/demo.git config core.bare
  true
  

进入demo版本库，生成一些测试提交。

$ cd /path/to/my/workspace/demo/
$ git commit --allow-empty -m "sync test 3"
[master d4b42b7] sync test 3
$ git commit --allow-empty -m "sync test 4"
[master 0285742] sync test 4

在demo版本库向demo-backup版本库执行PUSH操作，还会有错误么？

• 不带参数执行git push，因为未设定上游远程版本库，因此会报错：

  $ git push
  fatal: No destination configured to push to.
  

• 在执行git push时使用/path/to/repos/demo.git作为参数。

  推送成功。

  $ git push /path/to/repos/demo.git
  Counting objects: 2, done.
  Delta compression using up to 2 threads.
  Compressing objects: 100% (2/2), done.
  Writing objects: 100% (2/2), 275 bytes, done.
  Total 2 (delta 1), reused 0 (delta 0)
  Unpacking objects: 100% (2/2), done.
  To /path/to/repos/demo.git
     f86b7bf..0285742  master -> master
  

看看demo.git版本库，是否已经完成了同步？

$ git log --oneline -2
0285742 sync test 4
d4b42b7 sync test 3

这个方式实现版本库本地镜像显然是更好的方法，因为可以直接在工作区修改、提交，然后执行git push命令实现推送。稍有一点遗憾的是推送命令还需要加上裸版本库的路径。这个遗憾在后面介绍远程版本库的章节会给出解决方案。

2.10.4. 创建生成裸版本库

裸版本库不但可以通过克隆的方式创建，还可以通过git init命令以初始化的方式创建。之后的同步方式和上一节大同小异。

命令git init在“Git初始化”一章就已经用到了，是用于初始化一个版本库的。之前执行git init命令初始化的版本库是带工作区的，如何以裸版本库的方式初始化一个版本库呢？奥秘就在于--bare参数。

下面的命令会创建一个空的裸版本库于目录/path/to/repos/demo-init.git 中。

$ git init --bare /path/to/repos/demo-init.git
Initialized empty Git repository in /path/to/repos/demo-init.git/

创建的果真是裸版本库么？

• 看看 /path/to/repos/demo-init.git 下的内容：

  $ ls -F /path/to/repos/demo-init.git
  branches/  config  description  HEAD  hooks/  info/  objects/  refs/
  

• 看看这个版本库的配置core.bare的值：

  $ git --git-dir=/path/to/repos/demo-init.git config core.bare
  true
  

可是空版本库没有内容啊，那就执行PUSH操作为其创建内容呗。

$ cd /path/to/my/workspace/demo
$ git push /path/to/repos/demo-init.git
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to '/path/to/repos/demo-init.git'

为什么出错了？翻译一下错误输出。

$ cd /path/to/my/workspace/demo
$ git push /path/to/repos/demo-init.git
没有指定要推送的引用，而且两个版本库也没有共同的引用。
所以什么也没有做。
可能您需要提供要推送的分支名，如 'master'。
严重错误：远程操作意外终止
错误：部分引用推送失败，至 '/path/to/repos/demo-init.git'

关于这个问题详细说明要在后面的章节介绍，这里先说一个省略版：因为/path/to/repos/demo-init.git 版本库刚刚初始化完成，还没有任何提交更不要说分支了。当执行git push命令时，如果没有设定推送的分支，而且当前分支也没有注册到远程某个分支，将检查远程分支是否有和本地相同的分支名（如master），如果有，则推送，否则报错。

所以需要把git push命令写的再完整一些。像下面这样操作，就可以完成向空的裸版本库的推送。

$ git push /path/to/repos/demo-init.git master:master
Counting objects: 26, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (20/20), done.
Writing objects: 100% (26/26), 2.49 KiB, done.
Total 26 (delta 8), reused 0 (delta 0)
Unpacking objects: 100% (26/26), done.
To /path/to/repos/demo-init.git
 * [new branch]      master -> master

上面的git push命令也可以简写为：git push /pat h/to/repos/demo-init.git master。

推送成功了么？看看demo-init.git版本库中的提交。

$ git --git-dir=/path/to/repos/demo-init.git log --oneline -2
0285742 sync test 4
d4b42b7 sync test 3

好了继续在 demo 中执行几次提交。

$ cd /path/to/my/workspace/demo/
$ git commit --allow-empty -m "sync test 5"
[master 424aa67] sync test 5
$ git commit --allow-empty -m "sync test 6"
[master 70a5aa7] sync test 6

然后再向demo-init.git推送。注意这次使用的命令。

$ git push /path/to/repos/demo-init.git
Counting objects: 2, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 273 bytes, done.
Total 2 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (2/2), done.
To /path/to/repos/demo-init.git
   0285742..70a5aa7  master -> master

为什么这次使用git push命令后面没有跟上分支名呢？这是因为远程版本库（demo-init.git）中已经不再是空版本库了，而且有名为master的分支。

通过下面的命令可以查看远程版本库的分支。

$ git ls-remote /path/to/repos/demo-init.git
70a5aa7a7469076fd435a9e4f89c4657ba603ced        HEAD
70a5aa7a7469076fd435a9e4f89c4657ba603ced        refs/heads/master

至此相信读者已经能够把鸡蛋放在不同的篮子中了，也对Git更加的喜爱了吧。