2010年11月6日星期六

git 之五分钟教程

git 之五分钟教程

我懒,估计读者也是懒的,所以写点小文供大家了解一下 git。

git 是一个分布式版本管理工具,关于它大家应该都有所耳闻了,
貌似 Linus 说是 2005 年 4 月 17 日公开的,如今已经 1.4.3.4
了,开发社区非常活跃,一如 Linux (Linus 英明神武,sigh),
git 现在的维护者是 Junio C Hamano,主页在 http://git.or.cz 。

关于分布式版本管理工具的定义,我土,感受最深的是每个人都有
自己的代码库,这个跟 SVN 不同,这个区别带来的好处是跟踪本地
的修改过程非常方便,SVN 里头不同代码库之间不能 switch,麻烦。
但是 SVN 的用户界面实在是比 git 友好得多,特别是 SVN 建立
在大家普遍比较熟悉的 CVS 模型上。

闲话少说,切入正题。

* git 的四种对象

在 git 中最基本的四种对象为 blob,tree,commit,tag。
blob - 即文件,注意只包含内容,没有名字,权限等属性(例外的是
包含大小)
tree - 所有文件名字以及其属性的列表,这些属性只是基本属性,比如
权限,是否符号链接。git 没有像 svn 那样丰富的 property 用。
commit - 表示修改历史,描述一个个 tree 之间如何联系起来的,每一个
commit 对应有一个 tree —— commit 的修改结果。commit 包含
作者、提交者、parent commit、tree、log、修改时间、提交时间,
注意 git 明确区分了 author 和 committer 这两个角色。
tag - 标签,它可以指向 blob, tree, commit 并包含签名,最常见的是
指向 commit 的 GPG 签名的标签。

blob,tree,commit 都是用其存储内容的 SHA-1 值命名的(不是简单的对
整个文件取 SHA-1 值),tag 自然使用的是普通名字。

git 的想法就是 blob 和 tree 中包含的只能是最公共的最基本的信息,
所以它不会在 blob 和 tree 里头存放 svn 那么多的自定义属性。

git 也只是定位在 content tracker,这个术语跟 VCS 是有微妙的差别的,
第一是体现在它对 blob 和 tree 的“纯数据”的要求上,第二是对分支
合并的处理上,如下所示(a, b, c 表示三个 commit):

-- a ----> master
\
b ----- c -> test

test 分支从 master 的 a 点上分出来,做了许多修改,然后当 master
分支和 test 分支合并会怎么样呢?按照通常的 CVS/SVN 的做法,是创建
一个新的 commit,继承自 a 和 c,但是 git 则是直接修改 master
使其指向 c,在 git 这称为 fast forward,整个版本图变成这样:

