Git从入门到精通


1. Introduction 2. 起步 i. 关于版本控制 ii. Git 简史 iii. Git 基础 iv. 安装 Git v. 初次运行 Git 前的配置 vi. 获取帮助 vii. 小结 3. Git 基础 i. 取得项目的 Git 仓库 ii. 记录每次更新到仓库 iii. 查看提交历史 iv. 撤消操作 v. 远程仓库的使用 vi. 打标签 vii. 技巧和窍门 viii. 小结 4. Git 分支 i. 何谓分支 ii. 分支的新建与合并 iii. 分支的管理 iv. 利用分支进行开发的工作流程 v. 远程分支 vi. 分支的衍合 vii. 小结 5. 服务器上的 Git i. 协议 ii. 在服务器上部署 Git iii. 生成 SSH 公钥 iv. 架设服务器 v. 公共访问 vi. GitWeb vii. Gitosis viii. Gitolite ix. Git 守护进程 x. Git 托管服务 xi. 小结 6. 分布式 Git i. 分布式工作流程 ii. 为项目作贡献 iii. 项目的管理 iv. 小结 7. Git 工具 i. 修订版本(Revision)选择 ii. 交互式暂存 iii. 储藏(Stashing) iv. 重写历史 v. 使用 Git 调试 vi. 子模块 vii. 子树合并 viii. 总结 8. 自定义 Git Table of Contents i. 配置 Git ii. Git属性 iii. Git挂钩 iv. Git 强制策略实例 v. 总结 9. Git 与其他系统 i. Git 与 Subversion ii. 迁移到 Git iii. 总结 10. Git 内部原理 i. 底层命令 (Plumbing) 和高层命令 (Porcelain) ii. Git 对象 iii. Git References iv. Packfiles v. The Refspec vi. 传输协议 vii. 维护及数据恢复 viii. 总结 原文《Git Pro》 本章介绍开始使用 Git 前的相关知识。我们会先了解一些版本控制工具的历史背景,然后试着让 Git 在你的系统上跑起来,直 到最后配置好,可以正常开始开发工作。读完本章,你就会明白为什么 Git 会如此流行,为什么你应该立即开始使用它。 起步 什么是版本控制?我为什么要关心它呢?版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的 系统。在本书所展示的例子中,我们仅对保存着软件源代码的文本文件作版本控制管理,但实际上,你可以对任何类型的文 件进行版本控制。 如果你是位图形或网页设计师,可能会需要保存某一幅图片或页面布局文件的所有修订版本(这或许是你非常渴望拥有的功 能)。采用版本控制系统(VCS)是个明智的选择。有了它你就可以将某个文件回溯到之前的状态,甚至将整个项目都回退 到过去某个时间点的状态。你可以比较文件的变化细节,查出最后是谁修改了哪个地方,从而找出导致怪异问题出现的原 因,又是谁在何时报告了某个功能缺陷等等。使用版本控制系统通常还意味着,就算你乱来一气把整个项目中的文件改的改 删的删,你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。 许多人习惯用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示区别。这么做唯一的好处就是简 单。不过坏处也不少:有时候会混淆所在的工作目录,一旦弄错文件丢了数据就没法撤销恢复。 为了解决这个问题,人们很久以前就开发了许多种本地版本控制系统,大多都是采用某种简单的数据库来记录文件的历次更 新差异(见图 1-1)。 图 1-1. 本地版本控制系统 其中最流行的一种叫做 rcs,现今许多计算机系统上都还看得到它的踪影。甚至在流行的 Mac OS X 系统上安装了开发者工具 包之后,也可以使用 rcs 命令。它的工作原理基本上就是保存并管理文件补丁(patch)。文件补丁是一种特定格式的文本文 件,记录着对应文件修订前后的内容变化。所以,根据每次修订后的补丁,rcs 可以通过不断打补丁,计算出各个版本的文件 内容。 接下来人们又遇到一个问题,如何让在不同系统上的开发者协同工作?于是,集中化的版本控制系统( Centralized Version Control Systems,简称 CVCS )应运而生。这类系统,诸如 CVS,Subversion 以及 Perforce 等,都有一个单一的集中管 理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。 多年以来,这已成为版本控制系统的标准做法(见图 1-2)。 关于版本控制 本地版本控制系统 集中化的版本控制系统 图 1-2. 集中化的版本控制系统 这种做法带来了许多好处,特别是相较于老式的本地 VCS 来说。现在,每个人都可以在一定程度上看到项目中的其他人正在 做些什么。而管理员也可以轻松掌控每个开发者的权限,并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻 松容易。 事分两面,有好有坏。这么做最显而易见的缺点是中央服务器的单点故障。如果宕机一小时,那么在这一小时内,谁都无法 提交更新,也就无法协同工作。要是中央服务器的磁盘发生故障,碰巧没做备份,或者备份不够及时,就会有丢失数据的风 险。最坏的情况是彻底丢失整个项目的所有历史更改记录,而被客户端偶然提取出来的保存在本地的某些快照数据就成了恢 复数据的希望。但这样的话依然是个问题,你不能保证所有的数据都已经有人事先完整提取出来过。本地版本控制系统也存 在类似问题,只要整个项目的历史记录被保存在单一位置,就有丢失所有历史更新记录的风险。 于是分布式版本控制系统( Distributed Version Control System,简称 DVCS )面世了。在这类系统中,像 Git,Mercurial,Bazaar 以及 Darcs 等,客户端并不只提取最新版本的文件快照,而是把代码仓库完整地镜像下来。这么一 来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的提取操作,实 际上都是一次对代码仓库的完整备份(见图 1-3)。 分布式版本控制系统 图 1-3. 分布式版本控制系统 更进一步,许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此,你就可以在同一个项目中,分别和不同工 作小组的人相互协作。你可以根据需要设定不同的协作流程,比如层次模型式的工作流,而这在以前的集中式系统中是无法 实现的。 同生活中的许多伟大事件一样,Git 诞生于一个极富纷争大举创新的年代。Linux 内核开源项目有着为数众广的参与者。绝大 多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上(1991-2002年间)。到 2002 年,整个项目组开始 启用分布式版本控制系统 BitKeeper 来管理和维护代码。 到了 2005 年,开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束,他们收回了免费使用 BitKeeper 的权 力。这就迫使 Linux 开源社区(特别是 Linux 的缔造者 Linus Torvalds )不得不吸取教训,只有开发一套属于自己的版本控 制系统才不至于重蹈覆辙。他们对新的系统制订了若干目标: 速度 简单的设计 对非线性开发模式的强力支持(允许上千个并行开发的分支) 完全分布式 有能力高效管理类似 Linux 内核一样的超大规模项目(速度和数据量) 自诞生于 2005 年以来,Git 日臻成熟完善,在高度易用的同时,仍然保留着初期设定的目标。它的速度飞快,极其适合管理 大项目,它还有着令人难以置信的非线性分支管理系统(见第三章),可以应付各种复杂的项目开发需求。 Git 简史 那么,简单地说,Git 究竟是怎样的一个系统呢?请注意,接下来的内容非常重要,若是理解了 Git 的思想和基本工作原理, 用起来就会知其所以然,游刃有余。在开始学习 Git 的时候,请不要尝试把各种概念和其他版本控制系统(诸如 Subversion 和 Perforce 等)相比拟,否则容易混淆每个操作的实际意义。Git 在保存和处理各种信息的时候,虽然操作起来的命令形式 非常相近,但它与其他版本控制系统的做法颇为不同。理解这些差异将有助于你准确地使用 Git 提供的各种工具。 Git 和其他版本控制系统的主要差别在于,Git 只关心文件数据的整体是否发生变化,而大多数其他系统则只关心文件内容的 具体差异。这类系统(CVS,Subversion,Perforce,Bazaar 等等)每次记录有哪些文件作了更新,以及都更新了哪些行的 什么内容,请看图 1-4。 图 1-4. 其他系统在每个版本中记录着各个文件的具体差异 Git 并不保存这些前后变化的差异数据。实际上,Git 更像是把变化的文件作快照后,记录在一个微型的文件系统中。每次提 交更新时,它会纵览一遍所有文件的指纹信息并对文件作一快照,然后保存一个指向这次快照的索引。为提高性能,若文件 没有变化,Git 不会再次保存,而只对上次保存的快照作一链接。Git 的工作方式就像图 1-5 所示。 图 1-5. Git 保存每次更新时的文件快照 这是 Git 同其他系统的重要区别。它完全颠覆了传统版本控制的套路,并对各个环节的实现方式作了新的设计。Git 更像是个 小型的文件系统,但它同时还提供了许多以此为基础的超强工具,而不只是一个简单的 VCS。稍后在第三章讨论 Git 分支管 理的时候,我们会再看看这样的设计究竟会带来哪些好处。 在 Git 中的绝大多数操作都只需要访问本地文件和资源,不用连网。但如果用 CVCS 的话,差不多所有操作都需要连接网 络。因为 Git 在本地磁盘上就保存着所有当前项目的历史更新,所以处理起来速度飞快。 Git 基础 直接记录快照,而非差异比较 近乎所有操作都是本地执行 举个例子,如果要浏览项目的历史更新摘要,Git 不用跑到外面的服务器上去取数据回来,而直接从本地数据库读取后展示给 你看。所以任何时候你都可以马上翻阅,无需等待。如果想要看当前版本的文件和一个月前的版本之间有何差异,Git 会取出 一个月前的快照和当前文件作一次差异运算,而不用请求远程服务器来做这件事,或是把老版本的文件拉到本地来作比较。 用 CVCS 的话,没有网络或者断开 VPN 你就无法做任何事情。但用 Git 的话,就算你在飞机或者火车上,都可以非常愉快 地频繁提交更新,等到了有网络的时候再上传到远程仓库。同样,在回家的路上,不用连接 VPN 你也可以继续工作。换作其 他版本控制系统,这么做几乎不可能,抑或非常麻烦。比如 Perforce,如果不连到服务器,几乎什么都做不了(译注:默认 无法发出命令 p4 edit file 开始编辑文件,因为 Perforce 需要联网通知系统声明该文件正在被谁修订。但实际上手工修改文 件权限可以绕过这个限制,只是完成后还是无法提交更新。);如果是 Subversion 或 CVS,虽然可以编辑文件,但无法提 交更新,因为数据库在网络上。看上去好像这些都不是什么大问题,但实际体验过之后,你就会惊喜地发现,这其实是会带 来很大不同的。 在保存到 Git 之前,所有数据都要进行内容的校验和(checksum)计算,并将此结果作为数据的唯一标识和索引。换句话 说,不可能在你修改了文件或目录之后,Git 一无所知。这项特性作为 Git 的设计哲学,建在整体架构的最底层。所以如果文 件在传输时变得不完整,或者磁盘损坏导致文件数据缺失,Git 都能立即察觉。 Git 使用 SHA-1 算法计算数据的校验和,通过对文件的内容或目录的结构计算出一个 SHA-1 哈希值,作为指纹字符串。该字 串由 40 个十六进制字符(0-9 及 a-f)组成,看起来就像是: 24b9da6552252987aa493b52f8696cd6d3b00373 Git 的工作完全依赖于这类指纹字串,所以你会经常看到这样的哈希值。实际上,所有保存在 Git 数据库中的东西都是用此哈 希值来作索引的,而不是靠文件名。 常用的 Git 操作大多仅仅是把数据添加到数据库。因为任何一种不可逆的操作,比如删除数据,都会使回退或重现历史版本 变得困难重重。在别的 VCS 中,若还未提交更新,就有可能丢失或者混淆一些修改的内容,但在 Git 里,一旦提交快照之后 就完全不用担心丢失数据,特别是养成定期推送到其他仓库的习惯的话。 这种高可靠性令我们的开发工作安心不少,尽管去做各种试验性的尝试好了,再怎样也不会弄丢数据。至于 Git 内部究竟是 如何保存和恢复数据的,我们会在第九章讨论 Git 内部原理时再作详述。 好,现在请注意,接下来要讲的概念非常重要。对于任何一个文件,在 Git 内都只有三种状态:已提交(committed),已修 改(modified)和已暂存(staged)。已提交表示该文件已经被安全地保存在本地数据库中了;已修改表示修改了某个文 件,但还没有提交保存;已暂存表示把已修改的文件放在下次提交时要保存的清单中。 由此我们看到 Git 管理项目时,文件流转的三个工作区域:Git 的工作目录,暂存区域,以及本地仓库。 时刻保持数据完整性 多数操作仅添加数据 文件的三种状态 图 1-6. 工作目录,暂存区域,以及本地仓库 每个项目都有一个 Git 目录(译注:如果 git clone 出来的话,就是其中 .git 的目录;如果 git clone --bare 的话,新建的目 录本身就是 Git 目录。),它是 Git 用来保存元数据和对象数据库的地方。该目录非常重要,每次克隆镜像仓库的时候,实际 拷贝的就是这个目录里面的数据。 从项目中取出某个版本的所有文件和目录,用以开始后续工作的叫做工作目录。这些文件实际上都是从 Git 目录中的压缩对 象数据库中提取出来的,接下来就可以在工作目录中对这些文件进行编辑。 所谓的暂存区域只不过是个简单的文件,一般都放在 Git 目录中。有时候人们会把这个文件叫做索引文件,不过标准说法还 是叫暂存区域。 基本的 Git 工作流程如下: 1. 在工作目录中修改某些文件。 2. 对修改后的文件进行快照,然后保存到暂存区域。 3. 提交更新,将保存在暂存区域的文件快照永久转储到 Git 目录中。 所以,我们可以从文件所处的位置来判断状态:如果是 Git 目录中保存着的特定版本文件,就属于已提交状态;如果作了修 改并已放入暂存区域,就属于已暂存状态;如果自上次取出后,作了修改但还没有放到暂存区域,就是已修改状态。到第二 章的时候,我们会进一步了解其中细节,并学会如何根据文件状态实施后续操作,以及怎样跳过暂存直接提交。 是时候动手尝试下 Git 了,不过得先安装好它。有许多种安装方式,主要分为两种,一种是通过编译源代码来安装;另一种 是使用为特定平台预编译好的安装包。 若是条件允许,从源代码安装有很多好处,至少可以安装最新的版本。Git 的每个版本都在不断尝试改进用户体验,所以能通 过源代码自己编译安装最新版本就再好不过了。有些 Linux 版本自带的安装包更新起来并不及时,所以除非你在用最新的 distro 或者 backports,那么从源代码安装其实该算是最佳选择。 Git 的工作需要调用 curl,zlib,openssl,expat,libiconv 等库的代码,所以需要先安装这些依赖工具。在有 yum 的系统上 (比如 Fedora)或者有 apt-get 的系统上(比如 Debian 体系),可以用下面的命令安装: $ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel $ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \ libz-dev libssl-dev 之后,从下面的 Git 官方站点下载最新版本源代码: http://git-scm.com/download 然后编译并安装: $ tar -zxf git-1.7.2.2.tar.gz $ cd git-1.7.2.2 $ make prefix=/usr/local all $ sudo make prefix=/usr/local install 现在已经可以用 git 命令了,用 git 把 Git 项目仓库克隆到本地,以便日后随时更新: $ git clone git://git.kernel.org/pub/scm/git/git.git 如果要在 Linux 上安装预编译好的 Git 二进制安装包,可以直接用系统提供的包管理工具。在 Fedora 上用 yum 安装: $ yum install git-core 在 Ubuntu 这类 Debian 体系的系统上,可以用 apt-get 安装: $ apt-get install git 在 Mac 上安装 Git 有两种方式。最容易的当属使用图形化的 Git 安装工具,界面如图 1-7,下载地址在: 安装 Git 从源代码安装 在 Linux 上安装 在 Mac 上安装 http://code.google.com/p/git-osx-installer 图 1-7. Git OS X 安装工具 另一种是通过 MacPorts ( http://www.macports.org ) 安装。如果已经装好了 MacPorts,用下面的命令安装 Git: $ sudo port install git-core +svn +doc +bash_completion +gitweb 这种方式就不需要再自己安装依赖库了,Macports 会帮你搞定这些麻烦事。一般上面列出的安装选项已经够用,要是你想用 Git 连接 Subversion 的代码仓库,还可以加上 +svn 选项,具体将在第八章作介绍。(译注:还有一种是使用 homebrew( https://github.com/mxcl/homebrew ): brew install git 。) 在 Windows 上安装 Git 同样轻松,有个叫做 msysGit 的项目提供了安装包,可以到 GitHub 的页面上下载 exe 安装文件并运 行: http://msysgit.github.com/ 完成安装之后,就可以使用命令行的 git 工具(已经自带了 ssh 客户端)了,另外还有一个图形界面的 Git 项目管理工具。 给 Windows 用户的敬告:你应该在 msysGit 提供的 Unix 风格的 shell 来运行 Git。在 Unix 风格的 shell 中,可以使用本书 中提及的复杂多行的命令。对于那些需要在 Windows 命令行中使用 Git 的用户,必须注意:在参数中间有空格的时候,必须 使用双引号将参数括起来(在 Linux 中是单引号);另外,如果扬抑符(^)作为参数的结尾,并且作为这一行的最后一个字 符,则这个参数也需要用双引号括起来。因为扬抑符在 Windows 命令行中表示续行(译注:即下一行为这一行命令的继 续)。 在 Windows 上安装 一般在新的系统上,我们都需要先配置下自己的 Git 工作环境。配置工作只需一次,以后升级时还会沿用现在的配置。当 然,如果需要,你随时可以用相同的命令修改已有的配置。 Git 提供了一个叫做 git config 的工具(译注:实际是 git-config 命令,只不过可以通过 git 加一个名字来呼叫此命令。), 专门用来配置或读取相应的工作环境变量。而正是由这些环境变量,决定了 Git 在各个环节的具体工作方式和行为。这些变 量可以存放在以下三个不同的地方: /etc/gitconfig 文件:系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项,读写的就是这个文 件。 ~/.gitconfig 文件:用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项,读写的就是这个文 件。 当前项目的 git 目录中的配置文件(也就是工作目录中的 .git/config 文件):这里的配置仅仅针对当前项目有效。每一个 级别的配置都会覆盖上层的相同配置,所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。 在 Windows 系统上,Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录,一般都是 C:\Documents and Settings\$USER 。此外,Git 还会尝试找寻 /etc/gitconfig 文件,只不过看当初 Git 装在什么目录,就以此作 为根目录来定位。 第一个要配置的是你个人的用户名称和电子邮件地址。这两条配置很重要,每次 Git 提交时都会引用这两条信息,说明是谁 提交了更新,所以会随更新内容一起被永久纳入历史记录: $ git config --global user.name "John Doe" $ git config --global user.email johndoe@example.com 如果用了 --global 选项,那么更改的配置文件就是位于你用户主目录下的那个,以后你所有的项目都会默认使用这里配置的 用户信息。如果要在某个特定的项目中使用其他名字或者电邮,只要去掉 --global 选项重新配置即可,新的设定保存在当前 项目的 .git/config 文件里。 接下来要设置的是默认使用的文本编辑器。Git 需要你输入一些额外消息的时候,会自动调用一个外部文本编辑器给你用。默 认会使用操作系统指定的默认编辑器,一般可能会是 Vi 或者 Vim。如果你有其他偏好,比如 Emacs 的话,可以重新设置: $ git config --global core.editor emacs 还有一个比较常用的是,在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话: $ git config --global merge.tool vimdiff Git 可以理解 kdiff3,tkdiff,meld,xxdiff,emerge,vimdiff,gvimdiff,ecmerge,和 opendiff 等合并工具的输出信息。当 然,你也可以指定使用自己开发的工具,具体怎么做可以参阅第七章。 初次运行 Git 前的配置 用户信息 文本编辑器 差异分析工具 查看配置信息 要检查已有的配置信息,可以使用 git config --list 命令: $ git config --list user.name=Scott Chacon user.email=schacon@gmail.com color.status=auto color.branch=auto color.interactive=auto color.diff=auto ... 有时候会看到重复的变量名,那就说明它们来自不同的配置文件(比如 /etc/gitconfig 和 ~/.gitconfig ),不过最终 Git 实际采 用的是最后一个。 也可以直接查阅某个环境变量的设定,只要把特定的名字跟在后面即可,像这样: $ git config user.name Scott Chacon 想了解 Git 的各式工具该怎么用,可以阅读它们的使用帮助,方法有三: $ git help $ git --help $ man git- 比如,要学习 config 命令可以怎么用,运行: $ git help config 我们随时都可以浏览这些帮助信息而无需连网。 不过,要是你觉得还不够,可以到 Freenode IRC 服务器 (irc.freenode.net)上的 #git 或 #github 频道寻求他人帮助。这两个频道上总有着上百号人,大多都有着丰富的 git 知 识,并且乐于助人。 获取帮助 至此,你该对 Git 有了点基本认识,包括它和以前你使用的 CVCS 之间的差别。现在,在你的系统上应该已经装好了 Git,设 置了自己的名字和电邮。接下来让我们继续学习 Git 的基础知识。 小结 读完本章你就能上手使用 Git 了。本章将介绍几个最基本的,也是最常用的 Git 命令,以后绝大多数时间里用到的也就是这几 个命令。读完本章,你就能初始化一个新的代码仓库,做一些适当配置;开始或停止跟踪某些文件;暂存或提交某些更新。 我们还会展示如何让 Git 忽略某些文件,或是名称符合特定模式的文件;如何既快且容易地撤消犯下的小错误;如何浏览项 目的更新历史,查看某两次更新之间的差异;以及如何从远程仓库拉数据下来或者推数据上去。 Git 基础 有两种取得 Git 项目仓库的方法。第一种是在现存的目录下,通过导入所有文件来创建新的 Git 仓库。第二种是从已有的 Git 仓库克隆出一个新的镜像仓库来。 要对现有的某个项目开始用 Git 管理,只需到此项目所在的目录,执行: $ git init 初始化后,在当前目录下会出现一个名为 .git 的目录,所有 Git 需要的数据和资源都存放在这个目录中。不过目前,仅仅是按 照既有的结构框架初始化好了里边所有的文件和目录,但我们还没有开始跟踪管理项目中的任何一个文件。(在第九章我们 会详细说明刚才创建的 .git 目录中究竟有哪些文件,以及都起些什么作用。) 如果当前目录下有几个文件想要纳入版本控制,需要先用 git add 命令告诉 Git 开始对这些文件进行跟踪,然后提交: $ git add *.c $ git add README $ git commit -m 'initial project version' 稍后我们再逐一解释每条命令的意思。不过现在,你已经得到了一个实际维护着若干文件的 Git 仓库。 如果想对某个开源项目出一份力,可以先把该项目的 Git 仓库复制一份出来,这就需要用到 git clone 命令。如果你熟悉其他 的 VCS 比如 Subversion,你可能已经注意到这里使用的是 clone 而不是 checkout 。这是个非常重要的差别,Git 收取的是 项目历史的所有数据(每一个文件的每一个版本),服务器上有的数据克隆之后本地也都有了。实际上,即便服务器的磁盘 发生故障,用任何一个克隆出来的客户端都可以重建服务器上的仓库,回到当初克隆时的状态(虽然可能会丢失某些服务器 端的挂钩设置,但所有版本的数据仍旧还在,有关细节请参考第四章)。 克隆仓库的命令格式为 git clone [url] 。比如,要克隆 Ruby 语言的 Git 代码仓库 Grit,可以用下面的命令: $ git clone git://github.com/schacon/grit.git 这会在当前目录下创建一个名为 grit 的目录,其中包含一个 .git 的目录,用于保存下载下来的所有版本记录,然后从中取出 最新版本的文件拷贝。如果进入这个新建的 grit 目录,你会看到项目中的所有文件已经在里边了,准备好后续的开发和使 用。如果希望在克隆的时候,自己定义要新建的项目目录名称,可以在上面的命令末尾指定新的名字: $ git clone git://github.com/schacon/grit.git mygrit 唯一的差别就是,现在新建的目录成了 mygrit ,其他的都和上边的一样。 Git 支持许多数据传输协议。之前的例子使用的是 git:// 协议,不过你也可以用 http(s):// 或者 user@server:/path.git 表示的 SSH 传输协议。我们会在第四章详细介绍所有这些协议在服务器端该如何配置使用,以及各种方式之间的利弊。 取得项目的 Git 仓库 在工作目录中初始化新仓库 从现有仓库克隆 现在我们手上已经有了一个真实项目的 Git 仓库,并从这个仓库中取出了所有文件的工作拷贝。接下来,对这些文件作些修 改,在完成了一个阶段的目标之后,提交本次更新到仓库。 请记住,工作目录下面的所有文件都不外乎这两种状态:已跟踪或未跟踪。已跟踪的文件是指本来就被纳入版本控制管理的 文件,在上次快照中有它们的记录,工作一段时间后,它们的状态可能是未更新,已修改或者已放入暂存区。而所有其他文 件都属于未跟踪文件。它们既没有上次更新时的快照,也不在当前的暂存区域。初次克隆某个仓库时,工作目录中的所有文 件都属于已跟踪文件,且状态为未修改。 在编辑过某些文件之后,Git 将这些文件标为已修改。我们逐步把这些修改过的文件放到暂存区域,直到最后一次性提交所有 这些暂存起来的文件,如此重复。所以使用 Git 时的文件状态变化周期如图 2-1 所示。 图 2-1. 文件的状态变化周期 要确定哪些文件当前处于什么状态,可以用 git status 命令。如果在克隆仓库之后立即执行此命令,会看到类似这样的输 出: $ git status On branch master nothing to commit, working directory clean 这说明你现在的工作目录相当干净。换句话说,所有已跟踪文件在上次提交后都未被更改过。此外,上面的信息还表明,当 前目录下没有出现任何处于未跟踪的新文件,否则 Git 会在这里列出来。最后,该命令还显示了当前所在的分支是 master , 这是默认的分支名称,实际是可以修改的,现在先不用考虑。下一章我们就会详细讨论分支和引用。 现在让我们用 vim 创建一个新文件 README,保存退出后运行 git status 会看到该文件出现在未跟踪文件列表中: 记录每次更新到仓库 检查当前文件状态 $ vim README $ git status On branch master Untracked files: (use "git add ..." to include in what will be committed) README nothing added to commit but untracked files present (use "git add" to track) 在状态报告中可以看到新建的 README 文件出现在“Untracked files”下面。未跟踪的文件意味着Git在之前的快照(提交)中没 有这些文件;Git 不会自动将之纳入跟踪范围,除非你明明白白地告诉它“我需要跟踪该文件”,因而不用担心把临时文件什么 的也归入版本管理。不过现在的例子中,我们确实想要跟踪管理 README 这个文件。 使用命令 git add 开始跟踪一个新文件。所以,要跟踪 README 文件,运行: $ git add README 此时再运行 git status 命令,会看到 README 文件已被跟踪,并处于暂存状态: $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) new file: README 只要在 “Changes to be committed” 这行下面的,就说明是已暂存状态。如果此时提交,那么该文件此时此刻的版本将被留 存在历史记录中。你可能会想起之前我们使用 git init 后就运行了 git add 命令,开始跟踪当前目录下的文件。在 git add 后 面可以指明要跟踪的文件或目录路径。如果是目录的话,就说明要递归跟踪该目录下的所有文件。(译注:其实 git add 的 潜台词就是把目标文件快照放入暂存区域,也就是 add file into staged area,同时未曾跟踪过的文件标记为需要跟踪。这样 就好理解后续 add 操作的实际意义了。) 现在我们修改下之前已跟踪过的文件 benchmarks.rb ,然后再次运行 status 命令,会看到这样的状态报告: $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) new file: README Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: benchmarks.rb 文件 benchmarks.rb 出现在 “Changes not staged for commit” 这行下面,说明已跟踪文件的内容发生了变化,但还没有放到 暂存区。要暂存这次更新,需要运行 git add 命令(这是个多功能命令,根据目标文件的状态不同,此命令的效果也不同: 可以用它开始跟踪新文件,或者把已跟踪的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态等)。现在 让我们运行 git add 将 benchmarks.rb 放到暂存区,然后再看看 git status 的输出: 跟踪新文件 暂存已修改文件 $ git add benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) new file: README modified: benchmarks.rb 现在两个文件都已暂存,下次提交时就会一并记录到仓库。假设此时,你想要在 benchmarks.rb 里再加条注释,重新编辑存 盘后,准备好提交。不过且慢,再运行 git status 看看: $ vim benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) new file: README modified: benchmarks.rb Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: benchmarks.rb 怎么回事? benchmarks.rb 文件出现了两次!一次算未暂存,一次算已暂存,这怎么可能呢?好吧,实际上 Git 只不过暂存 了你运行 git add 命令时的版本,如果现在提交,那么提交的是添加注释前的版本,而非当前工作目录中的版本。所以,运 行了 git add 之后又作了修订的文件,需要重新运行 git add 把最新版本重新暂存起来: $ git add benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) new file: README modified: benchmarks.rb 一般我们总会有些文件无需纳入 Git 的管理,也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件,比如日 志文件,或者编译过程中创建的临时文件等。我们可以创建一个名为 .gitignore 的文件,列出要忽略的文件模式。来看一个 实际的例子: $ cat .gitignore *.[oa] *~ 第一行告诉 Git 忽略所有以 .o 或 .a 结尾的文件。一般这类对象文件和存档文件都是编译过程中出现的,我们用不着跟踪它 们的版本。第二行告诉 Git 忽略所有以波浪符( ~ )结尾的文件,许多文本编辑软件(比如 Emacs)都用这样的文件名保存 副本。此外,你可能还需要忽略 log , tmp 或者 pid 目录,以及自动生成的文档等等。要养成一开始就设置好 .gitignore 文 件的习惯,以免将来误提交这类无用的文件。 文件 .gitignore 的格式规范如下: 所有空行或者以注释符号 # 开头的行都会被 Git 忽略。 可以使用标准的 glob 模式匹配。 匹配模式最后跟反斜杠( / )说明要忽略的是目录。 忽略某些文件 要忽略指定模式以外的文件或目录,可以在模式前加上惊叹号( ! )取反。 所谓的 glob 模式是指 shell 所使用的简化了的正则表达式。星号( * )匹配零个或多个任意字符; [abc] 匹配任何一个列在 方括号中的字符(这个例子要么匹配一个 a,要么匹配一个 b,要么匹配一个 c);问号( ? )只匹配一个任意字符;如果在 方括号中使用短划线分隔两个字符,表示所有在这两个字符范围内的都可以匹配(比如 [0-9] 表示匹配所有 0 到 9 的数 字)。 我们再看一个 .gitignore 文件的例子: # 此为注释 – 将被 Git 忽略 # 忽略所有 .a 结尾的文件 *.a # 但 lib.a 除外 !lib.a # 仅仅忽略项目根目录下的 TODO 文件,不包括 subdir/TODO /TODO # 忽略 build/ 目录下的所有文件 build/ # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt doc/*.txt # ignore all .txt files in the doc/ directory doc/**/*.txt A **/ pattern is available in Git since version 1.8.2. 实际上 git status 的显示比较简单,仅仅是列出了修改过的文件,如果要查看具体修改了什么地方,可以用 git diff 命令。稍 后我们会详细介绍 git diff ,不过现在,它已经能回答我们的两个问题了:当前做的哪些更新还没有暂存?有哪些更新已经暂 存起来准备好了下次提交? git diff 会使用文件补丁的格式显示具体添加和删除的行。 假如再次修改 README 文件后暂存,然后编辑 benchmarks.rb 文件后先别暂存,运行 status 命令将会看到: $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) new file: README Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: benchmarks.rb 要查看尚未暂存的文件更新了哪些部分,不加参数直接输入 git diff : $ git diff diff --git a/benchmarks.rb b/benchmarks.rb index 3cb747f..da65585 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -36,6 +36,10 @@ def main @commit.parents[0].parents[0].parents[0] end + run_code(x, 'commits 1') do + git.commits.size + end + run_code(x, 'commits 2') do log = git.commits('master', 15) log.size 查看已暂存和未暂存的更新 此命令比较的是工作目录中当前文件和暂存区域快照之间的差异,也就是修改之后还没有暂存起来的变化内容。 若要看已经暂存起来的文件和上次提交时的快照之间的差异,可以用 git diff --cached 命令。(Git 1.6.1 及更高版本还允许使 用 git diff --staged ,效果是相同的,但更好记些。)来看看实际的效果: $ git diff --cached diff --git a/README b/README new file mode 100644 index 0000000..03902a1 --- /dev/null +++ b/README2 @@ -0,0 +1,5 @@ +grit + by Tom Preston-Werner, Chris Wanstrath + http://github.com/mojombo/grit + +Grit is a Ruby library for extracting information from a Git repository 请注意,单单 git diff 不过是显示还没有暂存起来的改动,而不是这次工作和上次提交之间的差异。所以有时候你一下子暂存 了所有更新过的文件后,运行 git diff 后却什么也没有,就是这个原因。 像之前说的,暂存 benchmarks.rb 后再编辑,运行 git status 会看到暂存前后的两个版本: $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) modified: benchmarks.rb Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: benchmarks.rb 现在运行 git diff 看暂存前后的变化: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb index e445e28..86b2f7c 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -127,3 +127,4 @@ end main() ##pp Grit::GitRuby.cache_client.stats +# test line 然后用 git diff --cached 查看已经暂存起来的变化: $ git diff --cached diff --git a/benchmarks.rb b/benchmarks.rb index 3cb747f..e445e28 100644 --- a/benchmarks.rb +++ b/benchmarks.rb @@ -36,6 +36,10 @@ def main @commit.parents[0].parents[0].parents[0] end + run_code(x, 'commits 1') do + git.commits.size + end + run_code(x, 'commits 2') do log = git.commits('master', 15) log.size 现在的暂存区域已经准备妥当可以提交了。在此之前,请一定要确认还有什么修改过的或新建的文件还没有 git add 过,否 则提交的时候不会记录这些还没暂存起来的变化。所以,每次准备提交前,先用 git status 看下,是不是都已暂存起来了, 然后再运行提交命令 git commit : $ git commit 这种方式会启动文本编辑器以便输入本次提交的说明。(默认会启用 shell 的环境变量 $EDITOR 所指定的软件,一般都是 vim 或 emacs。当然也可以按照第一章介绍的方式,使用 git config --global core.editor 命令设定你喜欢的编辑软件。) 编辑器会显示类似下面的文本信息(本例选用 Vim 的屏显方式展示): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # new file: README # modified: benchmarks.rb # ~ ~ ~ ".git/COMMIT_EDITMSG" 10L, 283C 可以看到,默认的提交消息包含最后一次运行 git status 的输出,放在注释行里,另外开头还有一空行,供你输入提交说 明。你完全可以去掉这些注释行,不过留着也没关系,多少能帮你回想起这次更新的内容有哪些。(如果觉得这还不够,可 以用 -v 选项将修改差异的每一行都包含到注释中来。)退出编辑器时,Git 会丢掉注释行,将说明内容和本次更新提交到仓 库。 另外也可以用 -m 参数后跟提交说明的方式,在一行命令中提交更新: $ git commit -m "Story 182: Fix benchmarks for speed" [master 463dc4f] Fix benchmarks for speed 2 files changed, 3 insertions(+) create mode 100644 README 好,现在你已经创建了第一个提交!可以看到,提交后它会告诉你,当前是在哪个分支(master)提交的,本次提交的完整 SHA-1 校验和是什么( 463dc4f ),以及在本次提交中,有多少文件修订过,多少行添改和删改过。 记住,提交时记录的是放在暂存区域的快照,任何还未暂存的仍然保持已修改状态,可以在下次提交时纳入版本管理。每一 次运行提交操作,都是对你项目作一次快照,以后可以回到这个状态,或者进行比较。 提交更新 尽管使用暂存区域的方式可以精心准备要提交的细节,但有时候这么做略显繁琐。Git 提供了一个跳过使用暂存区域的方式, 只要在提交的时候,给 git commit 加上 -a 选项,Git 就会自动把所有已经跟踪过的文件暂存起来一并提交,从而跳过 git add 步骤: $ 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: benchmarks.rb no changes added to commit (use "git add" and/or "git commit -a") $ git commit -a -m 'added new benchmarks' [master 83e38c7] added new benchmarks 1 files changed, 5 insertions(+) 看到了吗?提交之前不再需要 git add 文件 benchmarks.rb 了。 要从 Git 中移除某个文件,就必须要从已跟踪文件清单中移除(确切地说,是从暂存区域移除),然后提交。可以用 git rm 命令完成此项工作,并连带从工作目录中删除指定的文件,这样以后就不会出现在未跟踪文件清单中了。 如果只是简单地从工作目录中手工删除文件,运行 git status 时就会在 “Changes not staged for commit” 部分(也就是未暂 存清单)看到: $ rm grit.gemspec $ git status On branch master Changes not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) deleted: grit.gemspec no changes added to commit (use "git add" and/or "git commit -a") 然后再运行 git rm 记录此次移除文件的操作: $ git rm grit.gemspec rm 'grit.gemspec' $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) deleted: grit.gemspec 最后提交的时候,该文件就不再纳入版本管理了。如果删除之前修改过并且已经放到暂存区域的话,则必须要用强制删除选 项 -f (译注:即 force 的首字母),以防误删除文件后丢失修改的内容。 另外一种情况是,我们想把文件从 Git 仓库中删除(亦即从暂存区域移除),但仍然希望保留在当前工作目录中。换句话 说,仅是从跟踪清单中删除。比如一些大型日志文件或者一堆 .a 编译文件,不小心纳入仓库后,要移除跟踪但不删除文 件,以便稍后在 .gitignore 文件中补上,用 --cached 选项即可: $ git rm --cached readme.txt 跳过使用暂存区域 移除文件 后面可以列出文件或者目录的名字,也可以使用 glob 模式。比方说: $ git rm log/\*.log 注意到星号 * 之前的反斜杠 \ ,因为 Git 有它自己的文件模式扩展匹配方式,所以我们不用 shell 来帮忙展开(译注:实际 上不加反斜杠也可以运行,只不过按照 shell 扩展的话,仅仅删除指定目录下的文件而不会递归匹配。上面的例子本来就指 定了目录,所以效果等同,但下面的例子就会用递归方式匹配,所以必须加反斜杠。)。此命令删除所有 log/ 目录下扩展名 为 .log 的文件。类似的比如: $ git rm \*~ 会递归删除当前目录及其子目录中所有 ~ 结尾的文件。 不像其他的 VCS 系统,Git 并不跟踪文件移动操作。如果在 Git 中重命名了某个文件,仓库中存储的元数据并不会体现出这 是一次改名操作。不过 Git 非常聪明,它会推断出究竟发生了什么,至于具体是如何做到的,我们稍后再谈。 既然如此,当你看到 Git 的 mv 命令时一定会困惑不已。要在 Git 中对文件改名,可以这么做: $ git mv file_from file_to 它会恰如预期般正常工作。实际上,即便此时查看状态信息,也会明白无误地看到关于重命名操作的说明: $ git mv README.txt README $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) renamed: README.txt -> README 其实,运行 git mv 就相当于运行了下面三条命令: $ mv README.txt README $ git rm README.txt $ git add README 如此分开操作,Git 也会意识到这是一次改名,所以不管何种方式都一样。当然,直接用 git mv 轻便得多,不过有时候用其 他工具批处理改名的话,要记得在提交前删除老的文件名,再添加新的文件名。 移动文件 在提交了若干更新之后,又或者克隆了某个项目,想回顾下提交历史,可以使用 git log 命令查看。 接下来的例子会用我专门用于演示的 simplegit 项目,运行下面的命令获取该项目源代码: git clone git://github.com/schacon/simplegit-progit.git 然后在此项目中运行 git log ,应该会看到下面的输出: $ git log commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon Date: Sat Mar 15 16:40:33 2008 -0700 removed unnecessary test code commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon Date: Sat Mar 15 10:31:28 2008 -0700 first commit 默认不用任何参数的话, git log 会按提交时间列出所有的更新,最近的更新排在最上面。看到了吗,每次更新都有一个 SHA-1 校验和、作者的名字和电子邮件地址、提交时间,最后缩进一个段落显示提交说明。 git log 有许多选项可以帮助你搜寻感兴趣的提交,接下来我们介绍些最常用的。 我们常用 -p 选项展开显示每次提交的内容差异,用 -2 则仅显示最近的两次更新: 查看提交历史 $ git log -p -2 commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number diff --git a/Rakefile b/Rakefile index a874b73..8f94139 100644 --- a/Rakefile +++ b/Rakefile @@ -5,5 +5,5 @@ require 'rake/gempackagetask' spec = Gem::Specification.new do |s| s.name = "simplegit" - s.version = "0.1.0" + s.version = "0.1.1" s.author = "Scott Chacon" s.email = "schacon@gee-mail.com commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon Date: Sat Mar 15 16:40:33 2008 -0700 removed unnecessary test code diff --git a/lib/simplegit.rb b/lib/simplegit.rb index a0a60ae..47c6340 100644 --- a/lib/simplegit.rb +++ b/lib/simplegit.rb @@ -18,8 +18,3 @@ class SimpleGit end end - -if $0 == __FILE__ - git = SimpleGit.new - puts git.show -end \ No newline at end of file 该选项除了显示基本信息之外,还在附带了每次 commit 的变化。当进行代码审查,或者快速浏览某个搭档提交的 commit 的 变化的时候,这个参数就非常有用了。 某些时候,单词层面的对比,比行层面的对比,更加容易观察。Git 提供了 --word-diff 选项。我们可以将其添加到 git log -p 命令的后面,从而获取单词层面上的对比。在程序代码中进行单词层面的对比常常是没什么用的。不过当你需要在书籍、论 文这种很大的文本文件上进行对比的时候,这个功能就显出用武之地了。下面是一个简单的例子: $ git log -U1 --word-diff commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number diff --git a/Rakefile b/Rakefile index a874b73..8f94139 100644 --- a/Rakefile +++ b/Rakefile @@ -7,3 +7,3 @@ spec = Gem::Specification.new do |s| s.name = "simplegit" s.version = [-"0.1.0"-]{+"0.1.1"+} s.author = "Scott Chacon" 如你所见,这里并没有平常看到的添加行或者删除行的信息。这里的对比显示在行间。新增加的单词被 {+ +} 括起来,被删 除的单词被 [- -] 括起来。在进行单词层面的对比的时候,你可能希望上下文( context )行数从默认的 3 行,减为 1 行,那 么可以使用 -U1 选项。上面的例子中,我们就使用了这个选项。 另外, git log 还提供了许多摘要选项可以用,比如 --stat ,仅显示简要的增改行数统计: $ git log --stat commit ca82a6dff817ec66f44342007202690a93763949 Author: Scott Chacon Date: Mon Mar 17 21:52:11 2008 -0700 changed the version number Rakefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon Date: Sat Mar 15 16:40:33 2008 -0700 removed unnecessary test code lib/simplegit.rb | 5 ----- 1 file changed, 5 deletions(-) commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon Date: Sat Mar 15 10:31:28 2008 -0700 first commit README | 6 ++++++ Rakefile | 23 +++++++++++++++++++++++ lib/simplegit.rb | 25 +++++++++++++++++++++++++ 3 files changed, 54 insertions(+) 每个提交都列出了修改过的文件,以及其中添加和移除的行数,并在最后列出所有增减行数小计。 还有个常用的 --pretty 选 项,可以指定使用完全不同于默认格式的方式展示提交历史。比如用 oneline 将每个提交放在一行显示,这在提交数很大时 非常有用。另外还有 short , full 和 fuller 可以用,展示的信息或多或少有些不同,请自己动手实践一下看看效果如何。 $ git log --pretty=oneline ca82a6dff817ec66f44342007202690a93763949 changed the version number 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code a11bef06a3f659402fe7563abf99ad00de2209e6 first commit 但最有意思的是 format ,可以定制要显示的记录格式,这样的输出便于后期编程提取分析,像这样: $ git log --pretty=format:"%h - %an, %ar : %s" ca82a6d - Scott Chacon, 11 months ago : changed the version number 085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code a11bef0 - Scott Chacon, 11 months ago : first commit 表 2-1 列出了常用的格式占位符写法及其代表的意义。 选项 说明 %H 提交对象(commit)的完整哈希字串 %h 提交对象的简短哈希字串 %T 树对象(tree)的完整哈希字串 %t 树对象的简短哈希字串 %P 父对象(parent)的完整哈希字串 %p 父对象的简短哈希字串 %an 作者(author)的名字 %ae 作者的电子邮件地址 %ad 作者修订日期(可以用 -date= 选项定制格式) %ar 作者修订日期,按多久以前的方式显示 %cn 提交者(committer)的名字 %ce 提交者的电子邮件地址 %cd 提交日期 %cr 提交日期,按多久以前的方式显示 %s 提交说明 你一定奇怪作者(author)和提交者(committer)之间究竟有何差别,其实作者指的是实际作出修改的人,提交者指的是最 后将此工作成果提交到仓库的人。所以,当你为某个项目发布补丁,然后某个核心成员将你的补丁并入项目时,你就是作 者,而那个核心成员就是提交者。我们会在第五章再详细介绍两者之间的细微差别。 用 oneline 或 format 时结合 --graph 选项,可以看到开头多出一些 ASCII 字符串表示的简单图形,形象地展示了每个提交所 在的分支及其分化衍合情况。在我们之前提到的 Grit 项目仓库中可以看到: $ git log --pretty=format:"%h %s" --graph * 2d3acf9 ignore errors from SIGCHLD on trap * 5e3ee11 Merge branch 'master' of git://github.com/dustin/grit |\ | * 420eac9 Added a method for getting the current branch. * | 30e367c timeout code and tests * | 5a09431 add timeout protection to grit * | e1193f8 support for heads with slashes in them |/ * d6016bc require time for xmlschema * 11d191e Merge branch 'defunkt' into local 以上只是简单介绍了一些 git log 命令支持的选项。表 2-2 还列出了一些其他常用的选项及其释义。 选项 说明 -p 按补丁格式显示每个更新之间的差异。 --word-diff 按 word diff 格式显示差异。 --stat 显示每次更新的文件修改统计信息。 --shortstat 只显示 --stat 中最后的行数修改添加移除统计。 --name-only 仅在提交信息后显示已修改的文件清单。 --name-status 显示新增、修改、删除的文件清单。 --abbrev- commit 仅显示 SHA-1 的前几个字符,而非所有的 40 个字符。 --relative-date 使用较短的相对时间显示(比如,“2 weeks ago”)。 --graph 显示 ASCII 图形表示的分支合并历史。 --pretty 使用其他格式显示历史提交信息。可用的选项包括 oneline,short,full,fuller 和 format(后跟指 定格式)。 --oneline --pretty=oneline --abbrev-commit 的简化用法。 除了定制输出格式的选项之外, git log 还有许多非常实用的限制输出长度的选项,也就是只输出部分提交信息。之前我们已 经看到过 -2 了,它只显示最近的两条提交,实际上,这是 - 选项的写法,其中的 n 可以是任何自然数,表示仅显示最 近的若干条提交。不过实践中我们是不太用这个选项的,Git 在输出所有提交时会自动调用分页程序(less),要看更早的更 新只需翻到下页即可。 另外还有按照时间作限制的选项,比如 --since 和 --until 。下面的命令列出所有最近两周内的提交: 限制输出长度 $ git log --since=2.weeks 你可以给出各种时间格式,比如说具体的某一天(“2008-01-15”),或者是多久以前(“2 years 1 day 3 minutes ago”)。 还可以给出若干搜索条件,列出符合的提交。用 --author 选项显示指定作者的提交,用 --grep 选项搜索提交说明中的关键 字。(请注意,如果要得到同时满足这两个选项搜索条件的提交,就必须用 --all-match 选项。否则,满足任意一个条件的提 交都会被匹配出来) 另一个真正实用的 git log 选项是路径(path),如果只关心某些文件或者目录的历史提交,可以在 git log 选项的最后指定它们 的路径。因为是放在最后位置上的选项,所以用两个短划线( -- )隔开之前的选项和后面限定的路径名。 表 2-3 还列出了其他常用的类似选项。 选项 说明 -(n) 仅显示最近的 n 条提交 --since, --after 仅显示指定时间之后的提交。 --until, --before 仅显示指定时间之前的提交。 --author 仅显示指定作者相关的提交。 --committer 仅显示指定提交者相关的提交。 来看一个实际的例子,如果要查看 Git 仓库中,2008 年 10 月期间,Junio Hamano 提交的但未合并的测试脚本(位于项目 的 t/ 目录下的文件),可以用下面的查询命令: $ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \ --before="2008-11-01" --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f563754 - demonstrate breakage of detached checkout wi d1a43f2 - reset --hard/read-tree --reset -u: remove un 51a94af - Fix "checkout --track -b newbranch" on detac b0ad11e - pull: allow "git pull origin $something:$cur Git 项目有 20,000 多条提交,但我们给出搜索选项后,仅列出了其中满足条件的 6 条。 有时候图形化工具更容易展示历史提交的变化,随 Git 一同发布的 gitk 就是这样一种工具。它是用 Tcl/Tk 写成的,基本上相 当于 git log 命令的可视化版本,凡是 git log 可以用的选项也都能用在 gitk 上。在项目工作目录中输入 gitk 命令后,就会启 动图 2-2 所示的界面。 使用图形化工具查阅提交历史 图 2-2. gitk 的图形界面 上半个窗口显示的是历次提交的分支祖先图谱,下半个窗口显示当前点选的提交对应的具体差异。 任何时候,你都有可能需要撤消刚才所做的某些操作。接下来,我们会介绍一些基本的撤消操作相关的命令。请注意,有些 撤销操作是不可逆的,所以请务必谨慎小心,一旦失误,就有可能丢失部分工作成果。 有时候我们提交完了才发现漏掉了几个文件没有加,或者提交信息写错了。想要撤消刚才的提交操作,可以使用 --amend 选 项重新提交: $ git commit --amend 此命令将使用当前的暂存区域快照提交。如果刚才提交完没有作任何改动,直接运行此命令的话,相当于有机会重新编辑提 交说明,但将要提交的文件快照和之前的一样。 启动文本编辑器后,会看到上次提交时的说明,编辑它确认没问题后保存退出,就会使用新的提交说明覆盖刚才失误的提 交。 如果刚才提交时忘了暂存某些修改,可以先补上暂存操作,然后再运行 --amend 提交: $ git commit -m 'initial commit' $ git add forgotten_file $ git commit --amend 上面的三条命令最终只是产生一个提交,第二个提交命令修正了第一个的提交内容。 接下来的两个小节将演示如何取消暂存区域中的文件,以及如何取消工作目录中已修改的文件。不用担心,查看文件状态的 时候就提示了该如何撤消,所以不需要死记硬背。来看下面的例子,有两个修改过的文件,我们想要分开提交,但不小心用 git add . 全加到了暂存区域。该如何撤消暂存其中的一个文件呢?其实, git status 的命令输出已经告诉了我们该怎么做: $ git add . $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) modified: README.txt modified: benchmarks.rb 就在 “Changes to be committed” 下面,括号中有提示,可以使用 git reset HEAD ... 的方式取消暂存。好吧,我们来试 试取消暂存 benchmarks.rb 文件: 撤消操作 修改最后一次提交 取消已经暂存的文件 $ git reset HEAD benchmarks.rb Unstaged changes after reset: M benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) modified: README.txt Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: benchmarks.rb 这条命令看起来有些古怪,先别管,能用就行。现在 benchmarks.rb 文件又回到了之前已修改未暂存的状态。 如果觉得刚才对 benchmarks.rb 的修改完全没有必要,该如何取消修改,回到之前的状态(也就是修改之前的版本)呢? git status 同样提示了具体的撤消方法,接着上面的例子,现在未暂存区域看起来像这样: Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: benchmarks.rb 在第二个括号中,我们看到了抛弃文件修改的命令(至少在 Git 1.6.1 以及更高版本中会这样提示,如果你还在用老版本,我 们强烈建议你升级,以获取最佳的用户体验),让我们试试看: $ git checkout -- benchmarks.rb $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) modified: README.txt 可以看到,该文件已经恢复到修改前的版本。你可能已经意识到了,这条命令有些危险,所有对文件的修改都没有了,因为 我们刚刚把之前版本的文件复制过来重写了此文件。所以在用这条命令前,请务必确定真的不再需要保留刚才的修改。如果 只是想回退版本,同时保留刚才的修改以便将来继续工作,可以用下章介绍的 stashing 和分支来处理,应该会更好些。 记住,任何已经提交到 Git 的都可以被恢复。即便在已经删除的分支中的提交,或者用 --amend 重新改写的提交,都可以被 恢复(关于数据恢复的内容见第九章)。所以,你可能失去的数据,仅限于没有提交过的,对 Git 来说它们就像从未存在过 一样。 取消对文件的修改 要参与任何一个 Git 项目的协作,必须要了解该如何管理远程仓库。远程仓库是指托管在网络上的项目仓库,可能会有好多 个,其中有些你只能读,另外有些可以写。同他人协作开发某个项目时,需要管理这些远程仓库,以便推送或拉取数据,分 享各自的工作进展。 管理远程仓库的工作,包括添加远程库,移除废弃的远程库,管理各式远程库分支,定义是否跟踪这些 分支,等等。本节我们将详细讨论远程库的管理和使用。 要查看当前配置有哪些远程仓库,可以用 git remote 命令,它会列出每个远程库的简短名字。在克隆完某个项目后,至少可 以看到一个名为 origin 的远程库,Git 默认使用这个名字来标识你所克隆的原始仓库: $ git clone git://github.com/schacon/ticgit.git Cloning into 'ticgit'... remote: Reusing existing pack: 1857, done. remote: Total 1857 (delta 0), reused 0 (delta 0) Receiving objects: 100% (1857/1857), 374.35 KiB | 193.00 KiB/s, done. Resolving deltas: 100% (772/772), done. Checking connectivity... done. $ cd ticgit $ git remote origin 也可以加上 -v 选项(译注:此为 --verbose 的简写,取首字母),显示对应的克隆地址: $ git remote -v origin git://github.com/schacon/ticgit.git (fetch) origin git://github.com/schacon/ticgit.git (push) 如果有多个远程仓库,此命令将全部列出。比如在我的 Grit 项目中,可以看到: $ cd grit $ git remote -v bakkdoor git://github.com/bakkdoor/grit.git cho45 git://github.com/cho45/grit.git defunkt git://github.com/defunkt/grit.git koke git://github.com/koke/grit.git origin git@github.com:mojombo/grit.git 这样一来,我就可以非常轻松地从这些用户的仓库中,拉取他们的提交到本地。请注意,上面列出的地址只有 origin 用的是 SSH URL 链接,所以也只有这个仓库我能推送数据上去(我们会在第四章解释原因)。 要添加一个新的远程仓库,可以指定一个简单的名字,以便将来引用,运行 git remote add [shortname] [url] : $ git remote origin $ git remote add pb git://github.com/paulboone/ticgit.git $ git remote -v origin git://github.com/schacon/ticgit.git pb git://github.com/paulboone/ticgit.git 现在可以用字符串 pb 指代对应的仓库地址了。比如说,要抓取所有 Paul 有的,但本地仓库没有的信息,可以运行 git fetch pb : 远程仓库的使用 查看当前的远程库 添加远程仓库 $ git fetch pb remote: Counting objects: 58, done. remote: Compressing objects: 100% (41/41), done. remote: Total 44 (delta 24), reused 1 (delta 0) Unpacking objects: 100% (44/44), done. From git://github.com/paulboone/ticgit * [new branch] master -> pb/master * [new branch] ticgit -> pb/ticgit 现在,Paul 的主干分支(master)已经完全可以在本地访问了,对应的名字是 pb/master ,你可以将它合并到自己的某个分 支,或者切换到这个分支,看看有些什么有趣的更新。 正如之前所看到的,可以用下面的命令从远程仓库抓取数据到本地: $ git fetch [remote-name] 此命令会到远程仓库中拉取所有你本地仓库中还没有的数据。运行完成后,你就可以在本地访问该远程仓库中的所有分支, 将其中某个分支合并到本地,或者只是取出某个分支,一探究竟。(我们会在第三章详细讨论关于分支的概念和操作。) 如果是克隆了一个仓库,此命令会自动将远程仓库归于 origin 名下。所以, git fetch origin 会抓取从你上次克隆以来别人上 传到此远程仓库中的所有更新(或是上次 fetch 以来别人提交的更新)。有一点很重要,需要记住,fetch 命令只是将远端的 数据拉到本地仓库,并不自动合并到当前工作分支,只有当你确实准备好了,才能手工合并。 如果设置了某个分支用于跟踪某个远端仓库的分支(参见下节及第三章的内容),可以使用 git pull 命令自动抓取数据下 来,然后将远端分支自动合并到本地仓库中当前分支。在日常工作中我们经常这么用,既快且好。实际上,默认情况下 git clone 命令本质上就是自动创建了本地的 master 分支用于跟踪远程仓库中的 master 分支(假设远程仓库确实有 master 分 支)。所以一般我们运行 git pull ,目的都是要从原始克隆的远端仓库中抓取数据后,合并到工作目录中的当前分支。 项目进行到一个阶段,要同别人分享目前的成果,可以将本地仓库中的数据推送到远程仓库。实现这个任务的命令很简单: git push [remote-name] [branch-name] 。如果要把本地的 master 分支推送到 origin 服务器上(再次说明下,克隆操作会自动 使用默认的 master 和 origin 名字),可以运行下面的命令: $ git push origin master 只有在所克隆的服务器上有写权限,或者同一时刻没有其他人在推数据,这条命令才会如期完成任务。如果在你推数据前, 已经有其他人推送了若干更新,那你的推送操作就会被驳回。你必须先把他们的更新抓取到本地,合并到自己的项目中,然 后才可以再次推送。有关推送数据到远程仓库的详细内容见第三章。 我们可以通过命令 git remote show [remote-name] 查看某个远程仓库的详细信息,比如要看所克隆的 origin 仓库,可以运 行: 从远程仓库抓取数据 推送数据到远程仓库 查看远程仓库信息 $ git remote show origin * remote origin URL: git://github.com/schacon/ticgit.git Remote branch merged with 'git pull' while on branch master master Tracked remote branches master ticgit 除了对应的克隆地址外,它还给出了许多额外的信息。它友善地告诉你如果是在 master 分支,就可以用 git pull 命令抓取数 据合并到本地。另外还列出了所有处于跟踪状态中的远端分支。 上面的例子非常简单,而随着使用 Git 的深入, git remote show 给出的信息可能会像这样: $ git remote show origin * remote origin URL: git@github.com:defunkt/github.git Remote branch merged with 'git pull' while on branch issues issues Remote branch merged with 'git pull' while on branch master master New remote branches (next fetch will store in remotes/origin) caching Stale tracking branches (use 'git remote prune') libwalker walker2 Tracked remote branches acl apiv2 dashboard2 issues master postgres Local branch pushed with 'git push' master:master 它告诉我们,运行 git push 时缺省推送的分支是什么(译注:最后两行)。它还显示了有哪些远端分支还没有同步到本地 (译注:第六行的 caching 分支),哪些已同步到本地的远端分支在远端服务器上已被删除(译注: Stale tracking branches 下面的两个分支),以及运行 git pull 时将自动合并哪些分支(译注:前四行中列出的 issues 和 master 分支)。 在新版 Git 中可以用 git remote rename 命令修改某个远程仓库在本地的简称,比如想把 pb 改成 paul ,可以这么运行: $ git remote rename pb paul $ git remote origin paul 注意,对远程仓库的重命名,也会使对应的分支名称发生变化,原来的 pb/master 分支现在成了 paul/master 。 碰到远端仓库服务器迁移,或者原来的克隆镜像不再使用,又或者某个参与者不再贡献代码,那么需要移除对应的远端仓 库,可以运行 git remote rm 命令: $ git remote rm paul $ git remote origin 远程仓库的删除和重命名 同大多数 VCS 一样,Git 也可以对某一时间点上的版本打上标签。人们在发布某个软件版本(比如 v1.0 等等)的时候,经常 这么做。本节我们一起来学习如何列出所有可用的标签,如何新建标签,以及各种不同类型标签之间的差别。 列出现有标签的命令非常简单,直接运行 git tag 即可: $ git tag v0.1 v1.3 显示的标签按字母顺序排列,所以标签的先后并不表示重要程度的轻重。 我们可以用特定的搜索模式列出符合条件的标签。在 Git 自身项目仓库中,有着超过 240 个标签,如果你只对 1.4.2 系列的 版本感兴趣,可以运行下面的命令: $ git tag -l 'v1.4.2.*' v1.4.2.1 v1.4.2.2 v1.4.2.3 v1.4.2.4 Git 使用的标签有两种类型:轻量级的(lightweight)和含附注的(annotated)。轻量级标签就像是个不会变化的分支,实 际上它就是个指向特定提交对象的引用。而含附注标签,实际上是存储在仓库中的一个独立对象,它有自身的校验和信息, 包含着标签的名字,电子邮件地址和日期,以及标签说明,标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。 一般我们都建议使用含附注型的标签,以便保留相关信息;当然,如果只是临时性加注标签,或者不需要旁注额外信息,用 轻量级标签也没问题。 创建一个含附注类型的标签非常简单,用 -a (译注:取 annotated 的首字母)指定标签名字即可: $ git tag -a v1.4 -m 'my version 1.4' $ git tag v0.1 v1.3 v1.4 而 -m 选项则指定了对应的标签说明,Git 会将此说明一同保存在标签对象中。如果没有给出该选项,Git 会启动文本编辑软 件供你输入标签说明。 可以使用 git show 命令查看相应标签的版本信息,并连同显示打标签时的提交对象。 打标签 列显已有的标签 新建标签 含附注的标签 $ git show v1.4 tag v1.4 Tagger: Scott Chacon Date: Mon Feb 9 14:45:11 2009 -0800 my version 1.4 commit 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge: 4a447f7... a6b4c97... Author: Scott Chacon Date: Sun Feb 8 19:02:46 2009 -0800 Merge branch 'experiment' 我们可以看到在提交对象信息上面,列出了此标签的提交者和提交时间,以及相应的标签说明。 如果你有自己的私钥,还可以用 GPG 来签署标签,只需要把之前的 -a 改为 -s (译注: 取 signed 的首字母)即可: $ git tag -s v1.5 -m 'my signed 1.5 tag' You need a passphrase to unlock the secret key for user: "Scott Chacon " 1024-bit DSA key, ID F721C45A, created 2009-02-09 现在再运行 git show 会看到对应的 GPG 签名也附在其内: $ git show v1.5 tag v1.5 Tagger: Scott Chacon Date: Mon Feb 9 15:22:20 2009 -0800 my signed 1.5 tag -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEABECAAYFAkmQurIACgkQON3DxfchxFr5cACeIMN+ZxLKggJQf0QYiQBwgySN Ki0An2JeAVUCAiJ7Ox6ZEtK+NvZAj82/ =WryJ -----END PGP SIGNATURE----- commit 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge: 4a447f7... a6b4c97... Author: Scott Chacon Date: Sun Feb 8 19:02:46 2009 -0800 Merge branch 'experiment' 稍后我们再学习如何验证已经签署的标签。 轻量级标签实际上就是一个保存着对应提交对象的校验和信息的文件。要创建这样的标签,一个 -a , -s 或 -m 选项都不 用,直接给出标签名字即可: $ git tag v1.4-lw $ git tag v0.1 v1.3 v1.4 v1.4-lw v1.5 签署标签 轻量级标签 现在运行 git show 查看此标签信息,就只有相应的提交对象摘要: $ git show v1.4-lw commit 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge: 4a447f7... a6b4c97... Author: Scott Chacon Date: Sun Feb 8 19:02:46 2009 -0800 Merge branch 'experiment' 可以使用 git tag -v [tag-name] (译注:取 verify 的首字母)的方式验证已经签署的标签。此命令会调用 GPG 来验证签名, 所以你需要有签署者的公钥,存放在 keyring 中,才能验证: $ git tag -v v1.4.2.1 object 883653babd8ee7ea23e6a5c392bb739348b1eb61 type commit tag v1.4.2.1 tagger Junio C Hamano 1158138501 -0700 GIT 1.4.2.1 Minor fixes since 1.4.2, including git-mv and git-http with alternates. gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A gpg: Good signature from "Junio C Hamano " gpg: aka "[jpeg image of size 1513]" Primary key fingerprint: 3565 2A26 2040 E066 C9A7 4A7D C0C6 D9A4 F311 9B9A 若是没有签署者的公钥,会报告类似下面这样的错误: gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A gpg: Can't check signature: public key not found error: could not verify the tag 'v1.4.2.1' 你甚至可以在后期对早先的某次提交加注标签。比如在下面展示的提交历史中: $ git log --pretty=oneline 15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 0d52aaab4479697da7686c15f77a3d64d9165190 one more thing 6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment' 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function 4682c3261057305bdd616e23b64b0857d832627b added a todo file 166ae0c4d3f420721acbb115cc33848dfcc2121a started write support 9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile 964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme 我们忘了在提交 “updated rakefile” 后为此项目打上版本号 v1.2,没关系,现在也能做。只要在打标签的时候跟上对应提交 对象的校验和(或前几位字符)即可: $ git tag -a v1.2 9fceb02 可以看到我们已经补上了标签: 验证标签 后期加注标签 $ git tag v0.1 v1.2 v1.3 v1.4 v1.4-lw v1.5 $ git show v1.2 tag v1.2 Tagger: Scott Chacon Date: Mon Feb 9 15:32:16 2009 -0800 version 1.2 commit 9fceb02d0ae598e95dc970b74767f19372d61af8 Author: Magnus Chacon Date: Sun Apr 27 20:43:35 2008 -0700 updated rakefile ... 默认情况下, git push 并不会把标签传送到远端服务器上,只有通过显式命令才能分享标签到远端仓库。其命令格式如同推 送分支,运行 git push origin [tagname] 即可: $ git push origin v1.5 Counting objects: 50, done. Compressing objects: 100% (38/38), done. Writing objects: 100% (44/44), 4.56 KiB, done. Total 44 (delta 18), reused 8 (delta 1) To git@github.com:schacon/simplegit.git * [new tag] v1.5 -> v1.5 如果要一次推送所有本地新增的标签上去,可以使用 --tags 选项: $ git push origin --tags Counting objects: 50, done. Compressing objects: 100% (38/38), done. Writing objects: 100% (44/44), 4.56 KiB, done. Total 44 (delta 18), reused 8 (delta 1) To git@github.com:schacon/simplegit.git * [new tag] v0.1 -> v0.1 * [new tag] v1.2 -> v1.2 * [new tag] v1.4 -> v1.4 * [new tag] v1.4-lw -> v1.4-lw * [new tag] v1.5 -> v1.5 现在,其他人克隆共享仓库或拉取数据同步后,也会看到这些标签。 分享标签 在结束本章之前,我还想和大家分享一些 Git 使用的技巧和窍门。很多使用 Git 的开发者可能根本就没用过这些技巧,我们也 不是说在读过本书后非得用这些技巧不可,但至少应该有所了解吧。说实话,有了这些小窍门,我们的工作可以变得更简 单,更轻松,更高效。 如果你用的是 Bash shell,可以试试看 Git 提供的自动补全脚本。下载 Git 的源代码,进入 contrib/completion 目录,会看到 一个 git-completion.bash 文件。将此文件复制到你自己的用户主目录中(译注:按照下面的示例,还应改名加上点: cp git- completion.bash ~/.git-completion.bash ),并把下面一行内容添加到你的 .bashrc 文件中: source ~/.git-completion.bash 也可以为系统上所有用户都设置默认使用此脚本。Mac 上将此脚本复制到 /opt/local/etc/bash_completion.d 目录中,Linux 上 则复制到 /etc/bash_completion.d/ 目录中。这两处目录中的脚本,都会在 Bash 启动时自动加载。 如果在 Windows 上安装了 msysGit,默认使用的 Git Bash 就已经配好了这个自动补全脚本,可以直接使用。 在输入 Git 命令的时候可以敲两次跳格键(Tab),就会看到列出所有匹配的可用命令建议: $ git co commit config 此例中,键入 git co 然后连按两次 Tab 键,会看到两个相关的建议(命令) commit 和 config。继而输入 m 会自动完 成 git commit 命令的输入。 命令的选项也可以用这种方式自动完成,其实这种情况更实用些。比如运行 git log 的时候忘了相关选项的名字,可以输入开 头的几个字母,然后敲 Tab 键看看有哪些匹配的: $ git log --s --shortstat --since= --src-prefix= --stat --summary 这个技巧不错吧,可以节省很多输入和查阅文档的时间。 Git 并不会推断你输入的几个字符将会是哪条命令,不过如果想偷懒,少敲几个命令的字符,可以用 git config 为命令设置别 名。来看看下面的例子: $ git config --global alias.co checkout $ git config --global alias.br branch $ git config --global alias.ci commit $ git config --global alias.st status 现在,如果要输入 git commit 只需键入 git ci 即可。而随着 Git 使用的深入,会有很多经常要用到的命令,遇到这种情况, 不妨建个别名提高效率。 使用这种技术还可以创造出新的命令,比方说取消暂存文件时的输入比较繁琐,可以自己设置一下: 技巧和窍门 自动补全 Git 命令别名 $ git config --global alias.unstage 'reset HEAD --' 这样一来,下面的两条命令完全等同: $ git unstage fileA $ git reset HEAD fileA 显然,使用别名的方式看起来更清楚。另外,我们还经常设置 last 命令: $ git config --global alias.last 'log -1 HEAD' 然后要看最后一次的提交信息,就变得简单多了: $ git last commit 66938dae3329c7aebe598c2246a8e6af90d04646 Author: Josh Goebel Date: Tue Aug 26 19:48:51 2008 +0800 test for current head Signed-off-by: Scott Chacon 可以看出,实际上 Git 只是简单地在命令中替换了你设置的别名。不过有时候我们希望运行某个外部命令,而非 Git 的子命 令,这个好办,只需要在命令前加上 ! 就行。如果你自己写了些处理 Git 仓库信息的脚本的话,就可以用这种技术包装起 来。作为演示,我们可以设置用 git visual 启动 gitk : $ git config --global alias.visual '!gitk' 到目前为止,你已经学会了最基本的 Git 本地操作:创建和克隆仓库,做出修改,暂存并提交这些修改,以及查看所有历史 修改记录。接下来,我们将学习 Git 的必杀技特性:分支模型。 小结 几乎每一种版本控制系统都以某种形式支持分支。使用分支意味着你可以从开发主线上分离开来,然后在不影响主线的同时 继续工作。在很多版本控制系统中,这是个昂贵的过程,常常需要创建一个源代码目录的完整副本,对大型项目来说会花费 很长时间。 有人把 Git 的分支模型称为“必杀技特性”,而正是因为它,将 Git 从版本控制系统家族里区分出来。Git 有何特别之处呢?Git 的分支可谓是难以置信的轻量级,它的新建操作几乎可以在瞬间完成,并且在不同分支间切换起来也差不多一样快。和许多 其他版本控制系统不同,Git 鼓励在工作流程中频繁使用分支与合并,哪怕一天之内进行许多次都没有关系。理解分支的概念 并熟练运用后,你才会意识到为什么 Git 是一个如此强大而独特的工具,并从此真正改变你的开发方式。 Git 分支 为了理解 Git 分支的实现方式,我们需要回顾一下 Git 是如何储存数据的。或许你还记得第一章的内容,Git 保存的不是文件 差异或者变化量,而只是一系列文件快照。 在 Git 中提交时,会保存一个提交(commit)对象,该对象包含一个指向暂存内容快照的指针,包含本次提交的作者等相关 附属信息,包含零个或多个指向该提交对象的父对象指针:首次提交是没有直接祖先的,普通提交有一个祖先,由两个或多 个分支合并产生的提交则有多个祖先。 为直观起见,我们假设在工作目录中有三个文件,准备将它们暂存后提交。暂存操作会对每一个文件计算校验和(即第一章 中提到的 SHA-1 哈希字串),然后把当前版本的文件快照保存到 Git 仓库中(Git 使用 blob 类型的对象存储这些快照),并 将校验和加入暂存区域: $ git add README test.rb LICENSE $ git commit -m 'initial commit of my project' 当使用 git commit 新建一个提交对象前,Git 会先计算每一个子目录(本例中就是项目根目录)的校验和,然后在 Git 仓库中 将这些目录保存为树(tree)对象。之后 Git 创建的提交对象,除了包含相关提交信息以外,还包含着指向这个树对象(项目 根目录)的指针,如此它就可以在将来需要的时候,重现此次快照的内容了。 现在,Git 仓库中有五个对象:三个表示文件快照内容的 blob 对象;一个记录着目录树内容及其中各个文件对应 blob 对象索 引的 tree 对象;以及一个包含指向 tree 对象(根目录)的索引和其他提交信息元数据的 commit 对象。概念上来说,仓库中 的各个对象保存的数据和相互关系看起来如图 3-1 所示: 图 3-1. 单个提交对象在仓库中的数据结构 作些修改后再次提交,那么这次的提交对象会包含一个指向上次提交对象的指针(译注:即下图中的 parent 对象)。两次提 交后,仓库历史会变成图 3-2 的样子: 何谓分支 图 3-2. 多个提交对象之间的链接关系 现在来谈分支。Git 中的分支,其实本质上仅仅是个指向 commit 对象的可变指针。Git 会使用 master 作为分支的默认名字。 在若干次提交后,你其实已经有了一个指向最后一次提交对象的 master 分支,它在每次提交的时候都会自动向前移动。 图 3-3. 分支其实就是从某个提交对象往回看的历史 那么,Git 又是如何创建一个新的分支的呢?答案很简单,创建一个新的分支指针。比如新建一个 testing 分支,可以使用 git branch 命令: $ git branch testing 这会在当前 commit 对象上新建一个分支指针(见图 3-4)。 图 3-4. 多个分支指向提交数据的历史 那么,Git 是如何知道你当前在哪个分支上工作的呢?其实答案也很简单,它保存着一个名为 HEAD 的特别指针。请注意它 和你熟知的许多其他版本控制系统(比如 Subversion 或 CVS)里的 HEAD 概念大不相同。在 Git 中,它是一个指向你正在 工作中的本地分支的指针(译注:将 HEAD 想象为当前分支的别名。)。运行 git branch 命令,仅仅是建立了一个新的分 支,但不会自动切换到这个分支中去,所以在这个例子中,我们依然还在 master 分支里工作(参考图 3-5)。 图 3-5. HEAD 指向当前所在的分支 要切换到其他分支,可以执行 git checkout 命令。我们现在转换到新建的 testing 分支: $ git checkout testing 这样 HEAD 就指向了 testing 分支(见图3-6)。 图 3-6. HEAD 在你转换分支时指向新的分支 这样的实现方式会给我们带来什么好处呢?好吧,现在不妨再提交一次: $ vim test.rb $ git commit -a -m 'made a change' 图 3-7 展示了提交后的结果。 图 3-7. 每次提交后 HEAD 随着分支一起向前移动 非常有趣,现在 testing 分支向前移动了一格,而 master 分支仍然指向原先 git checkout 时所在的 commit 对象。现在我们 回到 master 分支看看: $ git checkout master 图 3-8 显示了结果。 图 3-8. HEAD 在一次 checkout 之后移动到了另一个分支 这条命令做了两件事。它把 HEAD 指针移回到 master 分支,并把工作目录中的文件换成了 master 分支所指向的快照内容。 也就是说,现在开始所做的改动,将始于本项目中一个较老的版本。它的主要作用是将 testing 分支里作出的修改暂时取消, 这样你就可以向另一个方向进行开发。 我们作些修改后再次提交: $ vim test.rb $ git commit -a -m 'made other changes' 现在我们的项目提交历史产生了分叉(如图 3-9 所示),因为刚才我们创建了一个分支,转换到其中进行了一些工作,然后 又回到原来的主分支进行了另外一些工作。这些改变分别孤立在不同的分支里:我们可以在不同分支里反复切换,并在时机 成熟时把它们合并到一起。而所有这些工作,仅仅需要 branch 和 checkout 这两条命令就可以完成。 图 3-9. 不同流向的分支历史 由于 Git 中的分支实际上仅是一个包含所指对象校验和(40 个字符长度 SHA-1 字串)的文件,所以创建和销毁一个分支就变 得非常廉价。说白了,新建一个分支就是向一个文件写入 41 个字节(外加一个换行符)那么简单,当然也就很快了。 这和大多数版本控制系统形成了鲜明对比,它们管理分支大多采取备份所有项目文件到特定目录的方式,所以根据项目文件 数量和大小不同,可能花费的时间也会有相当大的差别,快则几秒,慢则数分钟。而 Git 的实现与项目复杂度无关,它永远 可以在几毫秒的时间内完成分支的创建和切换。同时,因为每次提交时都记录了祖先信息(译注:即 parent 对象),将来 要合并分支时,寻找恰当的合并基础(译注:即共同祖先)的工作其实已经自然而然地摆在那里了,所以实现起来非常容 易。Git 鼓励开发者频繁使用分支,正是因为有着这些特性作保障。 接下来看看,我们为什么应该频繁使用分支。 现在让我们来看一个简单的分支与合并的例子,实际工作中大体也会用到这样的工作流程: 1. 开发某个网站。 2. 为实现某个新的需求,创建一个分支。 3. 在这个分支上开展工作。 假设此时,你突然接到一个电话说有个很严重的问题需要紧急修补,那么可以按照下面的方式处理: 1. 返回到原先已经发布到生产服务器上的分支。 2. 为这次紧急修补建立一个新分支,并在其中修复问题。 3. 通过测试后,回到生产服务器所在的分支,将修补分支合并进来,然后再推送到生产服务器上。 4. 切换到之前实现新需求的分支,继续工作。 首先,我们假设你正在项目中愉快地工作,并且已经提交了几次更新(见图 3-10)。 图 3-10. 一个简短的提交历史 现在,你决定要修补问题追踪系统上的 #53 问题。顺带说明下,Git 并不同任何特定的问题追踪系统打交道。这里为了说明 要解决的问题,才把新建的分支取名为 iss53。要新建并切换到该分支,运行 git checkout 并加上 -b 参数: $ git checkout -b iss53 Switched to a new branch 'iss53' 这相当于执行下面这两条命令: $ git branch iss53 $ git checkout iss53 图 3-11 示意该命令的执行结果。 图 3-11. 创建了一个新分支的指针 接着你开始尝试修复问题,在提交了若干次更新后, iss53 分支的指针也会随着向前推进,因为它就是当前分支(换句话 分支的新建与合并 分支的新建与切换 说,当前的 HEAD 指针正指向 iss53 ,见图 3-12): $ vim index.html $ git commit -a -m 'added a new footer [issue 53]' 图 3-12. iss53 分支随工作进展向前推进 现在你就接到了那个网站问题的紧急电话,需要马上修补。有了 Git ,我们就不需要同时发布这个补丁和 iss53 里作出的修 改,也不需要在创建和发布该补丁到服务器之前花费大力气来复原这些修改。唯一需要的仅仅是切换回 master 分支。 不过在此之前,留心你的暂存区或者工作目录里,那些还没有提交的修改,它会和你即将检出的分支产生冲突从而阻止 Git 为你切换分支。切换分支的时候最好保持一个清洁的工作区域。稍后会介绍几个绕过这种问题的办法(分别叫做 stashing 和 commit amending)。目前已经提交了所有的修改,所以接下来可以正常转换到 master 分支: $ git checkout master Switched to branch 'master' 此时工作目录中的内容和你在解决问题 #53 之前一模一样,你可以集中精力进行紧急修补。这一点值得牢记:Git 会把工作 目录的内容恢复为检出某分支时它所指向的那个提交对象的快照。它会自动添加、删除和修改文件以确保目录的内容和你当 时提交时完全一样。 接下来,你得进行紧急修补。我们创建一个紧急修补分支 hotfix 来开展工作,直到搞定(见图 3-13): $ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'fixed the broken email address' [hotfix 3a0874c] fixed the broken email address 1 files changed, 1 deletion(-) 图 3-13. hotfix 分支是从 master 分支所在点分化出来的 有必要作些测试,确保修补是成功的,然后回到 master 分支并把它合并进来,然后发布到生产服务器。用 git merge 命令 来进行合并: $ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast-forward README | 1 - 1 file changed, 1 deletion(-) 请注意,合并时出现了“Fast forward”的提示。由于当前 master 分支所在的提交对象是要并入的 hotfix 分支的直接上游,Git 只需把 master 分支指针直接右移。换句话说,如果顺着一个分支走下去可以到达另一个分支的话,那么 Git 在合并两者时, 只会简单地把指针右移,因为这种单线的历史分支不存在任何需要解决的分歧,所以这种合并过程可以称为快进(Fast forward)。 现在最新的修改已经在当前 master 分支所指向的提交对象中了,可以部署到生产服务器上去了(见图 3-14)。 图 3-14. 合并之后,master 分支和 hotfix 分支指向同一位置。 在那个超级重要的修补发布以后,你想要回到被打扰之前的工作。由于当前 hotfix 分支和 master 都指向相同的提交对象, 所以 hotfix 已经完成了历史使命,可以删掉了。使用 git branch 的 -d 选项执行删除操作: $ git branch -d hotfix Deleted branch hotfix (was 3a0874c). 现在回到之前未完成的 #53 问题修复分支上继续工作(图 3-15): $ git checkout iss53 Switched to branch 'iss53' $ vim index.html $ git commit -a -m 'finished the new footer [issue 53]' [iss53 ad82d7a] finished the new footer [issue 53] 1 file changed, 1 insertion(+) 图 3-15. iss53 分支可以不受影响继续推进。 值得注意的是之前 hotfix 分支的修改内容尚未包含到 iss53 中来。如果需要纳入此次修补,可以用 git merge master 把 master 分支合并到 iss53 ;或者等 iss53 完成之后,再将 iss53 分支中的更新并入 master 。 在问题 #53 相关的工作完成之后,可以合并回 master 分支。实际操作同前面合并 hotfix 分支差不多,只需回到 master 分 支,运行 git merge 命令指定要合并进来的分支: $ git checkout master $ git merge iss53 Auto-merging README Merge made by the 'recursive' strategy. README | 1 + 1 file changed, 1 insertion(+) 请注意,这次合并操作的底层实现,并不同于之前 hotfix 的并入方式。因为这次你的开发历史是从更早的地方开始分叉的。 由于当前 master 分支所指向的提交对象(C4)并不是 iss53 分支的直接祖先,Git 不得不进行一些额外处理。就此例而 言,Git 会用两个分支的末端(C4 和 C5)以及它们的共同祖先(C2)进行一次简单的三方合并计算。图 3-16 用红框标出了 Git 用于合并的三个提交对象: 分支的合并 图 3-16. Git 为分支合并自动识别出最佳的同源合并点。 这次,Git 没有简单地把分支指针右移,而是对三方合并后的结果重新做一个新的快照,并自动创建一个指向它的提交对象 (C6)(见图 3-17)。这个提交对象比较特殊,它有两个祖先(C4 和 C5)。 值得一提的是 Git 可以自己裁决哪个共同祖先才是最佳合并基础;这和 CVS 或 Subversion(1.5 以后的版本)不同,它们需 要开发者手工指定合并基础。所以此特性让 Git 的合并操作比其他系统都要简单不少。 图 3-17. Git 自动创建了一个包含了合并结果的提交对象。 既然之前的工作成果已经合并到 master 了,那么 iss53 也就没用了。你可以就此删除它,并在问题追踪系统里关闭该问 题。 $ git branch -d iss53 有时候合并操作并不会如此顺利。如果在不同的分支中都修改了同一个文件的同一部分,Git 就无法干净地把两者合到一起 遇到冲突时的分支合并 (译注:逻辑上说,这种问题只能由人来裁决。)。如果你在解决问题 #53 的过程中修改了 hotfix 中修改的部分,将得到类 似下面的结果: $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. Git 作了合并,但没有提交,它会停下来等你解决冲突。要看看哪些文件在合并时发生冲突,可以用 git status 查阅: $ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add ..." to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a") 任何包含未解决冲突的文件都会以未合并(unmerged)的状态列出。Git 会在有冲突的文件里加入标准的冲突解决标记,可 以通过它们来手工定位并解决这些冲突。可以看到此文件包含类似下面这样的部分: <<<<<<< HEAD ======= >>>>>>> iss53 可以看到 ======= 隔开的上半部分,是 HEAD (即 master 分支,在运行 merge 命令时所切换到的分支)中的内容,下 半部分是在 iss53 分支中的内容。解决冲突的办法无非是二者选其一或者由你亲自整合到一起。比如你可以通过把这段内容 替换为下面这样来解决: 这个解决方案各采纳了两个分支中的一部分内容,而且我还删除了 <<<<<<< , ======= 和 >>>>>>> 这些行。在解决 了所有文件里的所有冲突后,运行 git add 将把它们标记为已解决状态(译注:实际上就是来一次快照保存到暂存区域。 )。因为一旦暂存,就表示冲突已经解决。如果你想用一个有图形界面的工具来解决这些问题,不妨运行 git mergetool ,它 会调用一个可视化的合并工具并引导你解决所有冲突: $ git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge Merging: index.html Normal merge conflict for 'index.html': {local}: modified file {remote}: modified file Hit return to start merge resolution tool (opendiff): 如果不想用默认的合并工具(Git 为我默认选择了 opendiff ,因为我在 Mac 上运行了该命令),你可以在上方"merge tool candidates"里找到可用的合并工具列表,输入你想用的工具名。我们将在第七章讨论怎样改变环境中的默认值。 退出合并工具以后,Git 会询问你合并是否成功。如果回答是,它会为你把相关文件暂存起来,以表明状态为已解决。 再运行一次 git status 来确认所有冲突都已解决: $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) modified: index.html 如果觉得满意了,并且确认所有冲突都已解决,也就是进入了暂存区,就可以用 git commit 来完成这次合并提交。提交的记 录差不多是这样: Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # 如果想给将来看这次合并的人一些方便,可以修改该信息,提供更多合并细节。比如你都作了哪些改动,以及这么做的原 因。有时候裁决冲突的理由并不直接或明显,有必要略加注解。 到目前为止,你已经学会了如何创建、合并和删除分支。除此之外,我们还需要学习如何管理分支,在日后的常规工作中会 经常用到下面介绍的管理命令。 git branch 命令不仅仅能创建和删除分支,如果不加任何参数,它会给出当前所有分支的清单: $ git branch iss53 * master testing 注意看 master 分支前的 * 字符:它表示当前所在的分支。也就是说,如果现在提交更新, master 分支将随着开发进度前 移。若要查看各个分支最后一个提交对象的信息,运行 git branch -v : $ git branch -v iss53 93b412c fix javascript issue * master 7a98805 Merge branch 'iss53' testing 782fd34 add scott to the author list in the readmes 要从该清单中筛选出你已经(或尚未)与当前分支合并的分支,可以用 --merged 和 --no-merged 选项(Git 1.5.6 以上版 本)。比如用 git branch --merged 查看哪些分支已被并入当前分支(译注:也就是说哪些分支是当前分支的直接上游。): $ git branch --merged iss53 * master 之前我们已经合并了 iss53 ,所以在这里会看到它。一般来说,列表中没有 * 的分支通常都可以用 git branch -d 来删掉。原 因很简单,既然已经把它们所包含的工作整合到了其他分支,删掉也不会损失什么。 另外可以用 git branch --no-merged 查看尚未合并的工作: $ git branch --no-merged testing 它会显示还未合并进来的分支。由于这些分支中还包含着尚未合并进来的工作成果,所以简单地用 git branch -d 删除该分支 会提示错误,因为那样做会丢失数据: $ git branch -d testing error: The branch 'testing' is not fully merged. If you are sure you want to delete it, run 'git branch -D testing'. 不过,如果你确实想要删除该分支上的改动,可以用大写的删除选项 -D 强制执行,就像上面提示信息中给出的那样。 分支的管理 现在我们已经学会了新建分支和合并分支,可以(或应该)用它来做点什么呢?在本节,我们会介绍一些利用分支进行开发 的工作流程。而正是由于分支管理的便捷,才衍生出了这类典型的工作模式,你可以根据项目的实际情况选择一种用用看。 由于 Git 使用简单的三方合并,所以就算在较长一段时间内,反复多次把某个分支合并到另一分支,也不是什么难事。也就 是说,你可以同时拥有多个开放的分支,每个分支用于完成特定的任务,随着开发的推进,你可以随时把某个特性分支的成 果并到其他分支中。 许多使用 Git 的开发者都喜欢用这种方式来开展工作,比如仅在 master 分支中保留完全稳定的代码,即已经发布或即将发布 的代码。与此同时,他们还有一个名为 develop 或 next 的平行分支,专门用于后续的开发,或仅用于稳定性测试 — 当然并 不是说一定要绝对稳定,不过一旦进入某种稳定状态,便可以把它合并到 master 里。这样,在确保这些已完成的特性分支 (短期分支,比如之前的 iss53 分支)能够通过所有测试,并且不会引入更多错误之后,就可以并到主干分支中,等待下一 次的发布。 本质上我们刚才谈论的,是随着提交对象不断右移的指针。稳定分支的指针总是在提交历史中落后一大截,而前沿分支总是 比较靠前(见图 3-18)。 图 3-18. 稳定分支总是比较老旧。 或者把它们想象成工作流水线,或许更好理解一些,经过测试的提交对象集合被遴选到更稳定的流水线(见图 3-19)。 图 3-19. 想象成流水线可能会容易点。 你可以用这招维护不同层次的稳定性。某些大项目还会有个 proposed (建议)或 pu (proposed updates,建议更新)分 支,它包含着那些可能还没有成熟到进入 next 或 master 的内容。这么做的目的是拥有不同层次的稳定性:当这些分支进入 到更稳定的水平时,再把它们合并到更高层分支中去。再次说明下,使用多个长期分支的做法并非必需,不过一般来说,对 于特大型项目或特复杂的项目,这么做确实更容易管理。 利用分支进行开发的工作流程 长期分支 特性分支 在任何规模的项目中都可以使用特性(Topic)分支。一个特性分支是指一个短期的,用来实现单一特性或与其相关工作的分 支。可能你在以前的版本控制系统里从未做过类似这样的事情,因为通常创建与合并分支消耗太大。然而在 Git 中,一天之 内建立、使用、合并再删除多个分支是常见的事。 我们在上节的例子里已经见过这种用法了。我们创建了 iss53 和 hotfix 这两个特性分支,在提交了若干更新后,把它们合并 到主干分支,然后删除。该技术允许你迅速且完全的进行语境切换 — 因为你的工作分散在不同的流水线里,每个分支里的改 变都和它的目标特性相关,浏览代码之类的事情因而变得更简单了。你可以把作出的改变保持在特性分支中几分钟,几天甚 至几个月,等它们成熟以后再合并,而不用在乎它们建立的顺序或者进度。 现在我们来看一个实际的例子。请看图 3-20,由下往上,起先我们在 master 工作到 C1,然后开始一个新分支 iss91 尝试 修复 91 号缺陷,提交到 C6 的时候,又冒出一个解决该问题的新办法,于是从之前 C4 的地方又分出一个分支 iss91v2 ,干 到 C8 的时候,又回到主干 master 中提交了 C9 和 C10,再回到 iss91v2 继续工作,提交 C11,接着,又冒出个不太确定 的想法,从 master 的最新提交 C10 处开了个新的分支 dumbidea 做些试验。 图 3-20. 拥有多个特性分支的提交历史。 现在,假定两件事情:我们最终决定使用第二个解决方案,即 iss91v2 中的办法;另外,我们把 dumbidea 分支拿给同事们 看了以后,发现它竟然是个天才之作。所以接下来,我们准备抛弃原来的 iss91 分支(实际上会丢弃 C5 和 C6),直接在主 干中并入另外两个分支。最终的提交历史将变成图 3-21 这样: 图 3-21. 合并了 dumbidea 和 iss91v2 后的分支历史。 请务必牢记这些分支全部都是本地分支,这一点很重要。当你在使用分支及合并的时候,一切都是在你自己的 Git 仓库中进 行的 — 完全不涉及与服务器的交互。 远程分支(remote branch)是对远程仓库中的分支的索引。它们是一些无法移动的本地分支;只有在 Git 进行网络交互时才 会更新。远程分支就像是书签,提醒着你上次连接远程仓库时上面各分支的位置。 我们用 (远程仓库名)/(分支名) 这样的形式表示远程分支。比如我们想看看上次同 origin 仓库通讯时 master 分支的样子,就应 该查看 origin/master 分支。如果你和同伴一起修复某个问题,但他们先推送了一个 iss53 分支到远程仓库,虽然你可能也有 一个本地的 iss53 分支,但指向服务器上最新更新的却应该是 origin/iss53 分支。 可能有点乱,我们不妨举例说明。假设你们团队有个地址为 git.ourcompany.com 的 Git 服务器。如果你从这里克隆,Git 会自 动为你将此远程仓库命名为 origin ,并下载其中所有的数据,建立一个指向它的 master 分支的指针,在本地命名为 origin/master ,但你无法在本地更改其数据。接着,Git 建立一个属于你自己的本地 master 分支,始于 origin 上 master 分 支相同的位置,你可以就此开始工作(见图 3-22): 图 3-22. 一次 Git 克隆会建立你自己的本地分支 master 和远程分支 origin/master,并且将它们都指向 origin 上的 master 分 支。 如果你在本地 master 分支做了些改动,与此同时,其他人向 git.ourcompany.com 推送了他们的更新,那么服务器上的 master 分支就会向前推进,而于此同时,你在本地的提交历史正朝向不同方向发展。不过只要你不和服务器通讯,你的 origin/master 指针仍然保持原位不会移动(见图 3-23)。 远程分支 图 3-23. 在本地工作的同时有人向远程仓库推送内容会让提交历史开始分流。 可以运行 git fetch origin 来同步远程服务器上的数据到本地。该命令首先找到 origin 是哪个服务器(本例为 git.ourcompany.com ),从上面获取你尚未拥有的数据,更新你本地的数据库,然后把 origin/master 的指针移到它最新的位 置上(见图 3-24)。 图 3-24. git fetch 命令会更新 remote 索引。 为了演示拥有多个远程分支(在不同的远程服务器上)的项目是如何工作的,我们假设你还有另一个仅供你的敏捷开发小组 使用的内部服务器 git.team1.ourcompany.com 。可以用第二章中提到的 git remote add 命令把它加为当前项目的远程分支之 一。我们把它命名为 teamone ,以便代替完整的 Git URL 以方便使用(见图 3-25)。 图 3-25. 把另一个服务器加为远程仓库 现在你可以用 git fetch teamone 来获取小组服务器上你还没有的数据了。由于当前该服务器上的内容是你 origin 服务器上的 子集,Git 不会下载任何数据,而只是简单地创建一个名为 teamone/master 的远程分支,指向 teamone 服务器上 master 分 支所在的提交对象 31b8e (见图 3-26)。 图 3-26. 你在本地有了一个指向 teamone 服务器上 master 分支的索引。 要想和其他人分享某个本地分支,你需要把它推送到一个你拥有写权限的远程仓库。你创建的本地分支不会因为你的写入操 作而被自动同步到你引入的远程服务器上,你需要明确地执行推送分支的操作。换句话说,对于无意分享的分支,你尽管保 留为私人分支好了,而只推送那些协同工作要用到的特性分支。 如果你有个叫 serverfix 的分支需要和他人一起开发,可以运行 git push (远程仓库名) (分支名) : $ git push origin serverfix Counting objects: 20, done. Compressing objects: 100% (14/14), done. Writing objects: 100% (15/15), 1.74 KiB, done. Total 15 (delta 5), reused 0 (delta 0) To git@github.com:schacon/simplegit.git * [new branch] serverfix -> serverfix 这里其实走了一点捷径。Git 自动把 serverfix 分支名扩展为 refs/heads/serverfix:refs/heads/serverfix ,意为“取出我在本地的 serverfix 分支,推送到远程仓库的 serverfix 分支中去”。我们将在第九章进一步介绍 refs/heads/ 部分的细节,不过一般使用 的时候都可以省略它。也可以运行 git push origin serverfix:serverfix 来实现相同的效果,它的意思是“上传我本地的 serverfix 分支到远程仓库中去,仍旧称它为 serverfix 分支”。通过此语法,你可以把本地分支推送到某个命名不同的远程分支:若想 把远程分支叫作 awesomebranch ,可以用 git push origin serverfix:awesomebranch 来推送数据。 接下来,当你的协作者再次从服务器上获取数据时,他们将得到一个新的远程分支 origin/serverfix ,并指向服务器上 serverfix 所指向的版本: $ git fetch origin remote: Counting objects: 20, done. remote: Compressing objects: 100% (14/14), done. remote: Total 15 (delta 5), reused 0 (delta 0) Unpacking objects: 100% (15/15), done. From git@github.com:schacon/simplegit * [new branch] serverfix -> origin/serverfix 值得注意的是,在 fetch 操作下载好新的远程分支之后,你仍然无法在本地编辑该远程仓库中的分支。换句话说,在本例 中,你不会有一个新的 serverfix 分支,有的只是一个你无法移动的 origin/serverfix 指针。 如果要把该远程分支的内容合并到当前分支,可以运行 git merge origin/serverfix 。如果想要一份自己的 serverfix 来开发,可 以在远程分支的基础上分化出一个新的分支来: $ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' 这会切换到新建的 serverfix 本地分支,其内容同远程分支 origin/serverfix 一致,这样你就可以在里面继续开发了。 从远程分支 checkout 出来的本地分支,称为 跟踪分支 (tracking branch)。跟踪分支是一种和某个远程分支有直接联系的本 地分支。在跟踪分支里输入 git push ,Git 会自行推断应该向哪个服务器的哪个分支推送数据。同样,在这些分支里运行 git pull 会获取所有远程索引,并把它们的数据都合并到本地分支中来。 在克隆仓库时,Git 通常会自动创建一个名为 master 的分支来跟踪 origin/master 。这正是 git push 和 git pull 一开始就能正 常工作的原因。当然,你可以随心所欲地设定为其它跟踪分支,比如 origin 上除了 master 之外的其它分支。刚才我们已经 看到了这样的一个例子: git checkout -b [分支名] [远程名]/[分支名] 。如果你有 1.6.2 以上版本的 Git,还可以用 --track 选项简 化: 推送本地分支 跟踪远程分支 $ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix' 要为本地分支设定不同于远程分支的名字,只需在第一个版本的命令里换个名字: $ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf' 现在你的本地分支 sf 会自动将推送和抓取数据的位置定位到 origin/serverfix 了。 如果不再需要某个远程分支了,比如搞定了某个特性并把它合并进了远程的 master 分支(或任何其他存放稳定代码的分 支),可以用这个非常无厘头的语法来删除它: git push [远程名] :[分支名] 。如果想在服务器上删除 serverfix 分支,运行下面 的命令: $ git push origin :serverfix To git@github.com:schacon/simplegit.git - [deleted] serverfix 咚!服务器上的分支没了。你最好特别留心这一页,因为你一定会用到那个命令,而且你很可能会忘掉它的语法。有种方便 记忆这条命令的方法:记住我们不久前见过的 git push [远程名] [本地分支]:[远程分支] 语法,如果省略 [本地分支] ,那就等于是在 说“在这里提取空白然后把它变成 [远程分支] ”。 删除远程分支 把一个分支中的修改整合到另一个分支的办法有两种: merge 和 rebase (译注: rebase 的翻译暂定为“衍合”,大家知道就 可以了。)。在本章我们会学习什么是衍合,如何使用衍合,为什么衍合操作如此富有魅力,以及我们应该在什么情况下使 用衍合。 请回顾之前有关合并的一节(见图 3-27),你会看到开发进程分叉到两个不同分支,又各自提交了更新。 图 3-27. 最初分叉的提交历史。 之前介绍过,最容易的整合分支的方法是 merge 命令,它会把两个分支最新的快照(C3 和 C4)以及二者最新的共同祖先 (C2)进行三方合并,合并的结果是产生一个新的提交对象(C5)。如图 3-28 所示: 图 3-28. 通过合并一个分支来整合分叉了的历史。 其实,还有另外一个选择:你可以把在 C3 里产生的变化补丁在 C4 的基础上重新打一遍。在 Git 里,这种操作叫做衍合 (rebase)。有了 rebase 命令,就可以把在一个分支里提交的改变移到另一个分支里重放一遍。 在上面这个例子中,运行: $ git checkout experiment $ git rebase master First, rewinding head to replay your work on top of it... Applying: added staged command 它的原理是回到两个分支最近的共同祖先,根据当前分支(也就是要进行衍合的分支 experiment )后续的历次提交对象(这 分支的衍合 基本的衍合操作 里只有一个 C3),生成一系列文件补丁,然后以基底分支(也就是主干分支 master )最后一个提交对象(C4)为新的出发 点,逐个应用之前准备好的补丁文件,最后会生成一个新的合并提交对象(C3'),从而改写 experiment 的提交历史,使它 成为 master 分支的直接下游,如图 3-29 所示: 图 3-29. 把 C3 里产生的改变到 C4 上重演一遍。 现在回到 master 分支,进行一次快进合并(见图 3-30): 图 3-30. master 分支的快进。 现在的 C3' 对应的快照,其实和普通的三方合并,即上个例子中的 C5 对应的快照内容一模一样了。虽然最后整合得到的结 果没有任何区别,但衍合能产生一个更为整洁的提交历史。如果视察一个衍合过的分支的历史记录,看起来会更清楚:仿佛 所有修改都是在一根线上先后进行的,尽管实际上它们原本是同时并行发生的。 一般我们使用衍合的目的,是想要得到一个能在远程分支上干净应用的补丁 — 比如某些项目你不是维护者,但想帮点忙的 话,最好用衍合:先在自己的一个分支里进行开发,当准备向主项目提交补丁的时候,根据最新的 origin/master 进行一次衍 合操作然后再提交,这样维护者就不需要做任何整合工作(译注:实际上是把解决分支补丁同最新主干代码之间冲突的责 任,化转为由提交补丁的人来解决。),只需根据你提供的仓库地址作一次快进合并,或者直接采纳你提交的补丁。 请注意,合并结果中最后一次提交所指向的快照,无论是通过衍合,还是三方合并,都会得到相同的快照内容,只不过提交 历史不同罢了。衍合是按照每行的修改次序重演一遍修改,而合并是把最终结果合在一起。 衍合也可以放到其他分支进行,并不一定非得根据分化之前的分支。以图 3-31 的历史为例,我们为了给服务器端代码添加一 些功能而创建了特性分支 server ,然后提交 C3 和 C4。然后又从 C3 的地方再增加一个 client 分支来对客户端代码进行一 些相应修改,所以提交了 C8 和 C9。最后,又回到 server 分支提交了 C10。 有趣的衍合 图 3-31. 从一个特性分支里再分出一个特性分支的历史。 假设在接下来的一次软件发布中,我们决定先把客户端的修改并到主线中,而暂缓并入服务端软件的修改(因为还需要进一 步测试)。这个时候,我们就可以把基于 server 分支而非 master 分支的改变(即 C8 和 C9),跳过 server 直接放到 master 分支中重演一遍,但这需要用 git rebase 的 --onto 选项指定新的基底分支 master : $ git rebase --onto master server client 这好比在说:“取出 client 分支,找出 client 分支和 server 分支的共同祖先之后的变化,然后把它们在 master 上重演一 遍”。是不是有点复杂?不过它的结果如图 3-32 所示,非常酷(译注:虽然 client 里的 C8, C9 在 C3 之后,但这仅表明时 间上的先后,而非在 C3 修改的基础上进一步改动,因为 server 和 client 这两个分支对应的代码应该是两套文件,虽然这么 说不是很严格,但应理解为在 C3 时间点之后,对另外的文件所做的 C8,C9 修改,放到主干重演。): 图 3-32. 将特性分支上的另一个特性分支衍合到其他分支。 现在可以快进 master 分支了(见图 3-33): $ git checkout master $ git merge client 图 3-33. 快进 master 分支,使之包含 client 分支的变化。 现在我们决定把 server 分支的变化也包含进来。我们可以直接把 server 分支衍合到 master ,而不用手工切换到 server 分 支后再执行衍合操作 — git rebase [主分支] [特性分支] 命令会先取出特性分支 server ,然后在主分支 master 上重演: $ git rebase master server 于是, server 的进度应用到 master 的基础上,如图 3-34 所示: 图 3-34. 在 master 分支上衍合 server 分支。 然后就可以快进主干分支 master 了: $ git checkout master $ git merge server 现在 client 和 server 分支的变化都已经集成到主干分支来了,可以删掉它们了。最终我们的提交历史会变成图 3-35 的样 子: $ git branch -d client $ git branch -d server 图 3-35. 最终的提交历史 呃,奇妙的衍合也并非完美无缺,要用它得遵守一条准则: 一旦分支中的提交对象发布到公共仓库,就千万不要对该分支进行衍合操作。 如果你遵循这条金科玉律,就不会出差错。否则,人民群众会仇恨你,你的朋友和家人也会嘲笑你,唾弃你。 在进行衍合的时候,实际上抛弃了一些现存的提交对象而创造了一些类似但不同的新的提交对象。如果你把原来分支中的提 交对象发布出去,并且其他人更新下载后在其基础上开展工作,而稍后你又用 git rebase 抛弃这些提交对象,把新的重演后 的提交对象发布出去的话,你的合作者就不得不重新合并他们的工作,这样当你再次从他们那里获取内容时,提交历史就会 变得一团糟。 下面我们用一个实际例子来说明为什么公开的衍合会带来问题。假设你从一个中央服务器克隆然后在它的基础上搞了一些开 发,提交历史类似图 3-36 所示: 图 3-36. 克隆一个仓库,在其基础上工作一番。 现在,某人在 C1 的基础上做了些改变,并合并他自己的分支得到结果 C6,推送到中央服务器。当你抓取并合并这些数据到 你本地的开发分支中后,会得到合并结果 C7,历史提交会变成图 3-37 这样: 衍合的风险 图 3-37. 抓取他人提交,并入自己主干。 接下来,那个推送 C6 上来的人决定用衍合取代之前的合并操作;继而又用 git push --force 覆盖了服务器上的历史,得到 C4'。而之后当你再从服务器上下载最新提交后,会得到: 图 3-38. 有人推送了衍合后得到的 C4',丢弃了你作为开发基础的 C4 和 C6。 下载更新后需要合并,但此时衍合产生的提交对象 C4' 的 SHA-1 校验值和之前 C4 完全不同,所以 Git 会把它们当作新的提 交对象处理,而实际上此刻你的提交历史 C7 中早已经包含了 C4 的修改内容,于是合并操作会把 C7 和 C4' 合并为 C8(见 图 3-39): 图 3-39. 你把相同的内容又合并了一遍,生成一个新的提交 C8。 C8 这一步的合并是迟早会发生的,因为只有这样你才能和其他协作者提交的内容保持同步。而在 C8 之后,你的提交历史里 就会同时包含 C4 和 C4',两者有着不同的 SHA-1 校验值,如果用 git log 查看历史,会看到两个提交拥有相同的作者日期 与说明,令人费解。而更糟的是,当你把这样的历史推送到服务器后,会再次把这些衍合后的提交引入到中央服务器,进一 步困扰其他人(译注:这个例子中,出问题的责任方是那个发布了 C6 后又用衍合发布 C4' 的人,其他人会因此反馈双重历 史到共享主干,从而混淆大家的视听。)。 如果把衍合当成一种在推送之前清理提交历史的手段,而且仅仅衍合那些尚未公开的提交对象,就没问题。如果衍合那些已 经公开的提交对象,并且已经有人基于这些提交对象开展了后续开发工作的话,就会出现叫人沮丧的麻烦。 读到这里,你应该已经学会了如何创建分支并切换到新分支,在不同分支间转换,合并本地分支,把分支推送到共享服务器 上,使用共享分支与他人协作,以及在分享之前进行衍合。 小结 到目前为止,你应该已经学会了使用 Git 来完成日常工作。然而,如果想与他人合作,还需要一个远程的 Git 仓库。尽管技术 上可以从个人的仓库里推送和拉取修改内容,但我们不鼓励这样做,因为一不留心就很容易弄混其他人的进度。另外,你也 一定希望合作者们即使在自己不开机的时候也能从仓库获取数据 — 拥有一个更稳定的公共仓库十分有用。因此,更好的合作 方式是建立一个大家都可以访问的共享仓库,从那里推送和拉取数据。我们将把这个仓库称为 "Git 服务器";代理一个 Git 仓 库只需要花费很少的资源,几乎从不需要整个服务器来支持它的运行。 架设一台 Git 服务器并不难。第一步是选择与服务器通讯的协议。本章第一节将介绍可用的协议以及各自优缺点。下面一节 将介绍一些针对各个协议典型的设置以及如何在服务器上实施。最后,如果你不介意在他人服务器上保存你的代码,又想免 去自己架设和维护服务器的麻烦,倒可以试试我们介绍的几个仓库托管服务。 如果你对架设自己的服务器没兴趣,可以跳到本章最后一节去看看如何申请一个代码托管服务的账户然后继续下一章,我们 会在那里讨论分布式源码控制环境的林林总总。 远程仓库通常只是一个裸仓库(bare repository) — 即一个没有当前工作目录的仓库。因为该仓库只是一个合作媒介,所以 不需要从硬盘上取出最新版本的快照;仓库里存放的仅仅是 Git 的数据。简单地说,裸仓库就是你工作目录中 .git 子目录内 的内容。 服务器上的 Git Git 可以使用四种主要的协议来传输数据:本地传输,SSH 协议,Git 协议和 HTTP 协议。下面分别介绍一下哪些情形应该使 用(或避免使用)这些协议。 值得注意的是,除了 HTTP 协议外,其他所有协议都要求在服务器端安装并运行 Git。 最基本的就是本地协议(Local protocol),所谓的远程仓库在该协议中的表示,就是硬盘上的另一个目录。这常见于团队每 一个成员都对一个共享的文件系统(例如 NFS)拥有访问权,或者比较少见的多人共用同一台电脑的情况。后面一种情况并 不安全,因为所有代码仓库实例都储存在同一台电脑里,增加了灾难性数据损失的可能性。 如果你使用一个共享的文件系统,就可以在一个本地文件系统中克隆仓库,推送和获取。克隆的时候只需要将远程仓库的路 径作为 URL 使用,比如下面这样: $ git clone /opt/git/project.git 或者这样: $ git clone file:///opt/git/project.git 如果在 URL 开头明确使用 file:// ,那么 Git 会以一种略微不同的方式运行。如果你只给出路径,Git 会尝试使用硬链接或直 接复制它所需要的文件。如果使用了 file:// ,Git 会调用它平时通过网络来传输数据的工序,而这种方式的效率相对较低。使 用 file:// 前缀的主要原因是当你需要一个不包含无关引用或对象的干净仓库副本的时候 — 一般指从其他版本控制系统导入 的,或类似情形(参见第 9 章的维护任务)。我们这里仅仅使用普通路径,这样更快。 要添加一个本地仓库作为现有 Git 项目的远程仓库,可以这样做: $ git remote add local_proj /opt/git/project.git 然后就可以像在网络上一样向这个远程仓库推送和获取数据了。 基于文件仓库的优点在于它的简单,同时保留了现存文件的权限和网络访问权限。如果你的团队已经有一个全体共享的文件 系统,建立仓库就十分容易了。你只需把一份裸仓库的副本放在大家都能访问的地方,然后像对其他共享目录一样设置读写 权限就可以了。我们将在下一节“在服务器上部署 Git ”中讨论如何导出一个裸仓库的副本。 这也是从别人工作目录中获取工作成果的快捷方法。假如你和你的同事在一个项目中合作,他们想让你检出一些东西的时 候,运行类似 git pull /home/john/project 通常会比他们推送到服务器,而你再从服务器获取简单得多。 这种方法的缺点是,与基本的网络连接访问相比,难以控制从不同位置来的访问权限。如果你想从家里的笔记本电脑上推 送,就要先挂载远程硬盘,这和基于网络连接的访问相比更加困难和缓慢。 另一个很重要的问题是该方法不一定就是最快的,尤其是对于共享挂载的文件系统。本地仓库只有在你对数据访问速度快的 时候才快。在同一个服务器上,如果二者同时允许 Git 访问本地硬盘,通过 NFS 访问仓库通常会比 SSH 慢。 协议 本地协议 优点 缺点 SSH 协议 Git 使用的传输协议中最常见的可能就是 SSH 了。这是因为大多数环境已经支持通过 SSH 对服务器的访问 — 即便还没有, 架设起来也很容易。SSH 也是唯一一个同时支持读写操作的网络协议。另外两个网络协议(HTTP 和 Git)通常都是只读 的,所以虽然二者对大多数人都可用,但执行写操作时还是需要 SSH。SSH 同时也是一个验证授权的网络协议;而因为其 普遍性,一般架设和使用都很容易。 通过 SSH 克隆一个 Git 仓库,你可以像下面这样给出 ssh:// 的 URL: $ git clone ssh://user@server/project.git 或者不指明某个协议 — 这时 Git 会默认使用 SSH : $ git clone user@server:project.git 如果不指明用户,Git 会默认使用当前登录的用户名连接服务器。 使用 SSH 的好处有很多。首先,如果你想拥有对网络仓库的写权限,基本上不可能不使用 SSH。其次,SSH 架设相对比较 简单 — SSH 守护进程很常见,很多网络管理员都有一些使用经验,而且很多操作系统都自带了它或者相关的管理工具。再 次,通过 SSH 进行访问是安全的 — 所有数据传输都是加密和授权的。最后,和 Git 及本地协议一样,SSH 也很高效,会在 传输之前尽可能压缩数据。 SSH 的限制在于你不能通过它实现仓库的匿名访问。即使仅为读取数据,人们也必须在能通过 SSH 访问主机的前提下才能 访问仓库,这使得 SSH 不利于开源的项目。如果你仅仅在公司网络里使用,SSH 可能是你唯一需要使用的协议。如果想允 许对项目的匿名只读访问,那么除了为自己推送而架设 SSH 协议之外,还需要支持其他协议以便他人访问读取。 接下来是 Git 协议。这是一个包含在 Git 软件包中的特殊守护进程; 它会监听一个提供类似于 SSH 服务的特定端口 (9418),而无需任何授权。打算支持 Git 协议的仓库,需要先创建 git-daemon-export-ok 文件 — 它是协议进程提供仓库服 务的必要条件 — 但除此之外该服务没有什么安全措施。要么所有人都能克隆 Git 仓库,要么谁也不能。这也意味着该协议通 常不能用来进行推送。你可以允许推送操作;然而由于没有授权机制,一旦允许该操作,网络上任何一个知道项目 URL 的人 将都有推送权限。不用说,这是十分罕见的情况。 Git 协议是现存最快的传输协议。如果你在提供一个有很大访问量的公共项目,或者一个不需要对读操作进行授权的庞大项 目,架设一个 Git 守护进程来供应仓库是个不错的选择。它使用与 SSH 协议相同的数据传输机制,但省去了加密和授权的开 销。 Git 协议消极的一面是缺少授权机制。用 Git 协议作为访问项目的唯一方法通常是不可取的。一般的做法是,同时提供 SSH 接口,让几个开发者拥有推送(写)权限,其他人通过 git:// 拥有只读权限。 Git 协议可能也是最难架设的协议。它要求有单 独的守护进程,需要定制 — 我们将在本章的 “Gitosis” 一节详细介绍它的架设 — 需要设定 xinetd 或类似的程序,而这些工 作就没那么轻松了。该协议还要求防火墙开放 9418 端口,而企业级防火墙一般不允许对这个非标准端口的访问。大型企业 级防火墙通常会封锁这个少见的端口。 最后还有 HTTP 协议。HTTP 或 HTTPS 协议的优美之处在于架设的简便性。基本上,只需要把 Git 的裸仓库文件放在 HTTP 优点 缺点 Git 协议 优点 缺点 HTTP/S 协议 的根目录下,配置一个特定的 post-update 挂钩(hook)就可以搞定(Git 挂钩的细节见第 7 章)。此后,每个能访问 Git 仓 库所在服务器上 web 服务的人都可以进行克隆操作。下面的操作可以允许通过 HTTP 对仓库进行读取: $ cd /var/www/htdocs/ $ git clone --bare /path/to/git_project gitproject.git $ cd gitproject.git $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update 这样就可以了。Git 附带的 post-update 挂钩会默认运行合适的命令( git update-server-info )来确保通过 HTTP 的获取和克隆 正常工作。这条命令在你用 SSH 向仓库推送内容时运行;之后,其他人就可以用下面的命令来克隆仓库: $ git clone http://example.com/gitproject.git 在本例中,我们使用了 Apache 设定中常用的 /var/www/htdocs 路径,不过你可以使用任何静态 web 服务 — 把裸仓库放在它 的目录里就行。 Git 的数据是以最基本的静态文件的形式提供的(关于如何提供文件的详情见第 9 章)。 通过 HTTP 进行推送操作也是可能的,不过这种做法不太常见,并且牵扯到复杂的 WebDAV 设定。由于很少用到,本书将 略过对该内容的讨论。如果对 HTTP 推送协议感兴趣,不妨打开这个地址看一下操作方 法: http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt 。通过 HTTP 推送的好处之一是你可以使 用任何 WebDAV 服务器,不需要为 Git 设定特殊环境;所以如果主机提供商支持通过 WebDAV 更新网站内容,你也可以使 用这项功能。 使用 HTTP 协议的好处是易于架设。几条必要的命令就可以让全世界读取到仓库的内容。花费不过几分钟。HTTP 协议不会 占用过多服务器资源。因为它一般只用到静态的 HTTP 服务提供所有数据,普通的 Apache 服务器平均每秒能支撑数千个文 件的并发访问 — 哪怕让一个小型服务器超载都很难。 你也可以通过 HTTPS 提供只读的仓库,这意味着你可以加密传输内容;你甚至可以要求客户端使用特定签名的 SSL 证书。 一般情况下,如果到了这一步,使用 SSH 公共密钥可能是更简单的方案;不过也存在一些特殊情况,这时通过 HTTPS 使用 带签名的 SSL 证书或者其他基于 HTTP 的只读连接授权方式是更好的解决方案。 HTTP 还有个额外的好处:HTTP 是一个如此常见的协议,以至于企业级防火墙通常都允许其端口的通信。 HTTP 协议的消极面在于,相对来说客户端效率更低。克隆或者下载仓库内容可能会花费更多时间,而且 HTTP 传输的体积 和网络开销比其他任何一个协议都大。因为它没有按需供应的能力 — 传输过程中没有服务端的动态计算 — 因而 HTTP 协议 经常会被称为傻瓜(dumb)协议。更多 HTTP 协议和其他协议效率上的差异见第 9 章。 优点 缺点 开始架设 Git 服务器前,需要先把现有仓库导出为裸仓库 — 即一个不包含当前工作目录的仓库。做法直截了当,克隆时用 -- bare 选项即可。裸仓库的目录名一般以 .git 结尾,像这样: $ git clone --bare my_project my_project.git Cloning into bare repository 'my_project.git'... done. 该命令的输出或许会让人有些不解。其实 clone 操作基本上相当于 git init 加 git fetch ,所以这里出现的其实是 git init 的输 出,先由它建立一个空目录,而之后传输数据对象的操作并无任何输出,只是悄悄在幕后执行。现在 my_project.git 目录中 已经有了一份 Git 目录数据的副本。 整体上的效果大致相当于: $ cp -Rf my_project/.git my_project.git 但在配置文件中有若干小改动,不过对用户来讲,使用方式都一样,不会有什么影响。它仅取出 Git 仓库的必要原始数据, 存放在该目录中,而不会另外创建工作目录。 有了裸仓库的副本后,剩下的就是把它放到服务器上并设定相关协议。假设一个域名为 git.example.com 的服务器已经架设 好,并可以通过 SSH 访问,我们打算把所有 Git 仓库储存在 /opt/git 目录下。只要把裸仓库复制过去: $ scp -r my_project.git user@git.example.com:/opt/git 现在,所有对该服务器有 SSH 访问权限,并可读取 /opt/git 目录的用户都可以用下面的命令克隆该项目: $ git clone user@git.example.com:/opt/git/my_project.git 如果某个 SSH 用户对 /opt/git/my_project.git 目录有写权限,那他就有推送权限。如果到该项目目录中运行 git init 命令,并 加上 --shared 选项,那么 Git 会自动修改该仓库目录的组权限为可写(译注:实际上 --shared 可以指定其他行为,只是默认 为将组权限改为可写并执行 g+sx ,所以最后会得到 rws 。)。 $ ssh user@git.example.com $ cd /opt/git/my_project.git $ git init --bare --shared 由此可见,根据现有的 Git 仓库创建一个裸仓库,然后把它放上你和同事都有 SSH 访问权的服务器是多么容易。现在已经可 以开始在同一项目上密切合作了。 值得注意的是,这的的确确是架设一个少数人具有连接权的 Git 服务的全部 — 只要在服务器上加入可以用 SSH 登录的帐 号,然后把裸仓库放在大家都有读写权限的地方。一切都准备停当,无需更多。 下面的几节中,你会了解如何扩展到更复杂的设定。这些内容包含如何避免为每一个用户建立一个账户,给仓库添加公共读 取权限,架设网页界面,使用 Gitosis 工具等等。然而,只是和几个人在一个不公开的项目上合作的话,仅仅是一个 SSH 服 务器和裸仓库就足够了,记住这点就可以了。 在服务器上部署 Git 把裸仓库移到服务器上 小型安装 如果设备较少或者你只想在小型开发团队里尝试 Git ,那么一切都很简单。架设 Git 服务最复杂的地方在于账户管理。如果需 要仓库对特定的用户可读,而给另一部分用户读写权限,那么访问和许可的安排就比较困难。 如果已经有了一个所有开发成员都可以用 SSH 访问的服务器,架设第一个服务器将变得异常简单,几乎什么都不用做(正如 上节中介绍的那样)。如果需要对仓库进行更复杂的访问控制,只要使用服务器操作系统的本地文件访问许可机制就行了。 如果需要团队里的每个人都对仓库有写权限,又不能给每个人在服务器上建立账户,那么提供 SSH 连接就是唯一的选择了。 我们假设用来共享仓库的服务器已经安装了 SSH 服务,而且你通过它访问服务器。 有好几个办法可以让团队的每个人都有访问权。第一个办法是给每个人建立一个账户,直截了当但略过繁琐。反复运行 adduser 并给所有人设定临时密码可不是好玩的。 第二个办法是在主机上建立一个 git 账户,让每个需要写权限的人发送一个 SSH 公钥,然后将其加入 git 账户的 ~/.ssh/authorized_keys 文件。这样一来,所有人都将通过 git 账户访问主机。这丝毫不会影响提交的数据 — 访问主机用的身 份不会影响提交对象的提交者信息。 另一个办法是让 SSH 服务器通过某个 LDAP 服务,或者其他已经设定好的集中授权机制,来进行授权。只要每个人都能获 得主机的 shell 访问权,任何可用的 SSH 授权机制都能达到相同效果。 SSH 连接 大多数 Git 服务器都会选择使用 SSH 公钥来进行授权。系统中的每个用户都必须提供一个公钥用于授权,没有的话就要生成 一个。生成公钥的过程在所有操作系统上都差不多。 首先先确认一下是否已经有一个公钥了。SSH 公钥默认储存在账户的主 目录下的 ~/.ssh 目录。进去看看: $ cd ~/.ssh $ ls authorized_keys2 id_dsa known_hosts config id_dsa.pub 关键是看有没有用 something 和 something.pub 来命名的一对文件,这个 something 通常就是 id_dsa 或 id_rsa 。有 .pub 后缀的文件就是公钥,另一个文件则是密钥。假如没有这些文件,或者干脆连 .ssh 目录都没有,可以用 ssh-keygen 来创 建。该程序在 Linux/Mac 系统上由 SSH 包提供,而在 Windows 上则包含在 MSysGit 包里: $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/schacon/.ssh/id_rsa. Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub. The key fingerprint is: 43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a schacon@agadorlaptop.local 它先要求你确认保存公钥的位置( .ssh/id_rsa ),然后它会让你重复一个密码两次,如果不想在使用公钥的时候输入密码, 可以留空。 现在,所有做过这一步的用户都得把它们的公钥给你或者 Git 服务器的管理员(假设 SSH 服务被设定为使用公钥机制)。他 们只需要复制 .pub 文件的内容然后发邮件给管理员。公钥的样子大致如下: $ cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3 Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx NrRFi9wrf+M7Q== schacon@agadorlaptop.local 关于在多个操作系统上设立相同 SSH 公钥的教程,可以查阅 GitHub 上有关 SSH 公钥的向 导: http://github.com/guides/providing-your-ssh-key 。 生成 SSH 公钥 现在我们过一边服务器端架设 SSH 访问的流程。本例将使用 authorized_keys 方法来给用户授权。我们还将假定使用类似 Ubuntu 这样的标准 Linux 发行版。首先,创建一个名为 'git' 的用户,并为其创建一个 .ssh 目录。 $ sudo adduser git $ su git $ cd $ mkdir .ssh 接下来,把开发者的 SSH 公钥添加到这个用户的 authorized_keys 文件中。假设你通过电邮收到了几个公钥并存到了临时文 件里。重复一下,公钥大致看起来是这个样子: $ cat /tmp/id_rsa.john.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq dAv8JggJICUvax2T9va5 gsg-keypair 只要把它们逐个追加到 authorized_keys 文件尾部即可: $ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys $ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys 现在可以用 --bare 选项运行 git init 来建立一个裸仓库,这会初始化一个不包含工作目录的仓库。 $ cd /opt/git $ mkdir project.git $ cd project.git $ git --bare init 这时,Join,Josie 或者 Jessica 就可以把它加为远程仓库,推送一个分支,从而把第一个版本的项目文件上传到仓库里了。 值得注意的是,每次添加一个新项目都需要通过 shell 登入主机并创建一个裸仓库目录。我们不妨以 gitserver 作为 git 用户 及项目仓库所在的主机名。如果在网络内部运行该主机,并在 DNS 中设定 gitserver 指向该主机,那么以下这些命令都是可 用的: # 在 John 的电脑上 $ cd myproject $ git init $ git add . $ git commit -m 'initial commit' $ git remote add origin git@gitserver:/opt/git/project.git $ git push origin master 这样,其他人的克隆和推送也一样变得很简单: $ git clone git@gitserver:/opt/git/project.git $ cd project $ vim README $ git commit -am 'fix for the README file' $ git push origin master 用这个方法可以很快捷地为少数几个开发者架设一个可读写的 Git 服务。 架设服务器 作为一个额外的防范措施,你可以用 Git 自带的 git-shell 工具限制 git 用户的活动范围。只要把它设为 git 用户登入的 shell,那么该用户就无法使用普通的 bash 或者 csh 什么的 shell 程序。编辑 /etc/passwd 文件: $ sudo vim /etc/passwd 在文件末尾,你应该能找到类似这样的行: git:x:1000:1000::/home/git:/bin/sh 把 bin/sh 改为 /usr/bin/git-shell (或者用 which git-shell 查看它的实际安装路径)。该行修改后的样子如下: git:x:1000:1000::/home/git:/usr/bin/git-shell 现在 git 用户只能用 SSH 连接来推送和获取 Git 仓库,而不能直接使用主机 shell。尝试普通 SSH 登录的话,会看到下面这 样的拒绝信息: $ ssh git@gitserver fatal: What do you think I am? A shell? Connection to gitserver closed. 匿名的读取权限该怎么实现呢?也许除了内部私有的项目之外,你还需要托管一些开源项目。或者因为要用一些自动化的服 务器来进行编译,或者有一些经常变化的服务器群组,而又不想整天生成新的 SSH 密钥 — 总之,你需要简单的匿名读取权 限。 或许对小型的配置来说最简单的办法就是运行一个静态 web 服务,把它的根目录设定为 Git 仓库所在的位置,然后开启本章 第一节提到的 post-update 挂钩。这里继续使用之前的例子。假设仓库处于 /opt/git 目录,主机上运行着 Apache 服务。重 申一下,任何 web 服务程序都可以达到相同效果;作为范例,我们将用一些基本的 Apache 设定来展示大体需要的步骤。 首先,开启挂钩: $ cd project.git $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update post-update 挂钩是做什么的呢?其内容大致如下: $ cat .git/hooks/post-update #!/bin/sh # # An example hook script to prepare a packed repository for use over # dumb transports. # # To enable this hook, rename this file to "post-update". # exec git-update-server-info 意思是当通过 SSH 向服务器推送时,Git 将运行这个 git-update-server-info 命令来更新匿名 HTTP 访问获取数据时所需要的 文件。 接下来,在 Apache 配置文件中添加一个 VirtualHost 条目,把文档根目录设为 Git 项目所在的根目录。这里我们假定 DNS 服务已经配置好,会把对 .gitserver 的请求发送到这台主机: ServerName git.gitserver DocumentRoot /opt/git Order allow, deny allow from all 另外,需要把 /opt/git 目录的 Unix 用户组设定为 www-data ,这样 web 服务才可以读取仓库内容,因为运行 CGI 脚本的 Apache 实例进程默认就是以该用户的身份起来的: $ chgrp -R www-data /opt/git 重启 Apache 之后,就可以通过项目的 URL 来克隆该目录下的仓库了。 $ git clone http://git.gitserver/project.git 这一招可以让你在几分钟内为相当数量的用户架设好基于 HTTP 的读取权限。另一个提供非授权访问的简单方法是开启一个 Git 守护进程,不过这将要求该进程作为后台进程常驻 — 接下来的这一节就要讨论这方面的细节。 公共访问 现在我们的项目已经有了可读可写和只读的连接方式,不过如果能有一个简单的 web 界面访问就更好了。Git 自带一个叫做 GitWeb 的 CGI 脚本,运行效果可以到 http://git.kernel.org 这样的站点体验下(见图 4-1)。 Figure 4-1. 基于网页的 GitWeb 用户界面 如果想看看自己项目的效果,不妨用 Git 自带的一个命令,可以使用类似 lighttpd 或 webrick 这样轻量级的服务器启动一个 临时进程。如果是在 Linux 主机上,通常都预装了 lighttpd ,可以到项目目录中键入 git instaweb 来启动。如果用的是 Mac ,Leopard 预装了 Ruby,所以 webrick 应该是最好的选择。如果要用 lighttpd 以外的程序来启动 git instaweb ,可以通过 -- httpd 选项指定: $ git instaweb --httpd=webrick [2009-02-21 10:02:21] INFO WEBrick 1.3.1 [2009-02-21 10:02:21] INFO ruby 1.8.6 (2008-03-03) [universal-darwin9.0] 这会在 1234 端口开启一个 HTTPD 服务,随之在浏览器中显示该页,十分简单。关闭服务时,只需在原来的命令后面加上 - -stop 选项就可以了: $ git instaweb --httpd=webrick --stop 如果需要为团队或者某个开源项目长期运行 GitWeb,那么 CGI 脚本就要由正常的网页服务来运行。一些 Linux 发行版可以 通过 apt 或 yum 安装一个叫做 gitweb 的软件包,不妨首先尝试一下。我们将快速介绍一下手动安装 GitWeb 的流程。首 先,你需要 Git 的源码,其中带有 GitWeb,并能生成定制的 CGI 脚本: $ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git/ $ make GITWEB_PROJECTROOT="/opt/git" \ prefix=/usr gitweb $ sudo cp -Rf gitweb /var/www/ 注意,通过指定 GITWEB_PROJECTROOT 变量告诉编译命令 Git 仓库的位置。然后,设置 Apache 以 CGI 方式运行该脚本,添 加一个 VirtualHost 配置: GitWeb ServerName gitserver DocumentRoot /var/www/gitweb Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch AllowOverride All order allow,deny Allow from all AddHandler cgi-script cgi DirectoryIndex gitweb.cgi 不难想象,GitWeb 可以使用任何兼容 CGI 的网页服务来运行;如果偏向使用其他 web 服务器,配置也不会很麻烦。现在, 通过 http://gitserver 就可以在线访问仓库了,在 http://git.server 上还可以通过 HTTP 克隆和获取仓库的内容。 把所有用户的公钥保存在 authorized_keys 文件的做法,只能凑和一阵子,当用户数量达到几百人的规模时,管理起来就会十 分痛苦。每次改删用户都必须登录服务器不去说,这种做法还缺少必要的权限管理 — 每个人都对所有项目拥有完整的读写权 限。 幸好我们还可以选择应用广泛的 Gitosis 项目。简单地说,Gitosis 就是一套用来管理 authorized_keys 文件和实现简单连接限 制的脚本。有趣的是,用来添加用户和设定权限的并非通过网页程序,而只是管理一个特殊的 Git 仓库。你只需要在这个特 殊仓库内做好相应的设定,然后推送到服务器上,Gitosis 就会随之改变运行策略,听起来就很酷,对吧? Gitosis 的安装算不上傻瓜化,但也不算太难。用 Linux 服务器架设起来最简单 — 以下例子中,我们使用装有 Ubuntu 8.10 系统的服务器。 Gitosis 的工作依赖于某些 Python 工具,所以首先要安装 Python 的 setuptools 包,在 Ubuntu 上称为 python-setuptools: $ apt-get install python-setuptools 接下来,从 Gitosis 项目主页克隆并安装: $ git clone https://github.com/tv42/gitosis.git $ cd gitosis $ sudo python setup.py install 这会安装几个供 Gitosis 使用的工具。默认 Gitosis 会把 /home/git 作为存储所有 Git 仓库的根目录,这没什么不好,不过我 们之前已经把项目仓库都放在 /opt/git 里面了,所以为方便起见,我们可以做一个符号连接,直接划转过去,而不必重新配 置: $ ln -s /opt/git /home/git/repositories Gitosis 将会帮我们管理用户公钥,所以先把当前控制文件改名备份,以便稍后重新添加,准备好让 Gitosis 自动管理 authorized_keys 文件: $ mv /home/git/.ssh/authorized_keys /home/git/.ssh/ak.bak 接下来,如果之前把 git 用户的登录 shell 改为 git-shell 命令的话,先恢复 'git' 用户的登录 shell。改过之后,大家仍然无法 通过该帐号登录(译注:因为 authorized_keys 文件已经没有了。),不过不用担心,这会交给 Gitosis 来实现。所以现在先 打开 /etc/passwd 文件,把这行: git:x:1000:1000::/home/git:/usr/bin/git-shell 改回: git:x:1000:1000::/home/git:/bin/sh 好了,现在可以初始化 Gitosis 了。你可以用自己的公钥执行 gitosis-init 命令,要是公钥不在服务器上,先临时复制一份: $ sudo -H -u git gitosis-init < /tmp/id_dsa.pub Initialized empty Git repository in /opt/git/gitosis-admin.git/ Reinitialized existing Git repository in /opt/git/gitosis-admin.git/ Gitosis 这样该公钥的拥有者就能修改用于配置 Gitosis 的那个特殊 Git 仓库了。接下来,需要手工对该仓库中的 post-update 脚本加 上可执行权限: $ sudo chmod 755 /opt/git/gitosis-admin.git/hooks/post-update 基本上就算是好了。如果设定过程没出什么差错,现在可以试一下用初始化 Gitosis 的公钥的拥有者身份 SSH 登录服务器, 应该会看到类似下面这样: $ ssh git@gitserver PTY allocation request failed on channel 0 ERROR:gitosis.serve.main:Need SSH_ORIGINAL_COMMAND in environment. Connection to gitserver closed. 说明 Gitosis 认出了该用户的身份,但由于没有运行任何 Git 命令,所以它切断了连接。那么,现在运行一个实际的 Git 命令 — 克隆 Gitosis 的控制仓库: # 在你本地计算机上 $ git clone git@gitserver:gitosis-admin.git 这会得到一个名为 gitosis-admin 的工作目录,主要由两部分组成: $ cd gitosis-admin $ find . ./gitosis.conf ./keydir ./keydir/scott.pub gitosis.conf 文件是用来设置用户、仓库和权限的控制文件。 keydir 目录则是保存所有具有访问权限用户公钥的地方— 每人 一个。在 keydir 里的文件名(比如上面的 scott.pub )应该跟你的不一样 — Gitosis 会自动从使用 gitosis-init 脚本导入的公 钥尾部的描述中获取该名字。 看一下 gitosis.conf 文件的内容,它应该只包含与刚刚克隆的 gitosis-admin 相关的信息: $ cat gitosis.conf [gitosis] [group gitosis-admin] members = scott writable = gitosis-admin 它显示用户 scott — 初始化 Gitosis 公钥的拥有者 — 是唯一能管理 gitosis-admin 项目的人。 现在我们来添加一个新项目。为此我们要建立一个名为 mobile 的新段落,在其中罗列手机开发团队的开发者,以及他们拥 有写权限的项目。由于 'scott' 是系统中的唯一用户,我们把他设为唯一用户,并允许他读写名为 iphone_project 的新项目: [group mobile] members = scott writable = iphone_project 修改完之后,提交 gitosis-admin 里的改动,并推送到服务器使其生效: $ git commit -am 'add iphone_project and mobile group' [master 8962da8] add iphone_project and mobile group 1 file changed, 4 insertions(+) $ git push origin master Counting objects: 5, done. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 272 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@gitserver:gitosis-admin.git fb27aec..8962da8 master -> master 在新工程 iphone_project 里首次推送数据到服务器前,得先设定该服务器地址为远程仓库。但你不用事先到服务器上手工创 建该项目的裸仓库— Gitosis 会在第一次遇到推送时自动创建: $ git remote add origin git@gitserver:iphone_project.git $ git push origin master Initialized empty Git repository in /opt/git/iphone_project.git/ Counting objects: 3, done. Writing objects: 100% (3/3), 230 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) To git@gitserver:iphone_project.git * [new branch] master -> master 请注意,这里不用指明完整路径(实际上,如果加上反而没用),只需要一个冒号加项目名字即可 — Gitosis 会自动帮你映 射到实际位置。 要和朋友们在一个项目上协同工作,就得重新添加他们的公钥。不过这次不用在服务器上一个一个手工添加到 ~/.ssh/authorized_keys 文件末端,而只需管理 keydir 目录中的公钥文件。文件的命名将决定在 gitosis.conf 中对用户的标 识。现在我们为 John,Josie 和 Jessica 添加公钥: $ cp /tmp/id_rsa.john.pub keydir/john.pub $ cp /tmp/id_rsa.josie.pub keydir/josie.pub $ cp /tmp/id_rsa.jessica.pub keydir/jessica.pub 然后把他们都加进 'mobile' 团队,让他们对 iphone_project 具有读写权限: [group mobile] members = scott john josie jessica writable = iphone_project 如果你提交并推送这个修改,四个用户将同时具有该项目的读写权限。 Gitosis 也具有简单的访问控制功能。如果想让 John 只有读权限,可以这样做: [group mobile] members = scott josie jessica writable = iphone_project [group mobile_ro] members = john readonly = iphone_project 现在 John 可以克隆和获取更新,但 Gitosis 不会允许他向项目推送任何内容。像这样的组可以随意创建,多少不限,每个都 可以包含若干不同的用户和项目。甚至还可以指定某个组为成员之一(在组名前加上 @ 前缀),自动继承该组的成员: [group mobile_committers] members = scott josie jessica [group mobile] members = @mobile_committers writable = iphone_project [group mobile_2] members = @mobile_committers john writable = another_iphone_project 如果遇到意外问题,试试看把 loglevel=DEBUG 加到 [gitosis] 的段落(译注:把日志设置为调试级别,记录更详细的运行信 息。)。如果一不小心搞错了配置,失去了推送权限,也可以手工修改服务器上的 /home/git/.gitosis.conf 文件 — Gitosis 实 际是从该文件读取信息的。它在得到推送数据时,会把新的 gitosis.conf 存到该路径上。所以如果你手工编辑该文件的话,它 会一直保持到下次向 gitosis-admin 推送新版本的配置内容为止。 This section serves as a quick introduction to Gitolite, and provides basic installation and setup instructions. 不能完全替代 随 gitolite 自带的大量文档。 There may also be occasional changes to this section itself, so you may also want to look at the latest version here. Gitolite is an authorization layer on top of Git, relying on sshd or httpd for authentication. (Recap: authentication is identifying who the user is, authorization is deciding if he is allowed to do what he is attempting to). Gitolite 允许你定义访问许可而不只作用于仓库,而同样于仓库中的每个branch和tag name。你可以定义确切的人 (或一组 人) 只能push特定的 "refs" (或者branches或者tags)而不是其他人。 安装 Gitolite非常简单, 你甚至不用读自带的那一大堆文档。你需要一个unix服务器上的账户;许多linux变种和solaris 10都已 经试过了。你不需要root访问,假设git,perl,和一个openssh兼容的ssh服务器已经装好了。在下面的例子里,我们会用 git 账户在 gitserver 上. Gitolite 是不同于 "server" 的软件 -- 通过ssh访问, 而且每个在服务器上的userid都是一个潜在的 "gitolite host". We will describe the simplest install method in this article; for the other methods please see the documentation. To begin, create a user called git on your server and login to this user. Copy your SSH public key (a file called ~/.ssh/id_rsa.pub if you did a plain ssh-keygen with all the defaults) from your workstation, renaming it to .pub (we'll use scott.pub in our examples). Then run these commands: $ git clone git://github.com/sitaramc/gitolite $ gitolite/install -ln # assumes $HOME/bin exists and is in your $PATH $ gitolite setup -pk $HOME/scott.pub That last command creates new Git repository called gitolite-admin on the server. Finally, back on your workstation, run git clone git@gitserver:gitolite-admin . And you’re done! Gitolite has now been installed on the server, and you now have a brand new repository called gitolite-admin in your workstation. You administer your Gitolite setup by making changes to this repository and pushing. 默认快速安装对大多数人都管用,还有一些定制安装方法如果你用的上的话。Some changes can be made simply by editing the rc file, but if that is not sufficient, there’s documentation on customising Gitolite. 安装结束后,你切换到 gitolite-admin 仓库 (放在你的 HOME 目录) 然后看看都有啥: Gitolite 安装 定制安装 配置文件和访问规则 $ cd ~/gitolite-admin/ $ ls conf/ keydir/ $ find conf keydir -type f conf/gitolite.conf keydir/scott.pub $ cat conf/gitolite.conf repo gitolite-admin RW+ = scott repo testing RW+ = @all 注意 "scott" ( 之前用 gl-setup 命令时候的 pubkey 名稱) 有读写权限而且在 gitolite-admin 仓库里有一个同名的公钥文件。 Adding users is easy. To add a user called "alice", obtain her public key, name it alice.pub , and put it in the keydir directory of the clone of the gitolite-admin repo you just made on your workstation. Add, commit, and push the change, and the user has been added. gitolite配置文件的语法在 conf/example.conf 里,我们只会提到一些主要的。 你可以给用户或者仓库分组。分组名就像一些宏;定义的时候,无所谓他们是工程还是用户;区别在于你’使用‘“宏”的时候 @oss_repos = linux perl rakudo git gitolite @secret_repos = fenestra pear @admins = scott @interns = ashok @engineers = sitaram dilbert wally alice @staff = @admins @engineers @interns 你可以控制许可在 "ref" 级别。在下面的例子里,实习生可以 push "int" branch. 工程师可以 push任何有 "eng-"开头的 branch,还有refs/tags下面用 "rc"开头的后面跟数字的。而且管理员可以随便改 (包括rewind) 对任何参考名. repo @oss_repos RW int$ = @interns RW eng- = @engineers RW refs/tags/rc[0-9] = @engineers RW+ = @admins 在 RW or RW+ 之后的表达式是正则表达式 (regex) 对应着后面的push用的参考名字 (ref) 。所以我们叫它 "参考正 则"(refex)!当然,一个 refex 可以比这里表现的更强大,所以如果你对perl的正则表达式不熟的话就不要改过头。 同样,你可能猜到了,Gitolite 字头 refs/heads/ 是一个便捷句法如果参考正则没有用 refs/ 开头。 一个这个配置文件语法的重要功能是,所有的仓库的规则不需要在同一个位置。你能报所有普通的东西放在一起,就像上面 的对所有 oss_repos 的规则那样,然后建一个特殊的规则对后面的特殊案例,就像: repo gitolite RW+ = sitaram 那条规则刚刚加入规则集的 gitolite 仓库. 这次你可能会想要知道访问控制规则是如何应用的,我们简要介绍一下。 在gitolite里有两级访问控制。第一是在仓库级别;如果你已经读或者写访问过了任何在仓库里的参考,那么你已经读或者写 访问仓库了。 第二级,应用只能写访问,通过在仓库里的 branch或者 tag。用户名如果尝试过访问 ( W 或 + ),参考名被更新为已知。访 问规则检查是否出现在配置文件里,为这个联合寻找匹配 (但是记得参考名是正则匹配的,不是字符串匹配的)。如果匹配被 找到了,push就成功了。不匹配的访问会被拒绝。 目前,我们只看过了许可是 R , RW , 或者 RW+ 这样子的。但是gitolite还允许另外一种许可: - ,代表 "拒绝"。这个给了你更 多的能力,当然也有一点复杂,因为不匹配并不是唯一的拒绝访问的方法,因此规则的顺序变得无关了! 这么说好了,在前面的情况中,我们想要工程师可以 rewind 任意 branch 除了master和 integ。 这里是如何做到的 RW master integ = @engineers - master integ = @engineers RW+ = @engineers 你再一次简单跟随规则从上至下知道你找到一个匹配你的访问模式的,或者拒绝。非rewind push到 master或者 integ 被第 一条规则允许。一个 rewind push到那些 refs不匹配第一条规则,掉到第二条,因此被拒绝。任何 push (rewind 或非rewind) 到参考或者其他 master 或者 integ不会被前两条规则匹配,即被第三条规则允许。 此外限制用户 push改变到哪条branch的,你也可以限制哪个文件他们可以碰的到。比如, 可能 Makefile (或者其他哪些程序) 真的不能被任何人做任何改动,因为好多东西都靠着它呢,或者如果某些改变刚好不对就会崩溃。你可以告诉 gitolite: repo foo RW = @junior_devs @senior_devs - VREF/NAME/Makefile = @junior_devs 这是一个强力的公能写在 conf/example.conf 里。 Gitolite 也支持一个叫 "个人分支"的功能 (或者叫, "个人分支命名空间") 在合作环境里非常有用。 在 git世界里许多代码交换通过 "pull" 请求发生。然而在合作环境里,委任制的访问是‘绝不’,一个开发者工作站不能认证, 你必须push到中心服务器并且叫其他人从那里pull。 这个通常会引起一些 branch 名称簇变成像 VCS里一样集中化,加上设置许可变成管理员的苦差事。 Gitolite让你定义一个 "个人的" 或者 "乱七八糟的" 命名空间字首给每个开发人员 (比如, refs/personal//* );看在 doc/3-faq-tips-etc.mkd 里的 "personal branches" 一段获取细节。 Gitolite 允许你定义带通配符的仓库 (其实还是 perl正则式), 比如随便整个例子的话 assignments/s[0-9][0-9]/a[0-9][0-9] 。 这是 一个非常有用的功能,需要通过设置 $GL_WILDREPOS = 1; 在 rc文件中启用。允许你安排一个新许可模式 ("C") 允许用户创建 仓库基于通配符,自动分配拥有权对特定用户 - 创建者,允许他交出 R和 RW许可给其他合作用户等等。这个功能在 doc/4- wildcard-repositories.mkd 文档里 我们用一些其他功能的例子结束这段讨论,这些以及其他功能都在 "faqs, tips, etc" 和其他文档里。 带'拒绝'的高级访问控制 通过改变文件限制 push 个人分支 "通配符" 仓库 其他功能 记录: Gitolite 记录所有成功的访问。如果你太放松给了别人 rewind许可 ( RW+ ) 和其他孩子弄没了 "master", 记录文件会救 你的命,如果其他简单快速的找到SHA都不管用。 访问权报告: 另一个方便的功能是你尝试用ssh连接到服务器的时候发生了什么。Gitolite告诉你哪个 repos你访问过,那个访 问可能是什么。这里是例子: hello scott, this is git@git running gitolite3 v3.01-18-g9609868 on git 1.7.4.4 R anu-wsd R entrans R W git-notes R W gitolite R W gitolite-admin R indic_web_input R shreelipi_converter 委托:真正的大安装,你可以把责任委托给一组仓库给不同的人然后让他们独立管理那些部分。这个减少了主管理者的负 担,让他瓶颈更小。这个功能在他自己的文档目录里的 doc/ 下面。 镜像: Gitolite可以帮助你维护多个镜像,如果主服务器挂掉的话在他们之间很容易切换。 对于提供公共的,非授权的只读访问,我们可以抛弃 HTTP 协议,改用 Git 自己的协议,这主要是出于性能和速度的考虑。 Git 协议远比 HTTP 协议高效,因而访问速度也快,所以它能节省很多用户的时间。 重申一下,这一点只适用于非授权的只读访问。如果建在防火墙之外的服务器上,那么它所提供的服务应该只是那些公开的 只读项目。如果是在防火墙之内的服务器上,可用于支撑大量参与人员或自动系统(用于持续集成或编译的主机)只读访问 的项目,这样可以省去逐一配置 SSH 公钥的麻烦。 但不管哪种情形,Git 协议的配置设定都很简单。基本上,只要以守护进程的形式运行该命令即可: git daemon --reuseaddr --base-path=/opt/git/ /opt/git/ 这里的 --reuseaddr 选项表示在重启服务前,不等之前的连接超时就立即重启。而 --base-path 选项则允许克隆项目时不必给 出完整路径。最后面的路径告诉 Git 守护进程允许开放给用户访问的仓库目录。假如有防火墙,则需要为该主机的 9418 端口 设置为允许通信。 以守护进程的形式运行该进程的方法有很多,但主要还得看用的是什么操作系统。在 Ubuntu 主机上,可以用 Upstart 脚本达 成。编辑该文件: /etc/event.d/local-git-daemon 加入以下内容: start on startup stop on shutdown exec /usr/bin/git daemon \ --user=git --group=git \ --reuseaddr \ --base-path=/opt/git/ \ /opt/git/ respawn 出于安全考虑,强烈建议用一个对仓库只有读取权限的用户身份来运行该进程 — 只需要简单地新建一个名为 git-ro 的用户 (译注:新建用户默认对仓库文件不具备写权限,但这取决于仓库目录的权限设定。务必确认 git-ro 对仓库只能读不能写。 ),并用它的身份来启动进程。这里为了简化,后面我们还是用之前运行 Gitosis 的用户 'git'。 这样一来,当你重启计算机时,Git 进程也会自动启动。要是进程意外退出或者被杀掉,也会自行重启。在设置完成后,不重 启计算机就启动该守护进程,可以运行: initctl start local-git-daemon 而在其他操作系统上,可以用 xinetd ,或者 sysvinit 系统的脚本,或者其他类似的脚本 — 只要能让那个命令变为守护进程 并可监控。 接下来,我们必须告诉 Gitosis 哪些仓库允许通过 Git 协议进行匿名只读访问。如果每个仓库都设有各自的段落,可以分别指 定是否允许 Git 进程开放给用户匿名读取。比如允许通过 Git 协议访问 iphone_project,可以把下面两行加到 gitosis.conf 文 件的末尾: [repo iphone_project] daemon = yes 在提交和推送完成后,运行中的 Git 守护进程就会响应来自 9418 端口对该项目的访问请求。 Git 守护进程 如果不考虑 Gitosis,单单起了 Git 守护进程的话,就必须到每一个允许匿名只读访问的仓库目录内,创建一个特殊名称的空 文件作为标志: $ cd /path/to/project.git $ touch git-daemon-export-ok 该文件的存在,表明允许 Git 守护进程开放对该项目的匿名只读访问。 Gitosis 还能设定哪些项目允许放在 GitWeb 上显示。先打开 GitWeb 的配置文件 /etc/gitweb.conf ,添加以下四行: $projects_list = "/home/git/gitosis/projects.list"; $projectroot = "/home/git/repositories"; $export_ok = "git-daemon-export-ok"; @git_base_url_list = ('git://gitserver'); 接下来,只要配置各个项目在 Gitosis 中的 gitweb 参数,便能达成是否允许 GitWeb 用户浏览该项目。比如,要让 iphone_project 项目在 GitWeb 里出现,把 repo 的设定改成下面的样子: [repo iphone_project] daemon = yes gitweb = yes 在提交并推送过之后,GitWeb 就会自动开始显示 iphone_project 项目的细节和历史。 如果不想经历自己架设 Git 服务器的麻烦,网络上有几个专业的仓库托管服务可供选择。这样做有几大优点:托管账户的建 立通常比较省时,方便项目的启动,而且不涉及服务器的维护和监控。即使内部创建并运行着自己的服务器,同时为开源项 目提供一个公共托管站点还是有好处的 — 让开源社区更方便地找到该项目,并给予帮助。 目前,可供选择的托管服务数量繁多,各有利弊。在 Git 官方 wiki 上的 Githosting 页面有一个最新的托管服务列表: https://git.wiki.kernel.org/index.php/GitHosting 由于本书无法全部一一介绍,而本人(译注:指本书作者 Scott Chacon。)刚好在其中一家公司工作,所以接下来我们将会 介绍如何在 GitHub 上建立新账户并启动项目。至于其他托管服务大体也是这么一个过程,基本的想法都是差不多的。 GitHub 是目前为止最大的开源 Git 托管服务,并且还是少数同时提供公共代码和私有代码托管服务的站点之一,所以你可以 在上面同时保存开源和商业代码。事实上,本书就是放在 GitHub 上合作编著的。(译注:本书的翻译也是放在 GitHub 上广 泛协作的。) GitHub 和大多数的代码托管站点在处理项目命名空间的方式上略有不同。GitHub 的设计更侧重于用户,而不是完全基于项 目。也就是说,如果我在 GitHub 上托管一个名为 grit 的项目的话,它的地址不会是 github.com/grit ,而是按在用户底下 github.com/shacon/grit (译注:本书作者 Scott Chacon 在 GitHub 上的用户名是 shacon 。)。不存在所谓某个项目的官方 版本,所以假如第一作者放弃了某个项目,它可以无缝转移到其它用户的名下。 GitHub 同时也是一个向使用私有仓库的用户收取费用的商业公司,但任何人都可以方便快捷地申请到一个免费账户,并在上 面托管数量不限的开源项目。接下来我们快速介绍一下 GitHub 的基本使用。 首先注册一个免费账户。访问 Pricing and Signup 页面 http://github.com/plans 并点击 Free acount 里的 Sign Up 按钮(见图 4-2),进入注册页面。 图 4-2. GitHub 服务简介页面 选择一个系统中尚未使用的用户名,提供一个与之相关联的电邮地址,并输入密码(见图 4-3): Git 托管服务 GitHub 建立新账户 图 4-3. GitHub 用户注册表单 如果方便,现在就可以提供你的 SSH 公钥。我们在前文的"小型安装" 一节介绍过生成新公钥的方法。把新生成的公钥复制粘 贴到 SSH Public Key 文本框中即可。要是对生成公钥的步骤不太清楚,也可以点击 "explain ssh keys" 链接,会显示各个主 流操作系统上完成该步骤的介绍。 点击 "I agree,sign me up" 按钮完成用户注册,并转到该用户的 dashboard 页面(见图 4-4): 图 4-4. GitHub 的用户面板 接下来就可以建立新仓库了。 点击用户面板上仓库旁边的 "create a new one" 链接,显示 Create a New Repository 的表单(见图 4-5): 建立新仓库 图 4-5. 在 GitHub 上建立新仓库 当然,项目名称是必不可少的,此外也可以适当描述一下项目的情况或者给出官方站点的地址。然后点击 "Create Repository" 按钮,新仓库就建立起来了(见图 4-6): 图 4-6. GitHub 上各个项目的概要信息 由于尚未提交代码,点击项目地址后 GitHub 会显示一个简要的指南,告诉你如何新建一个项目并推送上来,如何从现有项 目推送,以及如何从一个公共的 Subversion 仓库导入项目(见图 4-7): 图 4-7. 新仓库指南 该指南和本书前文介绍的类似,对于新的项目,需要先在本地初始化为 Git 项目,添加要管理的文件并作首次提交: $ git init $ git add . $ git commit -m 'initial commit' 然后在这个本地仓库内把 GitHub 添加为远程仓库,并推送 master 分支上来: $ git remote add origin git@github.com:testinguser/iphone_project.git $ git push origin master 现在该项目就托管在 GitHub 上了。你可以把它的 URL 分享给每位对此项目感兴趣的人。本例的 URL 是 http://github.com/testinguser/iphone_project 。而在项目页面的摘要部分,你会发现有两个 Git URL 地址(见图 4-8): 图 4-8. 项目摘要中的公共 URL 和私有 URL Public Clone URL 是一个公开的,只读的 Git URL,任何人都可以通过它克隆该项目。可以随意散播这个 URL,比如发布到 个人网站之类的地方等等。 Your Clone URL 是一个基于 SSH 协议的可读可写 URL,只有使用与上传的 SSH 公钥对应的密钥来连接时,才能通过它进 行读写操作。其他用户访问该项目页面时只能看到之前那个公共的 URL,看不到这个私有的 URL。 如果想把某个公共 Subversion 项目导入 Git,GitHub 可以帮忙。在指南的最后有一个指向导入 Subversion 页面的链接。点 击它会看到一个表单,包含有关导入流程的信息以及一个用来粘贴公共 Subversion 项目连接的文本框(见图 4-9): 图 4-9. Subversion 导入界面 如果项目很大,采用非标准结构,或者是私有的,那就无法借助该工具实现导入。到第 7 章,我们会介绍如何手工导入复杂 工程的具体方法。 从 Subversion 导入项目 添加协作开发者 现在把团队里的其他人也加进来。如果 John,Josie 和 Jessica 都在 GitHub 注册了账户,要赋予他们对该仓库的推送权 限,可以把他们加为项目协作者。这样他们就可以通过各自的公钥访问我的这个仓库了。 点击项目页面上方的 "edit" 按钮或者顶部的 Admin 标签,进入该项目的管理页面(见图 4-10): 图 4-10. GitHub 的项目管理页面 为了给另一个用户添加项目的写权限,点击 "Add another collaborator" 链接,出现一个用于输入用户名的表单。在输入的同 时,它会自动跳出一个符合条件的候选名单。找到正确用户名之后,点 Add 按钮,把该用户设为项目协作者(见图 4- 11): 图 4-11. 为项目添加协作者 添加完协作者之后,就可以在 Repository Collaborators 区域看到他们的名单(见图 4-12): 图 4-12. 项目协作者名单 如果要取消某人的访问权,点击 "revoke" 即可取消他的推送权限。对于将来的项目,你可以从现有项目复制协作者名单,或 者直接借用协作者群组。 在推送或从 Subversion 导入项目之后,你会看到一个类似图 4-13 的项目主页: 项目页面 图 4-13. GitHub 上的项目主页 别人访问你的项目时看到的就是这个页面。它有若干导航标签,Commits 标签用于显示提交历史,最新的提交位于最上方, 这和 git log 命令的输出类似。Network 标签展示所有派生了该项目并做出贡献的用户的关系图谱。Downloads 标签允许你 上传项目的二进制文件,提供下载该项目各个版本的 tar/zip 包。Wiki 标签提供了一个用于撰写文档或其他项目相关信息的 wiki 站点。Graphs 标签包含了一些可视化的项目信息与数据。默认打开的 Source 标签页面,则列出了该项目的目录结构和 概要信息,并在下方自动展示 README 文件的内容(如果该文件存在的话),此外还会显示最近一次提交的相关信息。 如果要为一个自己没有推送权限的项目贡献代码,GitHub 鼓励使用派生(fork)。到那个感兴趣的项目主页上,点击页面上 方的 "fork" 按钮,GitHub 就会为你复制一份该项目的副本到你的仓库中,这样你就可以向自己的这个副本推送数据了。 采取这种办法的好处是,项目拥有者不必忙于应付赋予他人推送权限的工作。随便谁都可以通过派生得到一个项目副本并在 其中展开工作,事后只需要项目维护者将这些副本仓库加为远程仓库,然后提取更新合并即可。 要派生一个项目,到原始项目的页面(本例中是 mojombo/chronic)点击 "fork" 按钮(见图 4-14): 图 4-14. 点击 "fork" 按钮获得任意项目的可写副本 几秒钟之后,你将进入新建的项目页面,会显示该项目派生自哪一个项目(见图 4-15): 派生项目 图 4-15. 派生后得到的项目副本 关于 GitHub 就先介绍这么多,能够快速达成这些事情非常重要(译注:门槛的降低和完成基本任务的简单高效,对于推动 开源项目的协作发展有着举足轻重的意义。)。短短几分钟内,你就能创建一个新账户,添加一个项目并开始推送。如果项 目是开源的,整个庞大的开发者社区都可以立即访问它,提供各式各样的帮助和贡献。最起码,这也是一种 Git 新手立即体 验尝试 Git 的捷径。 GitHub 小结 我们讨论并介绍了一些建立远程 Git 仓库的方法,接下来你可以通过这些仓库同他人分享或合作。 运行自己的服务器意味着更多的控制权以及在防火墙内部操作的可能性,当然这样的服务器通常需要投入一定的时间精力来 架设维护。如果直接托管,虽然能免去这部分工作,但有时出于安全或版权的考虑,有些公司禁止将商业代码托管到第三方 服务商。 所以究竟采取哪种方案,并不是个难以取舍的问题,或者其一,或者相互配合,哪种合适就用哪种。 小结 为了便于项目中的所有开发者分享代码,我们准备好了一台服务器存放远程 Git 仓库。经过前面几章的学习,我们已经学会 了一些基本的本地工作流程中所需用到的命令。接下来,我们要学习下如何利用 Git 来组织和完成分布式工作流程。 特别是,当作为项目贡献者时,我们该怎么做才能方便维护者采纳更新;或者作为项目维护者时,又该怎样有效管理大量贡 献者的提交。 分布式 Git 同传统的集中式版本控制系统(CVCS)不同,开发者之间的协作方式因着 Git 的分布式特性而变得更为灵活多样。在集中式 系统上,每个开发者就像是连接在集线器上的节点,彼此的工作方式大体相像。而在 Git 网络中,每个开发者同时扮演着节 点和集线器的角色,这就是说,每一个开发者都可以将自己的代码贡献到另外一个开发者的仓库中,或者建立自己的公共仓 库,让其他开发者基于自己的工作开始,为自己的仓库贡献代码。于是,Git 的分布式协作便可以衍生出种种不同的工作流 程,我会在接下来的章节介绍几种常见的应用方式,并分别讨论各自的优缺点。你可以选择其中的一种,或者结合起来,应 用到你自己的项目中。 通常,集中式工作流程使用的都是单点协作模型。一个存放代码仓库的中心服务器,可以接受所有开发者提交的代码。所有 的开发者都是普通的节点,作为中心集线器的消费者,平时的工作就是和中心仓库同步数据(见图 5-1)。 图 5-1. 集中式工作流 如果两个开发者从中心仓库克隆代码下来,同时作了一些修订,那么只有第一个开发者可以顺利地把数据推送到共享服务 器。第二个开发者在提交他的修订之前,必须先下载合并服务器上的数据,解决冲突之后才能推送数据到共享服务器上。在 Git 中这么用也决无问题,这就好比是在用 Subversion(或其他 CVCS)一样,可以很好地工作。 如果你的团队不是很大,或者大家都已经习惯了使用集中式工作流程,完全可以采用这种简单的模式。只需要配置好一台中 心服务器,并给每个人推送数据的权限,就可以开展工作了。但如果提交代码时有冲突, Git 根本就不会让用户覆盖他人代 码,它直接驳回第二个人的提交操作。这就等于告诉提交者,你所作的修订无法通过快近(fast-forward)来合并,你必须先 拉取最新数据下来,手工解决冲突合并后,才能继续推送新的提交。 绝大多数人都熟悉和了解这种模式的工作方式,所以使 用也非常广泛。 由于 Git 允许使用多个远程仓库,开发者便可以建立自己的公共仓库,往里面写数据并共享给他人,而同时又可以从别人的 仓库中提取他们的更新过来。这种情形通常都会有个代表着官方发布的项目仓库(blessed repository),开发者们由此仓库 克隆出一个自己的公共仓库(developer public),然后将自己的提交推送上去,请求官方仓库的维护者拉取更新合并到主项 目。维护者在自己的本地也有个克隆仓库(integration manager),他可以将你的公共仓库作为远程仓库添加进来,经过测 试无误后合并到主干分支,然后再推送到官方仓库。工作流程看起来就像图 5-2 所示: 1. 项目维护者可以推送数据到公共仓库 blessed repository。 2. 贡献者克隆此仓库,修订或编写新代码。 3. 贡献者推送数据到自己的公共仓库 developer public。 4. 贡献者给维护者发送邮件,请求拉取自己的最新修订。 5. 维护者在自己本地的 integration manger 仓库中,将贡献者的仓库加为远程仓库,合并更新并做测试。 6. 维护者将合并后的更新推送到主仓库 blessed repository。 分布式工作流程 集中式工作流 集成管理员工作流 图 5-2. 集成管理员工作流 在 GitHub 网站上使用得最多的就是这种工作流。人们可以复制(fork 亦即克隆)某个项目到自己的列表中,成为自己的公共 仓库。随后将自己的更新提交到这个仓库,所有人都可以看到你的每次更新。这么做最主要的优点在于,你可以按照自己的 节奏继续工作,而不必等待维护者处理你提交的更新;而维护者也可以按照自己的节奏,任何时候都可以过来处理接纳你的 贡献。 这其实是上一种工作流的变体。一般超大型的项目才会用到这样的工作方式,像是拥有数百协作开发者的 Linux 内核项目就 是如此。各个集成管理员分别负责集成项目中的特定部分,所以称为副官(lieutenant)。而所有这些集成管理员头上还有一 位负责统筹的总集成管理员,称为司令官(dictator)。司令官维护的仓库用于提供所有协作者拉取最新集成的项目代码。整 个流程看起来如图 5-3 所示: 1. 一般的开发者在自己的特性分支上工作,并不定期地根据主干分支(dictator 上的 master)衍合。 2. 副官(lieutenant)将普通开发者的特性分支合并到自己的 master 分支中。 3. 司令官(dictator)将所有副官的 master 分支并入自己的 master 分支。 4. 司令官(dictator)将集成后的 master 分支推送到共享仓库 blessed repository 中,以便所有其他开发者以此为基础进 行衍合。 图 5-3. 司令官与副官工作流 这种工作流程并不常用,只有当项目极为庞杂,或者需要多级别管理时,才会体现出优势。利用这种方式,项目总负责人 (即司令官)可以把大量分散的集成工作委托给不同的小组负责人分别处理,最后再统筹起来,如此各人的职责清晰明确, 司令官与副官工作流 也不易出错(译注:此乃分而治之)。 以上介绍的是常见的分布式系统可以应用的工作流程,当然不止于 Git。在实际的开发工作中,你可能会遇到各种为了满足特 定需求而有所变化的工作方式。我想现在你应该已经清楚,接下来自己需要用哪种方式开展工作了。下节我还会再举些例 子,看看各式工作流中的每个角色具体应该如何操作。 接下来,我们来学习一下作为项目贡献者,会有哪些常见的工作模式。 不过要说清楚整个协作过程真的很难,Git 如此灵活,人们的协作方式便可以各式各样,没有固定不变的范式可循,而每个项 目的具体情况又多少会有些不同,比如说参与者的规模,所选择的工作流程,每个人的提交权限,以及 Git 以外贡献等等, 都会影响到具体操作的细节。 首当其冲的是参与者规模。项目中有多少开发者是经常提交代码的?经常又是多久呢?大多数两至三人的小团队,一天大约 只有几次提交,如果不是什么热门项目的话就更少了。可要是在大公司里,或者大项目中,参与者可以多到上千,每天都会 有十几个上百个补丁提交上来。这种差异带来的影响是显著的,越是多的人参与进来,就越难保证每次合并正确无误。你正 在工作的代码,可能会因为合并进来其他人的更新而变得过时,甚至受创无法运行。而已经提交上去的更新,也可能在等着 审核合并的过程中变得过时。那么,我们该怎样做才能确保代码是最新的,提交的补丁也是可用的呢? 接下来便是项目所采用的工作流。是集中式的,每个开发者都具有等同的写权限?项目是否有专人负责检查所有补丁?是不 是所有补丁都做过同行复阅(peer-review)再通过审核的?你是否参与审核过程?如果使用副官系统,那你是不是限定于只 能向此副官提交? 还有你的提交权限。有或没有向主项目提交更新的权限,结果完全不同,直接决定最终采用怎样的工作流。如果不能直接提 交更新,那该如何贡献自己的代码呢?是不是该有个什么策略?你每次贡献代码会有多少量?提交频率呢? 所有以上这些问题都会或多或少影响到最终采用的工作流。接下来,我会在一系列由简入繁的具体用例中,逐一阐述。此后 在实践时,应该可以借鉴这里的例子,略作调整,以满足实际需要构建自己的工作流。 开始分析特定用例之前,先来了解下如何撰写提交说明。一份好的提交指南可以帮助协作者更轻松更有效地配合。Git 项目本 身就提供了一份文档(Git 项目源代码目录中 Documentation/SubmittingPatches ),列数了大量提示,从如何编撰提交说明到 提交补丁,不一而足。 首先,请不要在更新中提交多余的白字符(whitespace)。Git 有种检查此类问题的方法,在提交之前,先运行 git diff -- check ,会把可能的多余白字符修正列出来。下面的示例,我已经把终端中显示为红色的白字符用 X 替换掉: $ git diff --check lib/simplegit.rb:5: trailing whitespace. + @git_dir = File.expand_path(git_dir)XX lib/simplegit.rb:7: trailing whitespace. + XXXXXXXXXXX lib/simplegit.rb:26: trailing whitespace. + def command(git_cmd)XXXX 这样在提交之前你就可以看到这类问题,及时解决以免困扰其他开发者。 接下来,请将每次提交限定于完成一次逻辑功能。并且可能的话,适当地分解为多次小更新,以便每次小型提交都更易于理 解。请不要在周末穷追猛打一次性解决五个问题,而最后拖到周一再提交。就算是这样也请尽可能利用暂存区域,将之前的 改动分解为每次修复一个问题,再分别提交和加注说明。如果针对两个问题改动的是同一个文件,可以试试看 git add --patch 的方式将部分内容置入暂存区域(我们会在第六章再详细介绍)。无论是五次小提交还是混杂在一起的大提交,最终分支末 端的项目快照应该还是一样的,但分解开来之后,更便于其他开发者复阅。这么做也方便自己将来取消某个特定问题的修 复。我们将在第六章介绍一些重写提交历史,同暂存区域交互的技巧和工具,以便最终得到一个干净有意义,且易于理解的 提交历史。 最后需要谨记的是提交说明的撰写。写得好可以让大家协作起来更轻松。一般来说,提交说明最好限制在一行以内,50 个字 符以下,简明扼要地描述更新内容,空开一行后,再展开详细注解。Git 项目本身需要开发者撰写详尽注解,包括本次修订的 因由,以及前后不同实现之间的比较,我们也该借鉴这种做法。另外,提交说明应该用祈使现在式语态,比如,不要说成 “I added tests for” 或 “Adding tests for” 而应该用 “Add tests for”。 下面是来自 tpope.net 的 Tim Pope 原创的提交说明格式模 版,供参考: 为项目作贡献 提交指南 本次更新的简要描述(50 个字符以内) 如果必要,此处展开详尽阐述。段落宽度限定在 72 个字符以内。 某些情况下,第一行的简要描述将用作邮件标题,其余部分作为邮件正文。 其间的空行是必要的,以区分两者(当然没有正文另当别论)。 如果并在一起,rebase 这样的工具就可能会迷惑。 另起空行后,再进一步补充其他说明。 - 可以使用这样的条目列举式。 - 一般以单个空格紧跟短划线或者星号作为每项条目的起始符。每个条目间用一空行隔开。 不过这里按自己项目的约定,可以略作变化。 如果你的提交说明都用这样的格式来书写,好多事情就可以变得十分简单。Git 项目本身就是这样要求的,我强烈建议你到 Git 项目仓库下运行 git log --no-merges 看看,所有提交历史的说明是怎样撰写的。(译注:如果现在还没有克隆 git 项目源 代码,是时候 git clone git://git.kernel.org/pub/scm/git/git.git 了。) 为简单起见,在接下来的例子(及本书随后的所有演示)中,我都不会用这种格式,而使用 -m 选项提交 git commit 。不过 请还是按照我之前讲的做,别学我这里偷懒的方式。 我们从最简单的情况开始,一个私有项目,与你一起协作的还有另外一到两位开发者。这里说私有,是指源代码不公开,其 他人无法访问项目仓库。而你和其他开发者则都具有推送数据到仓库的权限。 这种情况下,你们可以用 Subversion 或其他集中式版本控制系统类似的工作流来协作。你仍然可以得到 Git 带来的其他好 处:离线提交,快速分支与合并等等,但工作流程还是差不多的。主要区别在于,合并操作发生在客户端而非服务器上。 让 我们来看看,两个开发者一起使用同一个共享仓库,会发生些什么。第一个人,John,克隆了仓库,作了些更新,在本地提 交。(下面的例子中省略了常规提示,用 ... 代替以节约版面。) # John's Machine $ git clone john@githost:simplegit.git Initialized empty Git repository in /home/john/simplegit/.git/ ... $ cd simplegit/ $ vim lib/simplegit.rb $ git commit -am 'removed invalid default value' [master 738ee87] removed invalid default value 1 files changed, 1 insertions(+), 1 deletions(-) 第二个开发者,Jessica,一样这么做:克隆仓库,提交更新: # Jessica's Machine $ git clone jessica@githost:simplegit.git Initialized empty Git repository in /home/jessica/simplegit/.git/ ... $ cd simplegit/ $ vim TODO $ git commit -am 'add reset task' [master fbff5bc] add reset task 1 files changed, 1 insertions(+), 0 deletions(-) 现在,Jessica 将她的工作推送到服务器上: # Jessica's Machine $ git push origin master ... To jessica@githost:simplegit.git 1edee6b..fbff5bc master -> master 私有的小型团队 John 也尝试推送自己的工作上去: # John's Machine $ git push origin master To john@githost:simplegit.git ! [rejected] master -> master (non-fast forward) error: failed to push some refs to 'john@githost:simplegit.git' John 的推送操作被驳回,因为 Jessica 已经推送了新的数据上去。请注意,特别是你用惯了 Subversion 的话,这里其实修 改的是两个文件,而不是同一个文件的同一个地方。Subversion 会在服务器端自动合并提交上来的更新,而 Git 则必须先在 本地合并后才能推送。于是,John 不得不先把 Jessica 的更新拉下来: $ git fetch origin ... From john@githost:simplegit + 049d078...fbff5bc master -> origin/master 此刻,John 的本地仓库如图 5-4 所示: 图 5-4. John 的仓库历史 虽然 John 下载了 Jessica 推送到服务器的最近更新(fbff5),但目前只是 origin/master 指针指向它,而当前的本地分支 master 仍然指向自己的更新(738ee),所以需要先把她的提交合并过来,才能继续推送数据: $ git merge origin/master Merge made by recursive. TODO | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) 还好,合并过程非常顺利,没有冲突,现在 John 的提交历史如图 5-5 所示: 图 5-5. 合并 origin/master 后 John 的仓库历史 现在,John 应该再测试一下代码是否仍然正常工作,然后将合并结果(72bbc)推送到服务器上: $ git push origin master ... To john@githost:simplegit.git fbff5bc..72bbc59 master -> master 最终,John 的提交历史变为图 5-6 所示: 图 5-6. 推送后 John 的仓库历史 而在这段时间,Jessica 已经开始在另一个特性分支工作了。她创建了 issue54 并提交了三次更新。她还没有下载 John 提交 的合并结果,所以提交历史如图 5-7 所示: 图 5-7. Jessica 的提交历史 Jessica 想要先和服务器上的数据同步,所以先下载数据: # Jessica's Machine $ git fetch origin ... From jessica@githost:simplegit fbff5bc..72bbc59 master -> origin/master 于是 Jessica 的本地仓库历史多出了 John 的两次提交(738ee 和 72bbc),如图 5-8 所示: 图 5-8. 获取 John 的更新之后 Jessica 的提交历史 此时,Jessica 在特性分支上的工作已经完成,但她想在推送数据之前,先确认下要并进来的数据究竟是什么,于是运行 git log 查看: $ git log --no-merges origin/master ^issue54 commit 738ee872852dfaa9d6634e0dea7a324040193016 Author: John Smith Date: Fri May 29 16:01:27 2009 -0700 removed invalid default value 现在,Jessica 可以将特性分支上的工作并到 master 分支,然后再并入 John 的工作( origin/master )到自己的 master 分 支,最后再推送回服务器。当然,得先切回主分支才能集成所有数据: $ git checkout master Switched to branch "master" Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. 要合并 origin/master 或 issue54 分支,谁先谁后都没有关系,因为它们都在上游(upstream)(译注:想像分叉的更新像 是汇流成河的源头,所以上游 upstream 是指最新的提交),所以无所谓先后顺序,最终合并后的内容快照都是一样的,而 仅是提交历史看起来会有些先后差别。Jessica 选择先合并 issue54 : $ git merge issue54 Updating fbff5bc..4af4298 Fast forward README | 1 + lib/simplegit.rb | 6 +++++- 2 files changed, 6 insertions(+), 1 deletions(-) 正如所见,没有冲突发生,仅是一次简单快进。现在 Jessica 开始合并 John 的工作( origin/master ): $ git merge origin/master Auto-merging lib/simplegit.rb Merge made by recursive. lib/simplegit.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) 所有的合并都非常干净。现在 Jessica 的提交历史如图 5-9 所示: 图 5-9. 合并 John 的更新后 Jessica 的提交历史 现在 Jessica 已经可以在自己的 master 分支中访问 origin/master 的最新改动了,所以她应该可以成功推送最后的合并结果 到服务器上(假设 John 此时没再推送新数据上来): $ git push origin master ... To jessica@githost:simplegit.git 72bbc59..8059c15 master -> master 至此,每个开发者都提交了若干次,且成功合并了对方的工作成果,最新的提交历史如图 5-10 所示: 图 5-10. Jessica 推送数据后的提交历史 以上就是最简单的协作方式之一:先在自己的特性分支中工作一段时间,完成后合并到自己的 master 分支;然后下载合并 origin/master 上的更新(如果有的话),再推回远程服务器。一般的协作流程如图 5-11 所示: 图 5-11. 多用户共享仓库协作方式的一般工作流程时序 现在我们来看更大一点规模的私有团队协作。如果有几个小组分头负责若干特性的开发和集成,那他们之间的协作过程是怎 样的。 假设 John 和 Jessica 一起负责开发某项特性 A,而同时 Jessica 和 Josie 一起负责开发另一项功能 B。公司使用典型的集成 管理员式工作流,每个组都有一名管理员负责集成本组代码,及更新项目主仓库的 master 分支。所有开发都在代表小组的 分支上进行。 让我们跟随 Jessica 的视角看看她的工作流程。她参与开发两项特性,同时和不同小组的开发者一起协作。克隆生成本地仓 库后,她打算先着手开发特性 A。于是创建了新的 featureA 分支,继而编写代码: # Jessica's Machine $ git checkout -b featureA Switched to a new branch "featureA" $ vim lib/simplegit.rb $ git commit -am 'add limit to log function' [featureA 3300904] add limit to log function 1 files changed, 1 insertions(+), 1 deletions(-) 此刻,她需要分享目前的进展给 John,于是她将自己的 featureA 分支提交到服务器。由于 Jessica 没有权限推送数据到主 仓库的 master 分支(只有集成管理员有此权限),所以只能将此分支推上去同 John 共享协作: $ git push origin featureA ... To jessica@githost:simplegit.git * [new branch] featureA -> featureA 私有团队间协作 Jessica 发邮件给 John 让他上来看看 featureA 分支上的进展。在等待他的反馈之前,Jessica 决定继续工作,和 Josie 一起 开发 featureB 上的特性 B。当然,先创建此分支,分叉点以服务器上的 master 为起点: # Jessica's Machine $ git fetch origin $ git checkout -b featureB origin/master Switched to a new branch "featureB" 随后,Jessica 在 featureB 上提交了若干更新: $ vim lib/simplegit.rb $ git commit -am 'made the ls-tree function recursive' [featureB e5b0fdc] made the ls-tree function recursive 1 files changed, 1 insertions(+), 1 deletions(-) $ vim lib/simplegit.rb $ git commit -am 'add ls-files' [featureB 8512791] add ls-files 1 files changed, 5 insertions(+), 0 deletions(-) 现在 Jessica 的更新历史如图 5-12 所示: 图 5-12. Jessica 的更新历史 Jessica 正准备推送自己的进展上去,却收到 Josie 的来信,说是她已经将自己的工作推到服务器上的 featureBee 分支了。 这样,Jessica 就必须先将 Josie 的代码合并到自己本地分支中,才能再一起推送回服务器。她用 git fetch 下载 Josie 的最 新代码: $ git fetch origin ... From jessica@githost:simplegit * [new branch] featureBee -> origin/featureBee 然后 Jessica 使用 git merge 将此分支合并到自己分支中: $ git merge origin/featureBee Auto-merging lib/simplegit.rb Merge made by recursive. lib/simplegit.rb | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) 合并很顺利,但另外有个小问题:她要推送自己的 featureB 分支到服务器上的 featureBee 分支上去。当然,她可以使用冒 号(:)格式指定目标分支: $ git push origin featureB:featureBee ... To jessica@githost:simplegit.git fba9af8..cd685d1 featureB -> featureBee 我们称此为refspec。更多有关于 Git refspec 的讨论和使用方式会在第九章作详细阐述。 接下来,John 发邮件给 Jessica 告诉她,他看了之后作了些修改,已经推回服务器 featureA 分支,请她过目下。于是 Jessica 运行 git fetch 下载最新数据: $ git fetch origin ... From jessica@githost:simplegit 3300904..aad881d featureA -> origin/featureA 接下来便可以用 git log 查看更新了些什么: $ git log origin/featureA ^featureA commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6 Author: John Smith Date: Fri May 29 19:57:33 2009 -0700 changed log output to 30 from 25 最后,她将 John 的工作合并到自己的 featureA 分支中: $ git checkout featureA Switched to branch "featureA" $ git merge origin/featureA Updating 3300904..aad881d Fast forward lib/simplegit.rb | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) Jessica 稍做一番修整后同步到服务器: $ git commit -am 'small tweak' [featureA 774b3ed] small tweak 1 files changed, 1 insertions(+), 1 deletions(-) $ git push origin featureA ... To jessica@githost:simplegit.git 3300904..774b3ed featureA -> featureA 现在的 Jessica 提交历史如图 5-13 所示: 图 5-13. 在特性分支中提交更新后的提交历史 现在,Jessica,Josie 和 John 通知集成管理员服务器上的 featureA 及 featureBee 分支已经准备好,可以并入主线了。在 管理员完成集成工作后,主分支上便多出一个新的合并提交(5399e),用 fetch 命令更新到本地后,提交历史如图 5-14 所 示: 图 5-14. 合并特性分支后的 Jessica 提交历史 许多开发小组改用 Git 就是因为它允许多个小组间并行工作,而在稍后恰当时机再行合并。通过共享远程分支的方式,无需 干扰整体项目代码便可以开展工作,因此使用 Git 的小型团队间协作可以变得非常灵活自由。以上工作流程的时序如图 5-15 所示: 图 5-15. 团队间协作工作流程基本时序 上面说的是私有项目协作,但要给公开项目作贡献,情况就有些不同了。因为你没有直接更新主仓库分支的权限,得寻求其 它方式把工作成果交给项目维护人。下面会介绍两种方法,第一种使用 git 托管服务商提供的仓库复制功能,一般称作 fork, 比如 repo.or.cz 和 GitHub 都支持这样的操作,而且许多项目管理员都希望大家使用这样的方式。另一种方法是通过电子邮 件寄送文件补丁。 但不管哪种方式,起先我们总需要克隆原始仓库,而后创建特性分支开展工作。基本工作流程如下: $ git clone (url) $ cd project $ git checkout -b featureA $ (work) $ git commit $ (work) $ git commit 你可能想到用 rebase -i 将所有更新先变作单个提交,又或者想重新安排提交之间的差异补丁,以方便项目维护者审阅 -- 有 关交互式衍合操作的细节见第六章。 在完成了特性分支开发,提交给项目维护者之前,先到原始项目的页面上点击“Fork”按钮,创建一个自己可写的公共仓库 (译注:即下面的 url 部分,参照后续的例子,应该是 git://githost/simplegit.git )。然后将此仓库添加为本地的第二个远端仓 库,姑且称为 myfork : 公开的小型项目 $ git remote add myfork (url) 你需要将本地更新推送到这个仓库。要是将远端 master 合并到本地再推回去,还不如把整个特性分支推上去来得干脆直接。 而且,假若项目维护者未采纳你的贡献的话(不管是直接合并还是 cherry pick),都不用回退(rewind)自己的 master 分 支。但若维护者合并或 cherry-pick 了你的工作,最后总还可以从他们的更新中同步这些代码。好吧,现在先把 featureA 分 支整个推上去: $ git push myfork featureA 然后通知项目管理员,让他来抓取你的代码。通常我们把这件事叫做 pull request。可以直接用 GitHub 等网站提供的 “pull request” 按钮自动发送请求通知;或手工把 git request-pull 命令输出结果电邮给项目管理员。 request-pull 命令接受两个参数,第一个是本地特性分支开始前的原始分支,第二个是请求对方来抓取的 Git 仓库 URL(译 注:即下面 myfork 所指的,自己可写的公共仓库)。比如现在Jessica 准备要给 John 发一个 pull requst,她之前在自己的 特性分支上提交了两次更新,并把分支整个推到了服务器上,所以运行该命令会看到: $ git request-pull origin/master myfork The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40: John Smith (1): added a new function are available in the git repository at: git://githost/simplegit.git featureA Jessica Smith (2): add limit to log function change log output to 30 from 25 lib/simplegit.rb | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) 输出的内容可以直接发邮件给管理者,他们就会明白这是从哪次提交开始旁支出去的,该到哪里去抓取新的代码,以及新的 代码增加了哪些功能等等。 像这样随时保持自己的 master 分支和官方 origin/master 同步,并将自己的工作限制在特性分支上的做法,既方便又灵活, 采纳和丢弃都轻而易举。就算原始主干发生变化,我们也能重新衍合提供新的补丁。比如现在要开始第二项特性的开发,不 要在原来已推送的特性分支上继续,还是按原始 master 开始: $ git checkout -b featureB origin/master $ (work) $ git commit $ git push myfork featureB $ (email maintainer) $ git fetch origin 现在,A、B 两个特性分支各不相扰,如同竹筒里的两颗豆子,队列中的两个补丁,你随时都可以分别从头写过,或者衍合, 或者修改,而不用担心特性代码的交叉混杂。如图 5-16 所示: 图 5-16. featureB 以后的提交历史 假设项目管理员接纳了许多别人提交的补丁后,准备要采纳你提交的第一个分支,却发现因为代码基准不一致,合并工作无 法正确干净地完成。这就需要你再次衍合到最新的 origin/master ,解决相关冲突,然后重新提交你的修改: $ git checkout featureA $ git rebase origin/master $ git push -f myfork featureA 自然,这会重写提交历史,如图 5-17 所示: 图 5-17. featureA 重新衍合后的提交历史 注意,此时推送分支必须使用 -f 选项(译注:表示 force,不作检查强制重写)替换远程已有的 featureA 分支,因为新的 commit 并非原来的后续更新。当然你也可以直接推送到另一个新的分支上去,比如称作 featureAv2 。 再考虑另一种情形:管理员看过第二个分支后觉得思路新颖,但想请你改下具体实现。我们只需以当前 origin/master 分支为 基准,开始一个新的特性分支 featureBv2 ,然后把原来的 featureB 的更新拿过来,解决冲突,按要求重新实现部分代码,然 后将此特性分支推送上去: $ git checkout -b featureBv2 origin/master $ git merge --no-commit --squash featureB $ (change implementation) $ git commit $ git push myfork featureBv2 这里的 --squash 选项将目标分支上的所有更改全拿来应用到当前分支上,而 --no-commit 选项告诉 Git 此时无需自动生成和 记录(合并)提交。这样,你就可以在原来代码基础上,继续工作,直到最后一起提交。 好了,现在可以请管理员抓取 featureBv2 上的最新代码了,如图 5-18 所示: 图 5-18. featureBv2 之后的提交历史 许多大型项目都会立有一套自己的接受补丁流程,你应该注意下其中细节。但多数项目都允许通过开发者邮件列表接受补 丁,现在我们来看具体例子。 整个工作流程类似上面的情形:为每个补丁创建独立的特性分支,而不同之处在于如何提交这些补丁。不需要创建自己可写 的公共仓库,也不用将自己的更新推送到自己的服务器,你只需将每次提交的差异内容以电子邮件的方式依次发送到邮件列 表中即可。 $ git checkout -b topicA $ (work) $ git commit $ (work) $ git commit 如此一番后,有了两个提交要发到邮件列表。我们可以用 git format-patch 命令来生成 mbox 格式的文件然后作为附件发送。 每个提交都会封装为一个 .patch 后缀的 mbox 文件,但其中只包含一封邮件,邮件标题就是提交消息(译注:额外有前缀, 看例子),邮件内容包含补丁正文和 Git 版本号。这种方式的妙处在于接受补丁时仍可保留原来的提交消息,请看接下来的 例子: $ git format-patch -M origin/master 0001-add-limit-to-log-function.patch 0002-changed-log-output-to-30-from-25.patch format-patch 命令依次创建补丁文件,并输出文件名。上面的 -M 选项允许 Git 检查是否有对文件重命名的提交。我们来看看 补丁文件的内容: 公开的大型项目 $ cat 0001-add-limit-to-log-function.patch From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001 From: Jessica Smith Date: Sun, 6 Apr 2008 10:17:23 -0700 Subject: [PATCH 1/2] add limit to log function Limit log functionality to the first 20 --- lib/simplegit.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/simplegit.rb b/lib/simplegit.rb index 76f47bc..f9815f1 100644 --- a/lib/simplegit.rb +++ b/lib/simplegit.rb @@ -14,7 +14,7 @@ class SimpleGit end def log(treeish = 'master') - command("git log #{treeish}") + command("git log -n 20 #{treeish}") end def ls_tree(treeish = 'master') -- 1.6.2.rc1.20.g8c5b.dirty 如果有额外信息需要补充,但又不想放在提交消息中说明,可以编辑这些补丁文件,在第一个 --- 行之前添加说明,但不要 修改下面的补丁正文,比如例子中的 Limit log functionality to the first 20 部分。这样,其它开发者能阅读,但在采纳补丁时不 会将此合并进来。 你可以用邮件客户端软件发送这些补丁文件,也可以直接在命令行发送。有些所谓智能的邮件客户端软件会自作主张帮你调 整格式,所以粘贴补丁到邮件正文时,有可能会丢失换行符和若干空格。Git 提供了一个通过 IMAP 发送补丁文件的工具。接 下来我会演示如何通过 Gmail 的 IMAP 服务器发送。另外,在 Git 源代码中有个 Documentation/SubmittingPatches 文件,可 以仔细读读,看看其它邮件程序的相关导引。 首先在 ~/.gitconfig 文件中配置 imap 项。每个选项都可用 git config 命令分别设置,当然直接编辑文件添加以下内容更便 捷: [imap] folder = "[Gmail]/Drafts" host = imaps://imap.gmail.com user = user@gmail.com pass = p4ssw0rd port = 993 sslverify = false 如果你的 IMAP 服务器没有启用 SSL,就无需配置最后那两行,并且 host 应该以 imap:// 开头而不再是有 s 的 imaps:// 。 保存配置文件后,就能用 git send-email 命令把补丁作为邮件依次发送到指定的 IMAP 服务器上的文件夹中(译注:这里就 是 Gmail 的 [Gmail]/Drafts 文件夹。但如果你的语言设置不是英文,此处的文件夹 Drafts 字样会变为对应的语言。): $ cat *.patch |git imap-send Resolving imap.gmail.com... ok Connecting to [74.125.142.109]:993... ok Logging in... sending 2 messages 100% (2/2) done At this point, you should be able to go to your Drafts folder, change the To field to the mailing list you’re sending the patch to, possibly CC the maintainer or person responsible for that section, and send it off. You can also send the patches through an SMTP server. As before, you can set each value separately with a series of git config commands, or you can add them manually in the sendemail section in your ~/.gitconfig file: [sendemail] smtpencryption = tls smtpserver = smtp.gmail.com smtpuser = user@gmail.com smtpserverport = 587 After this is done, you can use git send-email to send your patches: $ git send-email *.patch 0001-added-limit-to-log-function.patch 0002-changed-log-output-to-30-from-25.patch Who should the emails appear to be from? [Jessica Smith ] Emails will be sent from: Jessica Smith Who should the emails be sent to? jessica@example.com Message-ID to be used as In-Reply-To for the first email? y 接下来,Git 会根据每个补丁依次输出类似下面的日志: (mbox) Adding cc: Jessica Smith from \line 'From: Jessica Smith ' OK. Log says: Sendmail: /usr/sbin/sendmail -i jessica@example.com From: Jessica Smith To: jessica@example.com Subject: [PATCH 1/2] added limit to log function Date: Sat, 30 May 2009 13:29:15 -0700 Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com> X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty In-Reply-To: References: Result: OK 本节主要介绍了常见 Git 项目协作的工作流程,还有一些帮助处理这些工作的命令和工具。接下来我们要看看如何维护 Git 项 目,并成为一个合格的项目管理员,或是集成经理。 小结 既然是相互协作,在贡献代码的同时,也免不了要维护管理自己的项目。像是怎么处理别人用 format-patch 生成的补丁,或 是集成远端仓库上某个分支上的变化等等。但无论是管理代码仓库,还是帮忙审核收到的补丁,都需要同贡献者约定某种长 期可持续的工作方式。 如果想要集成新的代码进来,最好局限在特性分支上做。临时的特性分支可以让你随意尝试,进退自如。比如碰上无法正常 工作的补丁,可以先搁在那边,直到有时间仔细核查修复为止。创建的分支可以用相关的主题关键字命名,比如 ruby_client 或者其它类似的描述性词语,以帮助将来回忆。Git 项目本身还时常把分支名称分置于不同命名空间下,比如 sc/ruby_client 就说明这是 sc 这个人贡献的。 现在从当前主干分支为基础,新建临时分支: $ git branch sc/ruby_client master 另外,如果你希望立即转到分支上去工作,可以用 checkout -b : $ git checkout -b sc/ruby_client master 好了,现在已经准备妥当,可以试着将别人贡献的代码合并进来了。之后评估一下有没有问题,最后再决定是不是真的要并 入主干。 如果收到一个通过电邮发来的补丁,你应该先把它应用到特性分支上进行评估。有两种应用补丁的方法: git apply 或者 git am 。 如果收到的补丁文件是用 git diff 或由其它 Unix 的 diff 命令生成,就该用 git apply 命令来应用补丁。假设补丁文件存在 /tmp/patch-ruby-client.patch ,可以这样运行: $ git apply /tmp/patch-ruby-client.patch 这会修改当前工作目录下的文件,效果基本与运行 patch -p1 打补丁一样,但它更为严格,且不会出现混乱。如果是 git diff 格式描述的补丁,此命令还会相应地添加,删除,重命名文件。当然,普通的 patch 命令是不会这么做的。另外请注意, git apply 是一个事务性操作的命令,也就是说,要么所有补丁都打上去,要么全部放弃。所以不会出现 patch 命令那样,一部 分文件打上了补丁而另一部分却没有,这样一种不上不下的修订状态。所以总的来说, git apply 要比 patch 严谨许多。因为 仅仅是更新当前的文件,所以此命令不会自动生成提交对象,你得手工缓存相应文件的更新状态并执行提交命令。 在实际打补丁之前,可以先用 git apply --check 查看补丁是否能够干净顺利地应用到当前分支中: $ git apply --check 0001-seeing-if-this-helps-the-gem.patch error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply 如果没有任何输出,表示我们可以顺利采纳该补丁。如果有问题,除了报告错误信息之外,该命令还会返回一个非零的状 态,所以在 shell 脚本里可用于检测状态。 项目的管理 使用特性分支进行工作 采纳来自邮件的补丁 使用 apply 命令应用补丁 使用 am 命令应用补丁 如果贡献者也用 Git,且擅于制作 format-patch 补丁,那你的合并工作将会非常轻松。因为这些补丁中除了文件内容差异 外,还包含了作者信息和提交消息。所以请鼓励贡献者用 format-patch 生成补丁。对于传统的 diff 命令生成的补丁,则只能 用 git apply 处理。 对于 format-patch 制作的新式补丁,应当使用 git am 命令。从技术上来说, git am 能够读取 mbox 格式的文件。这是种简 单的纯文本文件,可以包含多封电邮,格式上用 From 加空格以及随便什么辅助信息所组成的行作为分隔行,以区分每封邮 件,就像这样: From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001 From: Jessica Smith Date: Sun, 6 Apr 2008 10:17:23 -0700 Subject: [PATCH 1/2] add limit to log function Limit log functionality to the first 20 这是 format-patch 命令输出的开头几行,也是一个有效的 mbox 文件格式。如果有人用 git send-email 给你发了一个补丁, 你可以将此邮件下载到本地,然后运行 git am 命令来应用这个补丁。如果你的邮件客户端能将多封电邮导出为 mbox 格式的 文件,就可以用 git am 一次性应用所有导出的补丁。 如果贡献者将 format-patch 生成的补丁文件上传到类似 Request Ticket 一样的任务处理系统,那么可以先下载到本地,继而 使用 git am 应用该补丁: $ git am 0001-limit-log-function.patch Applying: add limit to log function 你会看到它被干净地应用到本地分支,并自动创建了新的提交对象。作者信息取自邮件头 From 和 Date ,提交消息则取自 Subject 以及正文中补丁之前的内容。来看具体实例,采纳之前展示的那个 mbox 电邮补丁后,最新的提交对象为: $ git log --pretty=fuller -1 commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0 Author: Jessica Smith AuthorDate: Sun Apr 6 10:17:23 2008 -0700 Commit: Scott Chacon CommitDate: Thu Apr 9 09:19:06 2009 -0700 add limit to log function Limit log functionality to the first 20 Commit 部分显示的是采纳补丁的人,以及采纳的时间。而 Author 部分则显示的是原作者,以及创建补丁的时间。 有时,我们也会遇到打不上补丁的情况。这多半是因为主干分支和补丁的基础分支相差太远,但也可能是因为某些依赖补丁 还未应用。这种情况下, git am 会报错并询问该怎么做: $ git am 0001-seeing-if-this-helps-the-gem.patch Applying: seeing if this helps the gem error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply Patch failed at 0001. When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". Git 会在有冲突的文件里加入冲突解决标记,这同合并或衍合操作一样。解决的办法也一样,先编辑文件消除冲突,然后暂存 文件,最后运行 git am --resolved 提交修正结果: $ (fix the file) $ git add ticgit.gemspec $ git am --resolved Applying: seeing if this helps the gem 如果想让 Git 更智能地处理冲突,可以用 -3 选项进行三方合并。如果当前分支未包含该补丁的基础代码或其祖先,那么三方 合并就会失败,所以该选项默认为关闭状态。一般来说,如果该补丁是基于某个公开的提交制作而成的话,你总是可以通过 同步来获取这个共同祖先,所以用三方合并选项可以解决很多麻烦: $ git am -3 0001-seeing-if-this-helps-the-gem.patch Applying: seeing if this helps the gem error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... No changes -- Patch already applied. 像上面的例子,对于打过的补丁我又再打一遍,自然会产生冲突,但因为加上了 -3 选项,所以它很聪明地告诉我,无需更 新,原有的补丁已经应用。 对于一次应用多个补丁时所用的 mbox 格式文件,可以用 am 命令的交互模式选项 -i ,这样就会在打每个补丁前停住,询问 该如何操作: $ git am -3 -i mbox Commit Body is: -------------------------- seeing if this helps the gem -------------------------- Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all 在多个补丁要打的情况下,这是个非常好的办法,一方面可以预览下补丁内容,同时也可以有选择性的接纳或跳过某些补 丁。 打完所有补丁后,如果测试下来新特性可以正常工作,那就可以安心地将当前特性分支合并到长期分支中去了。 如果贡献者有自己的 Git 仓库,并将修改推送到此仓库中,那么当你拿到仓库的访问地址和对应分支的名称后,就可以加为 远程分支,然后在本地进行合并。 比如,Jessica 发来一封邮件,说在她代码库中的 ruby-client 分支上已经实现了某个非常棒的新功能,希望我们能帮忙测试 一下。我们可以先把她的仓库加为远程仓库,然后抓取数据,完了再将她所说的分支检出到本地来测试: $ git remote add jessica git://github.com/jessica/myproject.git $ git fetch jessica $ git checkout -b rubyclient jessica/ruby-client 若是不久她又发来邮件,说还有个很棒的功能实现在另一分支上,那我们只需重新抓取下最新数据,然后检出那个分支到本 地就可以了,无需重复设置远程仓库。 这种做法便于同别人保持长期的合作关系。但前提是要求贡献者有自己的服务器,而我们也需要为每个人建一个远程分支。 有些贡献者提交代码补丁并不是很频繁,所以通过邮件接收补丁效率会更高。同时我们自己也不会希望建上百来个分支,却 只从每个分支取一两个补丁。但若是用脚本程序来管理,或直接使用代码仓库托管服务,就可以简化此过程。当然,选择何 种方式取决于你和贡献者的喜好。 使用远程分支的另外一个好处是能够得到提交历史。不管代码合并是不是会有问题,至少我们知道该分支的历史分叉点,所 以默认会从共同祖先开始自动进行三方合并,无需 -3 选项,也不用像打补丁那样祈祷存在共同的基准点。 检出远程分支 如果只是临时合作,只需用 git pull 命令抓取远程仓库上的数据,合并到本地临时分支就可以了。一次性的抓取动作自然不 会把该仓库地址加为远程仓库。 $ git pull git://github.com/onetimeguy/project.git From git://github.com/onetimeguy/project * branch HEAD -> FETCH_HEAD Merge made by recursive. 现在特性分支上已合并好了贡献者的代码,是时候决断取舍了。本节将回顾一些之前学过的命令,以看清将要合并到主干的 是哪些代码,从而理解它们到底做了些什么,是否真的要并入。 一般我们会先看下,特性分支上都有哪些新增的提交。比如在 contrib 特性分支上打了两个补丁,仅查看这两个补丁的提交 信息,可以用 --not 选项指定要屏蔽的分支 master ,这样就会剔除重复的提交历史: $ git log contrib --not master commit 5b6235bd297351589efc4d73316f0a68d484f118 Author: Scott Chacon Date: Fri Oct 24 09:53:59 2008 -0700 seeing if this helps the gem commit 7482e0d16d04bea79d0dba8988cc78df655f16a0 Author: Scott Chacon Date: Mon Oct 22 19:38:36 2008 -0700 updated the gemspec to hopefully work better 还可以查看每次提交的具体修改。请牢记,在 git log 后加 -p 选项将展示每次提交的内容差异。 如果想看当前分支同其他分支合并时的完整内容差异,有个小窍门: $ git diff master 虽然能得到差异内容,但请记住,结果有可能和我们的预期不同。一旦主干 master 在特性分支创建之后有所修改,那么通 过 diff 命令来比较的,是最新主干上的提交快照。显然,这不是我们所要的。比方在 master 分支中某个文件里添了一行, 然后运行上面的命令,简单的比较最新快照所得到的结论只能是,特性分支中删除了这一行。 这个很好理解:如果 master 是特性分支的直接祖先,不会产生任何问题;如果它们的提交历史在不同的分叉上,那么产生 的内容差异,看起来就像是增加了特性分支上的新代码,同时删除了 master 分支上的新代码。 实际上我们真正想要看的,是新加入到特性分支的代码,也就是合并时会并入主干的代码。所以,准确地讲,我们应该比较 特性分支和它同 master 分支的共同祖先之间的差异。 我们可以手工定位它们的共同祖先,然后与之比较: $ git merge-base contrib master 36c7dba2c95e6bbb78dfa822519ecfec6e1ca649 $ git diff 36c7db 但这么做很麻烦,所以 Git 提供了便捷的 ... 语法。对于 diff 命令,可以把 ... 加在原始分支(拥有共同祖先)和当前分支之 间: $ git diff master...contrib 决断代码取舍 现在看到的,就是实际将要引入的新代码。这是一个非常有用的命令,应该牢记。 一旦特性分支准备停当,接下来的问题就是如何集成到更靠近主线的分支中。此外还要考虑维护项目的总体步骤是什么。虽 然有很多选择,不过我们这里只介绍其中一部分。 一般最简单的情形,是在 master 分支中维护稳定代码,然后在特性分支上开发新功能,或是审核测试别人贡献的代码,接 着将它并入主干,最后删除这个特性分支,如此反复。来看示例,假设当前代码库中有两个分支,分别为 ruby_client 和 php_client ,如图 5-19 所示。然后先把 ruby_client 合并进主干,再合并 php_client ,最后的提交历史如图 5-20 所示。 图 5-19. 多个特性分支 代码集成 合并流程 图 5-20. 合并特性分支之后 这是最简单的流程,所以在处理大一些的项目时可能会有问题。 对于大型项目,至少需要维护两个长期分支 master 和 develop 。新代码(图 5-21 中的 ruby_client )将首先并入 develop 分支(图 5-22 中的 C8 ),经过一个阶段,确认 develop 中的代码已稳定到可发行时,再将 master 分支快进到稳定点(图 5-23 中的 C8 )。而平时这两个分支都会被推送到公开的代码库。 图 5-21. 特性分支合并前 图 5-22. 特性分支合并后 图 5-23. 特性分支发布后 这样,在人们克隆仓库时就有两种选择:既可检出最新稳定版本,确保正常使用;也能检出开发版本,试用最前沿的新特 性。 你也可以扩展这个概念,先将所有新代码合并到临时特性分支,等到该分支稳定下来并通过测试后,再并入 develop 分 支。然后,让时间检验一切,如果这些代码确实可以正常工作相当长一段时间,那就有理由相信它已经足够稳定,可以放心 并入主干分支发布。 Git 项目本身有四个长期分支:用于发布的 master 分支、用于合并基本稳定特性的 next 分支、用于合并仍需改进特性的 pu 分支(pu 是 proposed updates 的缩写),以及用于除错维护的 maint 分支(maint 取自 maintenance)。维护者可以 按照之前介绍的方法,将贡献者的代码引入为不同的特性分支(如图 5-24 所示),然后测试评估,看哪些特性能稳定工作, 哪些还需改进。稳定的特性可以并入 next 分支,然后再推送到公共仓库,以供其他人试用。 大项目的合并流程 图 5-24. 管理复杂的并行贡献 仍需改进的特性可以先并入 pu 分支。直到它们完全稳定后再并入 master 。同时一并检查下 next 分支,将足够稳定的特性 也并入 master 。所以一般来说, master 始终是在快进, next 偶尔做下衍合,而 pu 则是频繁衍合,如图 5-25 所示: 图 5-25. 将特性并入长期分支 并入 master 后的特性分支,已经无需保留分支索引,放心删除好了。Git 项目还有一个 maint 分支,它是以最近一次发行 版为基础分化而来的,用于维护除错补丁。所以克隆 Git 项目仓库后会得到这四个分支,通过检出不同分支可以了解各自进 展,或是试用前沿特性,或是贡献代码。而维护者则通过管理这些分支,逐步有序地并入第三方贡献。 一些维护者更喜欢衍合或者挑拣贡献者的代码,而不是简单的合并,因为这样能够保持线性的提交历史。如果你完成了一个 特性的开发,并决定将它引入到主干代码中,你可以转到那个特性分支然后执行衍合命令,好在你的主干分支上(也可能 是 develop 分支之类的)重新提交这些修改。如果这些代码工作得很好,你就可以快进 master 分支,得到一个线性的提交历 史。 另一个引入代码的方法是挑拣。挑拣类似于针对某次特定提交的衍合。它首先提取某次提交的补丁,然后试着应用在当前分 支上。如果某个特性分支上有多个commits,但你只想引入其中之一就可以使用这种方法。也可能仅仅是因为你喜欢用挑 拣,讨厌衍合。假设你有一个类似图 5-26 的工程。 衍合与挑拣(cherry-pick)的流程 图 5-26. 挑拣(cherry-pick)之前的历史 如果你希望拉取 e43a6 到你的主干分支,可以这样: $ git cherry-pick e43a6fd3e94888d76779ad79fb568ed180e5fcdf Finished one cherry-pick. [master]: created a0a41a9: "More friendly message when locking the index fails." 3 files changed, 17 insertions(+), 3 deletions(-) 这将会引入 e43a6 的代码,但是会得到不同的SHA-1值,因为应用日期不同。现在你的历史看起来像图 5-27. 图 5-27. 挑拣(cherry-pick)之后的历史 现在,你可以删除这个特性分支并丢弃你不想引入的那些commit。 你可以删除上次发布的版本并重新打标签,也可以像第二章所说的那样建立一个新的标签。如果你决定以维护者的身份给发 行版签名,应该这样做: 给发行版签名 $ git tag -s v1.5 -m 'my signed 1.5 tag' You need a passphrase to unlock the secret key for user: "Scott Chacon " 1024-bit DSA key, ID F721C45A, created 2009-02-09 完成签名之后,如何分发PGP公钥(public key)是个问题。(译者注:分发公钥是为了验证标签)。还好,Git的设计者想 到了解决办法:可以把key(既公钥)作为blob变量写入Git库,然后把它的内容直接写在标签里。 gpg --list-keys 命令可以显 示出你所拥有的key: $ gpg --list-keys /Users/schacon/.gnupg/pubring.gpg --------------------------------- pub 1024D/F721C45A 2009-02-09 [expires: 2010-02-09] uid Scott Chacon sub 2048g/45D02282 2009-02-09 [expires: 2010-02-09] 然后,导出key的内容并经由管道符传递给 git hash-object ,之后钥匙会以blob类型写入Git中,最后返回这个blob量的SHA-1 值: $ gpg -a --export F721C45A | git hash-object -w --stdin 659ef797d181633c87ec71ac3f9ba29fe5775b92 现在你的Git已经包含了这个key的内容了,可以通过不同的SHA-1值指定不同的key来创建标签。 $ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92 在运行 git push --tags 命令之后, maintainer-pgp-pub 标签就会公布给所有人。如果有人想要校验标签,他可以使用如下命令 导入你的key: $ git show maintainer-pgp-pub | gpg --import 人们可以用这个key校验你签名的所有标签。另外,你也可以在标签信息里写入一个操作向导,用户只需要运行 git show 查看标签信息,然后按照你的向导就能完成校验。 因为Git不会为每次提交自动附加类似'v123'的递增序列,所以如果你想要得到一个便于理解的提交号可以运行 git describe 命 令。Git将会返回一个字符串,由三部分组成:最近一次标定的版本号,加上自那次标定之后的提交次数,再加上一段所描述 的提交的SHA-1值: $ git describe master v1.6.2-rc1-20-g8c5b85c 这个字符串可以作为快照的名字,方便人们理解。如果你的Git是你自己下载源码然后编译安装的,你会发现 git --version 命令 的输出和这个字符串差不多。如果在一个刚刚打完标签的提交上运行 describe 命令,只会得到这次标定的版本号,而没有后 面两项信息。 git describe 命令只适用于有标注的标签(通过 -a 或者 -s 选项创建的标签),所以发行版的标签都应该是带有标注的,以保 证 git describe 能够正确的执行。你也可以把这个字符串作为 checkout 或者 show 命令的目标,因为他们最终都依赖于一个简 短的SHA-1值,当然如果这个SHA-1值失效他们也跟着失效。最近Linux内核为了保证SHA-1值的唯一性,将位数由8位扩展 到10位,这就导致扩展之前的 git describe 输出完全失效了。 生成内部版本号 现在可以发布一个新的版本了。首先要将代码的压缩包归档,方便那些可怜的还没有使用Git的人们。可以使用 git archive : $ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz $ ls *.tar.gz v1.6.2-rc1-20-g8c5b85c.tar.gz 这个压缩包解压出来的是一个文件夹,里面是你项目的最新代码快照。你也可以用类似的方法建立一个zip压缩包,在 git archive 加上 --format=zip 选项: $ git archive master --prefix='project/' --format=zip > `git describe master`.zip 现在你有了一个tar.gz压缩包和一个zip压缩包,可以把他们上传到你网站上或者用e-mail发给别人。 是时候通知邮件列表里的朋友们来检验你的成果了。使用 git shortlog 命令可以方便快捷的制作一份修改日志 (changelog),告诉大家上次发布之后又增加了哪些特性和修复了哪些bug。实际上这个命令能够统计给定范围内的所有提 交;假如你上一次发布的版本是v1.0.1,下面的命令将给出自从上次发布之后的所有提交的简介: $ git shortlog --no-merges master --not v1.0.1 Chris Wanstrath (8): Add support for annotated tags to Grit::Tag Add packed-refs annotated tag support. Add Grit::Commit#to_patch Update version and History.txt Remove stray `puts` Make ls_tree ignore nils Tom Preston-Werner (4): fix dates in history dynamic version method Version bump to 1.0.2 Regenerated gemspec for version 1.0.2 这就是自从v1.0.1版本以来的所有提交的简介,内容按照作者分组,以便你能快速的发e-mail给他们。 准备发布 制作简报 你学会了如何使用Git为项目做贡献,也学会了如何使用Git维护你的项目。恭喜!你已经成为一名高效的开发者。在下一章你 将学到更强大的工具来处理更加复杂的问题,之后你会变成一位Git大师。 小结 现在,你已经学习了管理或者维护 Git 仓库,实现代码控制所需的大多数日常命令和工作流程。你已经完成了跟踪和提交文 件的基本任务,并且发挥了暂存区和轻量级的特性分支及合并的威力。 接下来你将领略到一些 Git 可以实现的非常强大的功能,这些功能你可能并不会在日常操作中使用,但在某些时候你也许会 需要。 Git 工具 Git 允许你通过几种方法来指明特定的或者一定范围内的提交。了解它们并不是必需的,但是了解一下总没坏处。 显然你可以使用给出的 SHA-1 值来指明一次提交,不过也有更加人性化的方法来做同样的事。本节概述了指明单个提交的诸 多方法。 Git 很聪明,它能够通过你提供的前几个字符来识别你想要的那次提交,只要你提供的那部分 SHA-1 不短于四个字符,并且 没有歧义——也就是说,当前仓库中只有一个对象以这段 SHA-1 开头。 例如,想要查看一次指定的提交,假设你运行 git log 命令并找到你增加了功能的那次提交: $ git log commit 734713bc047d87bf7eac9674765ae793478c50d3 Author: Scott Chacon Date: Fri Jan 2 18:32:33 2009 -0800 fixed refs handling, added gc auto, updated tests commit d921970aadf03b3cf0e71becdaab3147ba71cdef Merge: 1c002dd... 35cfb2b... Author: Scott Chacon Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b Author: Scott Chacon Date: Thu Dec 11 14:58:32 2008 -0800 added some blame and merge stuff 假设是 1c002dd.... 。如果你想 git show 这次提交,下面的命令是等价的(假设简短的版本没有歧义): $ git show 1c002dd4b536e7479fe34593e72e6c6c1819e53b $ git show 1c002dd4b536e7479f $ git show 1c002d Git 可以为你的 SHA-1 值生成出简短且唯一的缩写。如果你传递 --abbrev-commit 给 git log 命令,输出结果里就会使用简短 且唯一的值;它默认使用七个字符来表示,不过必要时为了避免 SHA-1 的歧义,会增加字符数: $ git log --abbrev-commit --pretty=oneline ca82a6d changed the version number 085bb3b removed unnecessary test code a11bef0 first commit 通常在一个项目中,使用八到十个字符来避免 SHA-1 歧义已经足够了。最大的 Git 项目之一,Linux 内核,目前也只需要最 长 40 个字符中的 12 个字符来保持唯一性。 许多人可能会担心一个问题:在随机的偶然情况下,在他们的仓库里会出现两个具有相同 SHA-1 值的对象。那会怎么样呢? 如果你真的向仓库里提交了一个跟之前的某个对象具有相同 SHA-1 值的对象,Git 将会发现之前的那个对象已经存在在 Git 修订版本(Revision)选择 单个修订版本 简短的SHA 关于 SHA-1 的简短说明 数据库中,并认为它已经被写入了。如果什么时候你想再次检出那个对象时,你会总是得到先前的那个对象的数据。 不过,你应该了解到,这种情况发生的概率是多么微小。SHA-1 摘要长度是 20 字节,也就是 160 位。为了保证有 50% 的 概率出现一次冲突,需要 2^80 个随机哈希的对象(计算冲突机率的公式是 p = (n(n-1)/2) * (1/2^160)) 。2^80 是 1.2 x 10^24,也就是一亿亿亿,那是地球上沙粒总数的 1200 倍。 现在举例说一下怎样才能产生一次 SHA-1 冲突。如果地球上 65 亿的人类都在编程,每人每秒都在产生等价于整个 Linux 内 核历史(一百万个 Git 对象)的代码,并将之提交到一个巨大的 Git 仓库里面,那将花费 5 年的时间才会产生足够的对象,使 其拥有 50% 的概率产生一次 SHA-1 对象冲突。这要比你编程团队的成员同一个晚上在互不相干的意外中被狼袭击并杀死的 机率还要小。 指明一次提交的最直接的方法要求有一个指向它的分支引用。这样,你就可以在任何需要一个提交对象或者 SHA-1 值的 Git 命令中使用该分支名称了。如果你想要显示一个分支的最后一次提交的对象,例如假设 topic1 分支指向 ca82a6d ,那么下 面的命令是等价的: $ git show ca82a6dff817ec66f44342007202690a93763949 $ git show topic1 如果你想知道某个分支指向哪个特定的 SHA,或者想看任何一个例子中被简写的 SHA-1,你可以使用一个叫做 rev-parse 的 Git 探测工具。在第 9 章你可以看到关于探测工具的更多信息;简单来说, rev-parse 是为了底层操作而不是日常操作设计 的。不过,有时你想看 Git 现在到底处于什么状态时,它可能会很有用。这里你可以对你的分支运执行 rev-parse 。 $ git rev-parse topic1 ca82a6dff817ec66f44342007202690a93763949 在你工作的同时,Git 在后台的工作之一就是保存一份引用日志——一份记录最近几个月你的 HEAD 和分支引用的日志。 你可以使用 git reflog 来查看引用日志: $ git reflog 734713b... HEAD@{0}: commit: fixed refs handling, added gc auto, updated d921970... HEAD@{1}: merge phedders/rdocs: Merge made by recursive. 1c002dd... HEAD@{2}: commit: added some blame and merge stuff 1c36188... HEAD@{3}: rebase -i (squash): updating HEAD 95df984... HEAD@{4}: commit: # This is a combination of two commits. 1c36188... HEAD@{5}: rebase -i (squash): updating HEAD 7e05da5... HEAD@{6}: rebase -i (pick): updating HEAD 每次你的分支顶端因为某些原因被修改时,Git 就会为你将信息保存在这个临时历史记录里面。你也可以使用这份数据来指明 更早的分支。如果你想查看仓库中 HEAD 在五次前的值,你可以使用引用日志的输出中的 @{n} 引用: $ git show HEAD@{5} 你也可以使用这个语法来查看某个分支在一定时间前的位置。例如,想看你的 master 分支昨天在哪,你可以输入 $ git show master@{yesterday} 它就会显示昨天分支的顶端在哪。这项技术只对还在你引用日志里的数据有用,所以不能用来查看比几个月前还早的提交。 分支引用 引用日志里的简称 想要看类似于 git log 输出格式的引用日志信息,你可以运行 git log -g : $ git log -g master commit 734713bc047d87bf7eac9674765ae793478c50d3 Reflog: master@{0} (Scott Chacon ) Reflog message: commit: fixed refs handling, added gc auto, updated Author: Scott Chacon Date: Fri Jan 2 18:32:33 2009 -0800 fixed refs handling, added gc auto, updated tests commit d921970aadf03b3cf0e71becdaab3147ba71cdef Reflog: master@{1} (Scott Chacon ) Reflog message: merge phedders/rdocs: Merge made by recursive. Author: Scott Chacon Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' 需要注意的是,引用日志信息只存在于本地——这是一个记录你在你自己的仓库里做过什么的日志。其他人拷贝的仓库里的 引用日志不会和你的相同;而你新克隆一个仓库的时候,引用日志是空的,因为你在仓库里还没有操作。 git show HEAD@{2.months.ago} 这条命令只有在你克隆了一个项目至少两个月时才会有用——如果你是五分钟前克隆的仓库,那么它 将不会有结果返回。 另一种指明某次提交的常用方法是通过它的祖先。如果你在引用最后加上一个 ^ ,Git 将其理解为此次提交的父提交。 假设 你的工程历史是这样的: $ git log --pretty=format:'%h %s' --graph * 734713b fixed refs handling, added gc auto, updated tests * d921970 Merge commit 'phedders/rdocs' |\ | * 35cfb2b Some rdoc changes * | 1c002dd added some blame and merge stuff |/ * 1c36188 ignore *.gem * 9b29157 add open3_detach to gemspec file list 那么,想看上一次提交,你可以使用 HEAD^ ,意思是“HEAD 的父提交”: $ git show HEAD^ commit d921970aadf03b3cf0e71becdaab3147ba71cdef Merge: 1c002dd... 35cfb2b... Author: Scott Chacon Date: Thu Dec 11 15:08:43 2008 -0800 Merge commit 'phedders/rdocs' 你也可以在 ^ 后添加一个数字——例如, d921970^2 意思是“d921970 的第二父提交”。这种语法只在合并提交时有用,因 为合并提交可能有多个父提交。第一父提交是你合并时所在分支,而第二父提交是你所合并的分支: 祖先引用 $ git show d921970^ commit 1c002dd4b536e7479fe34593e72e6c6c1819e53b Author: Scott Chacon Date: Thu Dec 11 14:58:32 2008 -0800 added some blame and merge stuff $ git show d921970^2 commit 35cfb2b795a55793d7cc56a6cc2060b4bb732548 Author: Paul Hedderly Date: Wed Dec 10 22:22:03 2008 +0000 Some rdoc changes 另外一个指明祖先提交的方法是 ~ 。这也是指向第一父提交,所以 HEAD~ 和 HEAD^ 是等价的。当你指定数字的时候就明 显不一样了。 HEAD~2 是指“第一父提交的第一父提交”,也就是“祖父提交”——它会根据你指定的次数检索第一父提交。例 如,在上面列出的历史记录里面, HEAD~3 会是 $ git show HEAD~3 commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d Author: Tom Preston-Werner Date: Fri Nov 7 13:47:59 2008 -0500 ignore *.gem 也可以写成 HEAD^^^ ,同样是第一父提交的第一父提交的第一父提交: $ git show HEAD^^^ commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d Author: Tom Preston-Werner Date: Fri Nov 7 13:47:59 2008 -0500 ignore *.gem 你也可以混合使用这些语法——你可以通过 HEAD~3^2 指明先前引用的第二父提交(假设它是一个合并提交)。 现在你已经可以指明单次的提交,让我们来看看怎样指明一定范围的提交。这在你管理分支的时候尤显重要——如果你有很 多分支,你可以指明范围来圈定一些问题的答案,比如:“这个分支上我有哪些工作还没合并到主分支的?” 最常用的指明范围的方法是双点的语法。这种语法主要是让 Git 区分出可从一个分支中获得而不能从另一个分支中获得的提 交。例如,假设你有类似于图 6-1 的提交历史。 图 6-1. 范围选择的提交历史实例 你想要查看你的试验分支上哪些没有被提交到主分支,那么你就可以使用 master..experiment 来让 Git 显示这些提交的日志 ——这句话的意思是“所有可从experiment分支中获得而不能从master分支中获得的提交”。为了使例子简单明了,我使用了 图标中提交对象的字母来代替真实日志的输出,所以会显示: 提交范围 双点 $ git log master..experiment D C 另一方面,如果你想看相反的——所有在 master 而不在 experiment 中的分支——你可以交换分支的名 字。 experiment..master 显示所有可在 master 获得而在 experiment 中不能的提交: $ git log experiment..master F E 这在你想保持 experiment 分支最新和预览你将合并的提交的时候特别有用。这个语法的另一种常见用途是查看你将把什么推 送到远程: $ git log origin/master..HEAD 这条命令显示任何在你当前分支上而不在远程 origin 上的提交。如果你运行 git push 并且的你的当前分支正在跟踪 origin/master ,被 git log origin/master..HEAD 列出的提交就是将被传输到服务器上的提交。 你也可以留空语法中的一边来让 Git 来假定它是 HEAD。例如,输入 git log origin/master.. 将得到和上面的例子一样的结果—— Git 使用 HEAD 来代替不存在 的一边。 双点语法就像速记一样有用;但是你也许会想针对两个以上的分支来指明修订版本,比如查看哪些提交被包含在某些分支中 的一个,但是不在你当前的分支上。Git允许你在引用前使用 ^ 字符或者 --not 指明你不希望提交被包含其中的分支。因此下 面三个命令是等同的: $ git log refA..refB $ git log ^refA refB $ git log refB --not refA 这样很好,因为它允许你在查询中指定多于两个的引用,而这是双点语法所做不到的。例如,如果你想查找所有 从 refA 或 refB 包含的但是不被 refC 包含的提交,你可以输入下面中的一个 $ git log refA refB ^refC $ git log refA refB --not refC 这建立了一个非常强大的修订版本查询系统,应该可以帮助你解决分支里包含了什么这个问题。 最后一种主要的范围选择语法是三点语法,这个可以指定被两个引用中的一个包含但又不被两者同时包含的分支。回过头来 看一下图6-1里所列的提交历史的例子。 如果你想查看 master 或者 experiment 中包含的但不是两者共有的引用,你可以运行 $ git log master...experiment F E D C 这个再次给出你普通的 log 输出但是只显示那四次提交的信息,按照传统的提交日期排列。 这种情形下, log 命令的一个常用参数是 --left-right ,它会显示每个提交到底处于哪一侧的分支。这使得数据更加有用。 多点 三点 $ git log --left-right master...experiment < F < E > D > C 有了以上工具,让Git知道你要察看哪些提交就容易得多了。 Git提供了很多脚本来辅助某些命令行任务。这里,你将看到一些交互式命令,它们帮助你方便地构建只包含特定组合和部分 文件的提交。在你修改了一大批文件然后决定将这些变更分布在几个各有侧重的提交而不是单个又大又乱的提交时,这些工 具非常有用。用这种方法,你可以确保你的提交在逻辑上划分为相应的变更集,以便于供和你一起工作的开发者审阅。如果 你运行 git add 时加上 -i 或者 --interactive 选项,Git就进入了一个交互式的shell模式,显示一些类似于下面的信息: $ git add -i staged unstaged path 1: unchanged +0/-1 TODO 2: unchanged +1/-1 index.html 3: unchanged +5/-1 lib/simplegit.rb *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> 你会看到这个命令以一个完全不同的视图显示了你的暂存区——主要是你通过 git status 得到的那些信息但是稍微简洁但信息 更加丰富一些。它在左侧列出了你暂存的变更,在右侧列出了未被暂存的变更。 在这之后是一个命令区。这里你可以做很多事情,包括暂存文件,撤回文件,暂存部分文件,加入未被追踪的文件,查看暂 存文件的差别。 如果你在 What now> 的提示后输入 2 或者 u ,这个脚本会提示你那些文件你想要暂存: What now> 2 staged unstaged path 1: unchanged +0/-1 TODO 2: unchanged +1/-1 index.html 3: unchanged +5/-1 lib/simplegit.rb Update>> 如果想暂存TODO和index.html,你可以输入相应的编号: Update>> 1,2 staged unstaged path * 1: unchanged +0/-1 TODO * 2: unchanged +1/-1 index.html 3: unchanged +5/-1 lib/simplegit.rb Update>> 每个文件旁边的 * 表示选中的文件将被暂存。如果你在 update>> 提示后直接敲入回车,Git会替你把所有选中的内容暂存: Update>> updated 2 paths *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> 1 staged unstaged path 1: +0/-1 nothing TODO 2: +1/-1 nothing index.html 3: unchanged +5/-1 lib/simplegit.rb 现在你可以看到TODO和index.html文件被暂存了同时simplegit.rb文件仍然未被暂存。如果这时你想要撤回TODO文件,就使 用 3 或者 r (代表revert,恢复)选项: 交互式暂存 暂存和撤回文件 *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> 3 staged unstaged path 1: +0/-1 nothing TODO 2: +1/-1 nothing index.html 3: unchanged +5/-1 lib/simplegit.rb Revert>> 1 staged unstaged path * 1: +0/-1 nothing TODO 2: +1/-1 nothing index.html 3: unchanged +5/-1 lib/simplegit.rb Revert>> [enter] reverted one path 再次查看Git的状态,你会看到你已经撤回了TODO文件 *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> 1 staged unstaged path 1: unchanged +0/-1 TODO 2: +1/-1 nothing index.html 3: unchanged +5/-1 lib/simplegit.rb 要查看你暂存内容的差异,你可以使用 6 或者 d (表示diff)命令。它会显示你暂存文件的列表,你可以选择其中的几个,显 示其被暂存的差异。这跟你在命令行下指定 git diff --cached 非常相似: *** Commands *** 1: status 2: update 3: revert 4: add untracked 5: patch 6: diff 7: quit 8: help What now> 6 staged unstaged path 1: +1/-1 nothing index.html Review diff>> 1 diff --git a/index.html b/index.html index 4d07108..4335f49 100644 --- a/index.html +++ b/index.html @@ -16,7 +16,7 @@ Date Finder

...

- +