在Ubuntu里安装Git后,manual文档也会一并安装。查看manual的方法:
// 查看Git Manual
$man git
// 查看Git clone Manual
$man git clone
// 查看Git clone Manual
$git clone --help
// 查看Git clone Manual
$git help clone
也可以通过help选项查看帮助信息:
// 查看Git的帮助信息
$git --help
// 查看Git的帮助信息
$git help
// 查看Git clone的帮助信息
$git clone -h
Git clone和git init是用来创建工作区的两个命令。
Git clone是将一个已经存在的数据仓库(repository)克隆到本地一个新创建的文件夹中。
git clone 是一个 Git 命令行工具,它被用来指定一个现有的仓库(可以是远程或是本地),并创建一个目标仓库的克隆或副本。下面讨论git clone的扩展配置选项和常见用例。
如果已经在中央仓库中建立了一个项目,git clone命令是用户获得开发副本的最常见方式。像git init一样,克隆通常是一次性的操作。一旦开发者获得了一个工作副本,所有的版本控制操作和协作都是通过他们的本地仓库管理的。
仓库与仓库之间的协作
我们必须明白,Git的 "工作副本 "概念与你从SVN仓库签出的工作副本有很大不同。与SVN不同,Git对工作副本和中央仓库没有任何区分,它们都是完备的Git仓库。
这使得用Git进行协作与用SVN进行协作有着本质的区别。SVN依赖于中央仓库和工作副本之间的关系,而Git的协作模式则是基于仓库与仓库之间的互动。你不需要将工作副本提交到SVN的中央仓库,而是将提交从一个仓库推送到另一个仓库,或者从一个仓库将提交拉过来。
使用方法
git clone主要用于指向一个现有的版本库,并在另一个位置的新目录下复制或拷贝该版本库。原始仓库可以位于本地文件系统或支持协议访问的远程机器上。git clone 命令复制一个现有的 Git 仓库。这有点像 SVN 签出(checkout),只不过这个 "工作副本 "(working copy)是一个完备的 Git 仓库--它有自己的历史,管理自己的文件,是一个与原仓库完全隔离的环境。
为了方便起见,克隆会自动创建一个名为 "origin "的远程连接,指向原始仓库。这使得与中央仓库的互动变得非常容易。在refs/remotes/origin下创建Git refs,用来指向远程分支的head,并初始化remote.origin.url和remote.origin.fetch两个配置变量,来创建这个连接。
$ git config remote.origin.url
ssh://git@bitbucket.company.com:7999/projects/productXXX.git
$ git config remote.origin.fetch
+refs/heads/*:refs/remotes/origin/*
下面的例子演示了如何使用 SSH 用户名 john 获取存储在 example.com 服务器上的中央仓库的本地拷贝:
git clone ssh://john@example.com/path/to/my-project.git
cd my-project
# Start working on the project
从github上clone仓库的例子:
$ git clone git@github.com:yeliubing/GitLearn.git
Git clone命令在本地机器上的 my-project 文件夹中初始化一个新的 Git 仓库,并将中央仓库的内容填充到该仓库中。然后,你就可以进入项目,开始编辑文件,提交快照(committing snapshots),并与其他仓库进行交互。还要注意的是,克隆的版本库的名称和文件夹名去掉了.git扩展名。这就是一个非空的本地拷贝。
克隆到一个特定的文件夹
git clone <repo> <directory>
将位于<repo>的版本库克隆到本地机器上名为<directory>的文件夹中。这个文件夹要是一个空文件夹才行。
不指定文件夹,会以仓库名创建一个新文件夹,里面填充内容;指定文件夹,则以指定的文件夹里填充内容,就不会有仓库名了。
克隆一个特定的TAG
git clone --branch <tag> <repo>
将仓库<repo>的版本标签<tag>克隆到本地。
Shallow clone 浅克隆
git clone --depth=1 <repo>
克隆位于<repo>的版本库,并且只克隆由选项depth=1指定的提交历史。在这个例子中,我们克隆了<repo>,在新克隆的 Repo 中只包括最近的提交。浅层克隆在处理有大量提交历史的 Repo 时最有用。大量的提交历史可能会导致数据量大问题,如磁盘空间使用限制和克隆时的漫长等待时间。浅层克隆可以帮助缓解这些问题。
--[no-]single-branch
控制是否fetch其他的所有分支数据。
git clone --branch or git clone -b
通过 -branch 参数,您可以指定一个特定的分支来克隆,而不是远程 HEAD 指向的分支,通常是主分支。此外,你还可以传递一个标签,而不是分支,以达到同样的效果。和上面克隆一个特定的TAG的用法一样。
git clone --branch new_feature git://remoterepository.git
有时我们不需要远程的HEAD所指向的主分支,比如mater分支,而是一个特定分支,这样能节省时间,直接获得需要的分支,不需要下载HEAD ref。否则还要多一次checkout操作,来fetch你需要的ref。
git clone -mirror vs. git clone -bare
git clone --bare
与git init --bare类似,当bare参数被传递给git clone时,远程仓库的工作目录不会被拷贝。这意味着将建立一个只带有项目历史的仓库,可以推送和提取,但没有内容可以编辑。此外,使用bare仓库时,不会为该仓库配置远程分支,refs文件夹下没有remote/origin。和git init --bare一样,这也是用来创建一个开发者不会直接编辑的托管仓库。
有两种类型的 git 仓库:裸仓库和非裸仓库(bare and non-bare)。裸库是指除了 .git 文件夹以外什么都不包含的库;换句话说,它有索引,但缺乏实际的工作文件。非裸库是你习惯使用的,它包括git索引和工作文件的检查副本。通常情况下,裸库被用作远程;我们从工作中的非裸库推送修改到裸库。
git clone --mirror
使用--mirror参数的同时,也隐含地传递了--bare参数。这意味着bare的行为被-mirror所继承。克隆一个没有可编辑的工作文件(no working tree)的裸仓库。此外,--mirror将克隆远程仓库的所有扩展引用(extended refs),并维护远程分支配置。然后你可以在镜像上运行git remote命令来更新设置,它将覆盖origin repo的所有refs。给你提供精确的 "镜像 "功能。
就是说Bare和mirror都是裸仓库,没有工作区,镜像仓库可以用来做远程仓库的本地只读备份,按需要运行更新,是两仓库保持同步,远程仓库会覆盖本地仓库。
Git URLs
Git 有自己的 URL 语法,用来传递远程仓库的位置给 Git 命令。因为git clone最常用于远程仓库,我们将在这里研究Git的URL语法。
Git URL protocols
-SSH
Secure Shell(SSH)是一个无处不在的认证网络协议,通常在大多数服务器上都是默认配置的。因为SSH是一个认证协议,你需要在连接之前与托管服务器建立凭证。
ssh://[user@]host.xz[:port]/path/to/repo.git/
- GIT
git特有的一个协议。Git有一个运行在端口(9418)的守护程序(daemon )。该协议类似于SSH,但它不需要认证(it has NO AUTHENTICATION)。
git://host.xz[:port]/path/to/repo.git/
- HTTP
超文本传输协议(Hyper text transfer protocol.)。Web网络使用的协议,最常用于在互联网上传输网页HTML数据。Git可以被配置为通过HTTP进行通信:
http[s]://host.xz[:port]/path/to/repo.git/
更多详情请参考:(official Git documentation & setting up a repository guide)
或
Setting up a repository | Atlassian Git Tutorial
参考:
git clone | Atlassian Git Tutorial
Push-to-deploy: A nice git workflow for updating server code