版本控制工具git使用指南

《版本控制工具git使用指南》由会员分享，可在线阅读，更多相关《版本控制工具git使用指南（30页珍藏版）》请在金锄头文库上搜索。

1、GIT 使用体会Yubao.L2008-10-25iContents1前言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2版本控制的基本概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3GIT 里的术语定义 . . . . . . . . . . . . . . . .

2、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4版本库 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5对象记法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6合并之

3、 fast forward. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7混乱之源index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8工作流程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4、. . . . . . . . 19 9常用命令简介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10GIT 的模块功能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27iiFigures1一个简单的版本演化图4 2Fast forward13 3Fast forward 的结果14 4-firs

5、t-parent 的作用15 5-first-parent 的失效1611 前言本文面向有一定版本控制经验的人群， 对 GIT1有基本了解， 如果有Subversion2、Mercurial3等使用经验更好。 文中从工具的原理和设计乃至实现出发， 讲述了 GIT的用法， 并以个人愚见展示了一些 GIT 不完美的方面。 文章名字本来想戏谑的起名 深入浅出 GIT ， 意指原理讲的教深(但愿)，而具体单个命令用法讲的很浅， 因为后者有手册可查， 但后来还是觉得有辱没类似名字命名的著作且混乱成语用法的嫌疑， 遂作罢。以前初学 GIT 不久写过一篇 GIT 五分钟教程 ， 当时以为自己对 GIT 了解

6、的比较好， 但后来在工作中真正的用上 GIT 后， 才发觉还是学习的很肤浅， 遇到问题经常觉得无所适从。 GIT 秉承了 UNIX 的优良传统小工具堆叠， “条条道路通罗马”， 可惜我常常不知道哪条路是最好走的。 经过近一年的实战使用， 我仍觉得GIT 这玩意还是没能运用自如， 但总算有些心得体会， 记录成文， 希望对 GIT 用户有所帮助。GIT 的命令行界面我觉得至今还是不能让人满意， 我比较喜欢 Subversion、Mercurial 的命令行界面： 一致、 简洁。 GIT 属于那种每个人都想拼命往里面塞功能， 每个人都想让 GIT 具备自己喜欢特性的工具， 结果就导致 GIT 如同

7、Shell 编程一般， “一切皆有可能”， 虽然是颇有恶趣味， 但也常让人厌烦。 这绝不会只是我个人的感受， 遍观繁多的 GIT 包装工具就知道了， 而且有一些 GIT 包装工具的做法被 GIT 吸收， 可以说 GIT 正在成为一个怪物， 一个让人又爱又恨的怪物4， 它的运行速度非常快真的是非常快， 它的设计思想非常简洁有效。如果你要纳入版本控制的文件树规模不大5， 如果你不关心分布式开发， 那么对于版本控制工具， 我向你推荐Subversion，集中式版本控制工具的佼佼者， 有着http:/git.or.cz1http:/subversion.tigris.org/2http:/ Perl、

8、VIM。4大于 500 MB 你就要慎重考虑了 ， Subversion 没有文件复制自动探测， 用户如果粗心的用 svn add5来替代 svn copy，那么会导致版本库迅速膨胀， 而且 Subversion 的工作拷贝实现原理比较低效 ， 类 似操作比起 GIT 慢得多， 著名的开源项目 FreeBSD 从 CVS 转向 Subversion，我是觉得很可惜的。2非常友好的命令行和图形使用界面， 否则， 如果你不是必须使用 GIT，那么我推荐Mercurial，目前分布式版本控制工具里唯一可以跟 GIT 抗衡的选手6，Sun的OpenJDK、OpenSolaris 这样的大规模项目都是使

9、用Mercurial 管理的。 这两者都已经被用在大量开源项目里， 而且可移植性非常好。啰嗦了这么多， 该说感谢致辞了， 首先要感谢 NewSMTH BBS 的 donated 和garfield。大概是一年前， donated 非常耐心的给我介绍了 ConTEXt，但那时能方便使用新字体的 ConTEXt MkIV 还没有成熟， 我也就没提起兴趣继续学习。 不久前我阅读了 garfield 的 ConTEXt 学习笔记7， 才知道ConTEXt MkIV 居然已堪实用， 蒙这篇笔记的引导才开始慢慢学习 ConTEXt，本文就是我正式用 ConTEXt 排版的第一篇文章8。 其次我要感谢我的同