-- a -- b -- c --> master
\
`--> test

从图中看 master 分支和 test 分支分不出主次,这里头的含义很值得玩味。


* 选择对象

blob, tree, commit 都是用其 SHA-1 命名的,如果得到一个 SHA-1
值,但不知道是什么类型,可以用
git cat-file -t SHA-1
命令识别,它会输出 blob, tree, commit (如果给它一个 tag 名字,
它也能输出 tag) 这样的字符串,然后就可以用
git cat-file type SHA-1
查看其内容了,这里 type 是 blob, tree, commit, tag 中的一个。
注意对于 tree 对象它输出的是 tree 对象存储时的样子,看起来像是
乱码,所以对于 tree 要用
git ls-tree SHA-1

另外 git 也可以在需要 tree 对象的地方给它一个 commit 对象
或者一个 tag 对象,这时就是用 commit 或 tag 指向的 tree,
在 git 的手册中可以看到 tree-ish 这样的写法,意思就是可以
从 tree-ish 这个参数得到一个 tree,同样的,也有 commit-ish.
比如
git-ls-tree [-d] [-r] [-t] [-z] [--name-only]
[--name-status] [--full-name] [--abbrev=[]]
[paths…]

总结一下,可以用 SHA-1 值指定是哪一个 blob/tree/commit 对象(无需
指出类型),可以用 commit 或者 tag 指定一个 tree,可以用 tag 指定
一个 commit(一般 tag 都是用来指向 commit,虽然它可以指向其它类型
对象)。

在 git 中很频繁提到 ref 或者 reference,它就是一个名字,包含了
一个 commit。分支名字,tag 其实都是 reference,这可以从它们都
位于 .git/refs 下看出来,区别在于分支名字(就是指代各个分支的
HEAD)指向的目标可以改变,而 tag 不能。

指代一个 tree 中的某个文件可以用
tree-ish:path/to/file
的格式,注意 path 前面没有“/”。

* commit 记法

commit 因为有继承关系(ancestry),它的选择方式更特殊些,比如怎么
选择它的 parent commit,以及 parent commit 的 parent commit,
虽然这个信息可以逐步通过 git cat-file commit commit-ish 获得,
但显然需要一个简便的记法来指定,类似于 SVN 的 HEAD、PREV、COMMITTED。

这种 git 独有的记法在 git-rev-parse(1) 有详细描述,简要的说,
commit-ish^n 表示 commit 的第 n 个 直接 parent commit,n 从 1 算起。
只有在一个 commit 是合并的结果时这个 commit 才可能有
commit^2, commit^3。
当 n 等于 1 时可以省略,只写 ^。
当 n 等于 0 时就指 commit 本身,这可以用来将一个 tag
转成 commit。

这种 ^n 记法可以连续写,比如 HEAD^2^2 表示 HEAD 的第二个 parent commit
的第二个 parent commit。

commit-ish~n 这种记法是 commit-ish^^^...^ 总共 n 个 ^ 的简写,这样在
直线历史上能够方便的说倒数第 (n+1) 次提交(commit-ish^1
是倒数第二次)。
当 n 等于 1 时自然也是可以不写 1 的。

在接收 commit 集合的命令中,比如 git log,commit 的记法有特殊含义:
git log HEAD
表示按照 parent 关系从 HEAD 能够到达的所有 commit,
包含 HEAD。

git log ^HEAD~2 HEAD
表示从 HEAD 能够到达的所有 commit(包含 HEAD),排除
能从 HEAD~2 到达的所有 commit(包含 HEAD~2),这样计算
的结果就是 HEAD~1 和 HEAD.

这样的集合记法可以写多个,比如
git log commit-1 commit-2 ^commit-3 ^commit-4

特殊的,commitA..commitB 是 ^commitA commitB 的简写。

这种集合记法在比较两个分支的区别时很有效,比如想看 test 分支从 master
分支分出来后做了什么修改,可以用
git log ^master test
这里不需要从分支点排除,因为按照这种集合相减关系,得到的就是 test 自
master 分出来后所创建的所有 commit。

由于 git 的 fast forward 形式的合并,HEAD^1 并不总是合并前所在的
工作分支,这一点是很容易迷糊人的,如下图(a,b,c 代表 commit):

--- a ---> master
\
b ----- c ---> test

现在 master 从 test 上合并,按照 git 的做法,因为 a 是 c 祖先,而且
master 分支上自 a 之后没有新的修改,所以 git 直接把 master 指向 c,
而不创建新的 commit:

--- a --- b ----- c ---->master, test

现在 master 和 test 指向同一个 commit,master^1 是 b,而 b 并不在
*原先的* master 分支上。合并后,master 和 test 的历史是一致的,没有
区别,这个 CVS 和 SVN 的做法是不同的,按照 CVS 或者 SVN 的做法,
合并后 show log master 看到的应该是 a 和 d(d 的 parent commit 是 a 和 c),
但是 git log master 看到的是 a b c。

git 的这个 fast forward 形式的 merge 很有意思。

* .git 和 index
CVS/SVN 中,代码库和工作拷贝都是分开的,工作拷贝的版本信息放在每一层
目录中,这给在工作拷贝中 grep 代码不便。git 将代码库和工作拷贝的版本
信息统一放在工作拷贝的顶层目录下的 .git/ 中(可以配置使用其它目录)。

.git/
├─branches
├─hooks
├─info
├─objects
│ ├─info
│ └─pack
├─refs
│ ├─heads
│ └─tags
└─remotes

objects 下面是存放 blob, tree, commit 对象的地方,取 SHA-1的十六进制
前两个字符做目录名,余下的做文件名, 注意一个对象的 SHA-1 值不是直接
对这里面的文件计算 SHA-1 值得到的。

用 SHA-1 引用对象时,一般取其前六个字符,只要能够唯一识别一个对象即可,

.git 下可以存在 config 文件,这个是一个库的配置文件,用户可以在自己
的 HOME 目录下有 .gitconfig 文件,两者格式是一样的,参考 git-repo-config(1)。

.git 下可能还存在一个 logs 目录,由于 git 的 fast forward 形式的合并
做法,导致不能通过 git log 来获取一个分支的头曾经指向哪些 commit,这个
logs 目录下的文件就是用来记录这个信息的,要想使用它需要在 .git/config
或者 ~/.gitconfig 里头设置选项。这些 log 就称为 reflog,叫 ref 是因为
分支名和标签都是 commit 的引用,都放在 .git/refs 目录下。

.git 下还有 index 文件(对于刚创建的空库是没有的),这个文件就起到 CVS
的 .cvs 目录或者 SVN 的 .svn 目录的作用,它记录了工作拷贝在哪个 commit
上,以及工作拷贝中被 git 管理的文件的状态。在 SVN 中,.svn 里头保存了
一份代码,称为 BASE,index 里头跟它作用类似,不过它只是记录了文件名
和其 SHA-1 值、mtime、ctime、所在的设备号、权限位、uid、gid、size,
真正的文件内容都在 .git/objects 里头。

index 跟 tree 很类似,除了包含一些信息用于跟踪工作拷贝中的文件状态,
粗略的讲,使用 git 最常打交道的有三个 tree:HEAD 对应的 tree,index
对应的 tree,工作拷贝中的目录树。

git 和 svn 对于处理 index 和 BASE 版本的方式不大一样,SVN 是以工作拷贝为
中心,BASE 在提交前是不会变的,git 则以 index 为中心,在提交前 index 是
可以变的,这一点也很迷糊人,比如,如果你在工作拷贝中修改了文件,用 git
commit 却告诉你没有修改,因为 git commit 是把 index 代表的状态提交到库里
头,只有你用git-update-index your_file 将工作目录中的修改反映到 index 里,
git commit 才会跟直觉的提交行为一致,不过文件被提交到库里的时机是在调用
git-update-index 的时候,而非 git commit 的时候,git commit只是依照
index 的状态创建一个 tree 放入 .git/ojbects 里头。可以用 git commit -a
达到 svn commit 的直观效果。

index 也被称为 cache,这是早期的叫法。

一份 .gitconfig:
[core]
fileMode = false
logAllRefUpdates = true
compression = 9

[diff]
color = auto

[pack]
window = 64

[user]
email = your_email
name = your_name

[merge]
summary = true



* 入门操作
git 的命令分成两类,低级命令(称为“plumbing”)和高级命令(称为“porcelain”),
不算开头的 git 前缀,低级命令的名字 *一般* 是两个单词的,高级命令则 *一般* 是
一个单词的。

低级命令都是一些 C 写的小程序,直接操作 git 核心的对象如 tree,commit 以
及 index 等,这些是提供给编写 git 包装程序比如 cogito 的人使用的,高级命
令是面向最终用户的,这些命令要么是对 git 命令的包装,要么是提供一些方便的
功能比如统计 log。

一个 git 命令可以写成 "git-cmd" 或者 "git cmd",前者在 PATH 中寻找 "git-cmd"
这个命令并执行之,后者则是执行 git 命令,传入后面的 cmd 等参数,git 这个
程序在 exec-path 中寻找 git-cmd 并执行之,这个 exec-path 可以通过命令行
选项 --exec-path=XXX 或者 GIT_EXEC_PATH 环境变量设置,在安装 git 时它内部
也会保存一个缺省的 exec-path。这个路径列表的语法跟 PATH 一致。git 的这种
exec-path 机制能够让它很方便的加入更多的命令。

获取一个 git 命令的帮助可以用 man git-cmd 或者 git --help cmd 或者 git help cmd
或者 git cmd --help,这四种命令效果跟第一条一样。

(a)
git init-db
在当前目录下创建 git 库(.git)

(b)
echo hello > xxx
git add xxx
递归将 xxx 加入 git 控制中,执行完后文件已经被加入库中,index 也已更新,
这时 git diff 因为 index 跟 工作拷贝一致,所以没有差别。
// 其实就是用的 git-update-index,这个命令在更新 index 时也会立即把
// 文件写入库中,这点跟 SVN 的 add 不一样。

(c)
git commit
将 index 实例化为一个 tree,创建一个 commit,这个时候看.git/objects 下面
就有三个对象:blob xxx,一个 tree 和一个commit。

(d)
echo world >> xxx
git diff
比较 index 和 工作拷贝
git diff --cached
比较 index 和前一次提交对应的 tree,这就是 git commit 要提交的东西。
git diff HEAD
比较工作拷贝和前一次提交对应的 tree,这就是 git commit -a 要提交的东西。

(e)
git commit
因为 index 没有改变,而 commit 只是从 index 创建 tree,所以没有需要提交
的,提示用 git-update-index.
git update-index xxx
git commit
更新了 index,这下可以提交了, 如果是想提交 index 中所有修改过和删除了的
文件,这两步可以用 git commit -a(这个命令类似于在顶层目录执行 svn commit)。

(f)
git log -p
查看 log,-p 表示显示每一次修改的 diff。

(g)
git branch
显示所有分支,当前分支前面有一个 *,默认分支叫 master。
git branch test
建立一个分支 test
git checkout test
切换到 test 分支,这两步可以合并为 git checkout -b test。

(h)
在 test 分支做了有些修改后提交;
git checkout master
回到主分支
git log master..test
查看 test 分支上修改记录(参考 “commit 记法” 一节)。

git merge --no-commit "msg" HEAD test
这个命令的参数语法比较怪异。--no-commit 是让 git 不要马上
提交,这样可以检查一下合并结果是否正确,由于这段时间主干上
没有修改,所以这个合并其实就是 fast forward,直接将
master 指向 test 分支的 HEAD,不会创建新的 commit。
// git pull 的行为有点古怪,不推荐使用。

如果不是 fast forward,可以用 git diff 检查一下然后再
git commit;如果合并后有冲突,git 会把冲突标记写入文件,
这个时候打开这个文件编辑之,解决冲突后用 git-update-index
更新 index,然后 git commit。

(i)
gitk --all
查看版本图。

(j)
git branch -D test
删除 test 分支。

(k)
git clone git://git.kernel.org/pub/scm/git/git.git
把 git 的开发库镜像到本地的 git 目录中。

(l)
cd git && git fetch
与 git 的开发库同步。不建议用 git pull,可以用 git fetch
和 git merge 的组合代替 git pull。

(m)
git status
查看工作拷贝中的修改情况

(n)
git show commit-ish
查看一个 commit。

(o)
git reset commit-ish
将当前 HEAD 指向 commit-ish 代表的 commit。
这个命令有三个选项:
--mixed 默认选项,调整 HEAD 并重置 index,保留工作拷贝中的修改,
修改过的文件需要再次 git-update-index 以更新 index。
--soft 仅修改 HEAD。
--hard 修改 HEAD,并将 index 和 工作拷贝的状态对应到 commit-ish
相应的 tree 上,这会丢失工作拷贝中的修改!

在 git-reset(1) 中有一些这个命令的使用场合说明,可以看看,常用的可能
是第一条:
git reset --soft HEAD^
撤销最近一次提交。

// 类似于 svn revert 的是 git checkout。

(p)
git revert commit-ish
撤销库里的某次提交,注意跟 svn revert 撤销工作拷贝的修改不一样。
如果是撤销最近的提交,最好用 git reset。

(q)
有点点类似于 svn info 的命令是:
cat .git/remotes/origin

还有一个 git-push(1), 比较的复杂,以及其它的许多许多命令,
比如格式化 patch,将 patch 通过邮件发送,从 mbox 中提取
patch,等等,这篇小文就不罗嗦了(我也不大会-_-b),可以参考手册。


* 参考资料
http://www.kernel.org/pub/software/scm/git/docs/
这个上面的 tutorial 和 Everyday Git 指向两篇很好的教程,此页的
FURTHER DOCUMENTATION 中提到的 Discussion 以及 Core tutorial 对了解
git 的内部机制很有帮助。

http://git.or.cz/gitwiki/GitLinks
很多 git 相关资料的链接。

http://linux.yyz.us/git-howto.html
Kernel Hackers' Guide to git, 比较老的一篇教程了。

http://www.gelato.unsw.edu.au/archives/git/0512/13748.html
http://marc.theaimsgroup.com/?l=git&m=113402372012587&w=4
git for the confused, 虽然有点老了,仍然强烈推荐。

没有评论:

发表评论