10、事， 我觍颜作为他们的 GIT 传教者以及版本库维护者， 正是由于跟他们的合作促使我认真思索应该如何使用 GIT 从“怎么用”到“怎么用好”9是个很大的转变。2 版本控制的基本概念版本控制(version control)的目的就是保存一个文件树在不同时刻的状态， 其基本概念是相当直白的：文件(file)普通的包含数据的文件。用途： 保存数据。目录(directory)文件名、 目录名的集合， 目录的这种递归包含结构构成了整个文件树。虽然我欣赏 Canonical 的Ubuntu Linux 发行版， 但是对它家的 Bazaar 并没有多大好感， 从几次使6用印象来看这东西效率太太太低了， 表

11、面友好的使用界面掩盖不住其繁复的设计。 http:/ 另外 ConTEXt MkIV 中文排版还有些问题， 有待改进。8希望以后能明白“怎么用最好”:-)93用途： 保存文件路径清单。版本(version, revision)记录某一时刻整个文件树的状态， 并且会包含一些额外信息， 比如时间、 作者、 备注、 从哪个版本演化而来的。 版本的记法有很多种， 比如用递增的数字标记(Subversion)，用点分数字如1.2.3 标记(CVS, RCS)，用版本信息的摘要值标记(GIT, Mercurial)等等。用途： 记录文件树状态变更整个过程， 文件树状态演化形成一个单向无循环图(DAG)。标

12、签(tag, label)用一个容易记忆的名字标记某个版本。用途： 帮助记忆。标签可以分成两种： 静态标签(static tag) 和浮动标签 (float tag)，在各种版本控制工具中， “标签”一词往往指静态标签， 而将浮动标签称为“分支头(branchhead)” ， 或简称为“ 头(head)” ， 分支头的名字(也即浮动标签的名字)命名了一个分支。 需要注意的是版本控制工具中往往用大写的 HEAD 指代当前分支对应的头部。所谓静态标签就是指必须显式修改标签内容(比如版本控制工具的 tag 命令)，才能让其标记另外一个版本， 浮动标签就是指从它指代的版本派生新版本时(比如版本控制工具

13、的 commit 命令)，标签自动被修改， 以指向新版本。而关于“ 分支(branch)”的定义， 则是各有微妙分歧， 下图中小写字母表示版本， 也就是文件树状态以及关于这个状态的备注信息， 连线表示其版本变迁关系， 时间轴从左向右：4a - b - c - f - g = master / d - e = testFigure 1一个简单的版本演化图这个版本图中， 文件树从起始的 a 版本， 用 master 动态标签来标记， 由于修改意图的分歧， 在 b 版本之后分成两个修改方向， b - c 方向仍然用 master 标记， b-d 用 test 标记， 在 c 和 e 之后， 两个修改

14、方向取长补短又合并成一个版本f，之后经过修改后又达到版本 g。图中最后 master 和 test 两个浮动标签分别指代 g 和 e，它们命名了两个分支： master 分支和 test 分支。那么“分支”指代什么呢？ 比如 master 分支， 有如下几种说法：从分歧点算起， master 分支指 f, g 这两个版本， 或者只算 g;指 master 这个标签曾经指向的版本， 也就是 master 这个动态标签的“ 轨迹”a, b, c, f, g;指从 master 标记的版本回溯， 可以达到的版本， 也即 g, f, c, e, d, b, a (注意 f是一次合并， 它可以回溯到 e

15、 和 c)。这种分支含义的分歧直接导致版本控制工具对于“ 分支历史” 定义的分歧， 比如 log 命令的输出。由于分支头命名了分支， 所以往往将二者笼统的都称呼为分支。关于分支还有另外一个分歧， 就是合并的对称性， 考虑图 1中的版本图， 在 e版本的基础上合并 c(也即通常说的在 test 分支上合并分支 master)，和在 c 版本的基础上合并 e(也即通常说的在 master 分支上合并分支 test) 所带来的结果是否等价呢？而其实“ 版本” 的定义也是有分歧的， 从上面可以看到， 标签主要是助记用的， 它的内容可以被修改， 那么“版本”记录的状态里是否要包含当时标签的状态呢？5各种

16、术语称呼差别， 命令叫法不一， 模型定义分歧， 往往导致从一种版本控制工具切换到另一种时极为别扭， 不知所措。3 GIT 里的术语定义GIT 里用 blob, tree, commit, tag 四种存储对象来描述版本控制所需信息， 每一种存储对象都是以类型名字、 内容长度、 内容计算出的 SHA1 摘要值命名， 存放在 .git/objects/ 目录下的文件。blob表示第 2节中的文件, blob 只有文件数据和长度， 不保存名字、 文件类型、 权限等信息， 恰如其名;tree表示第 2节中的目录， 不包括像 Subversion 那样的 property，只有文件权限位（ 无属组和属主信息)、对象类型(blob 还是 tree)、SHA1 摘要值、 文件或子目录名字。 早期的 git 实现中 tree 对象保存的是整个