许可证
本作品在“创作共用 署名-非商业性使用-相同方式共享 3.0 未本地化版本 (CC BY-NC-SA 3.0)”许可协议下授权。 要阅览该许可的副本,请访问 https://creativecommons.org/licenses/by-nc-sa/3.0/deed.zh 或者写信向 Creative Commons, PO Box 1866, Mountain View, CA 94042, USA 获取。
Scott Chacon 序
欢迎来到 Pro Git 第二版。 第一版出版到现在已经过去了四年。 到今天,Git 虽然出现了许多改变,但是还有很多重要的事情一如昨日。 因为 Git 核心团队对保持向后兼容性异常固执,所以直到今天大多数核心命令与概念依然有效,但是围绕 Git 的社区还是有一些重大的增加与改变。 本书的第二版就是为了更新书籍并讲解那些改动以使其对新用户更有帮助。
当我写第一版时,Git 对于超级黑客来说还是一个相对难用,只能勉强接受的工具。 它开始在特定的社区中快速发展,但是还没有达到像今天一样无处不在的地步。 自那时起,几乎每一个开源社区都采用了它。 Git 在 Windows 上取得了难以置信的进步,包括所有平台的图形用户界面对它的支持、IDE 的支持,以及商业使用的爆炸式发展。 四年前的 Pro Git 对此一无所知。 新版本的主要目标之一就是涉及 Git 社区中那些所有新的前沿领域。
使用 Git 的开源社区也呈现出爆炸式的发展。 大概在五年前吧,我坐下来写这本书时(写完第一个版本花了我不少时间),我开始在一个知名度极小的开发 Git 托管网站的公司工作,这家公司就是 GitHub。 本书出版时大概有几千人在使用 GitHub 网站,而为其工作的只有我们四个人。 在我写这篇介绍时,GitHub 宣布我们托管了 1000 万个项目、拥有大概 500 万注册开发者账户与大概 230 名员工。 爱它也好,恨它也罢,当我坐下来写第一版时,GitHub 以一种意想不到的方式猛烈地改变了一大批开源社区。
我在 Pro Git 的原始版本中写了一节我并不是很满意的内容,是作为和提供 Git 托管服务相关的例子的 GitHub。 我在书里写的东西本质上都是和社区有关的,但是又不得不讨论到我的公司,这点我不喜欢。 虽然我还是不喜欢这种利益冲突,但 GitHub 在 Git 社区的重要性是不能回避的。 我已经决定将本书中关于 GitHub 的部分转变为深度介绍 GitHub 是什么以及如何高效地使用它,而不再是作为一个 Git 托管的例子。 如果你正学习如何使用 Git,那么了解如何使用 GitHub 将会帮助你加入到一个巨大的社区中。不论你决定为自己的代码使用哪一个 Git 托管服务,这都很有价值。
自从上次出版以来另一个重大变革是 Git 网络传输 HTTP 协议的开发与崛起。书中的大多数例子都已经从 SSH 切换到 HTTP,因为它更简单。
在过去这几年看到 Git 从一个相对无名的版本管理系统成长为商业与开源版本管理的事实标准是令人吃惊的。我很高兴 Pro Git 做得很好并已经成为市场上几本既成功又完全开源的技术书籍之一。
我希望你能享受这个升级版的 Pro Git。
Ben Straub 序
本书的第一版就是将我与 Git 结下不解之缘的原因。书中采用的是我引进的做软件的风格,这种风格比我之前看到的任何事情都要自然。那时我已经做了好几年开发者了,但是这本书将我指引到一条更加精彩的道路上。
几年之后的现在,我是 Git 的一个主要实现的贡献者,我在最大的 Git 托管公司工作,我已经环游世界教人们使用 Git。当 Scott 问我是否有兴趣在第二版上工作时,我甚至连想都没想就答应了。
能在这本书上工作是一份巨大的快乐与荣耀。我希望它能像帮助我一样帮助你。
献辞
致我的妻子,Becky,没有她的话这段冒险不会开始。—— Ben
谨以此书献给我的家人。 给这些年一直支持着我的妻子 Jessica 和女儿 Josephine, 还有那些在我风烛残年之时还能支持我的人。—— Scott
贡献者
因为这是一本开源书籍,这几年我们获得了捐赠的若干勘误表与内容修改。 下面是将 ProGit 英文版作为开源项目贡献的所有人员。 感谢你们帮助将这本书变成对每一个人都更好的书。
Contributors as of 72233a61:
4wk- KatDwo Wisp Zhan
8loser Katrin Leinweber WispZhan
Adam Laflamme Kausar Mehmood Wlodek Bzyl
Adrien Ollier Keith Hill Xavier Bonaventura
Akrom K Kenneth Kin Lum Y. Z. Chen
Alan Klaus Frank Yann Soubeyrand
Alan Wang Kristijan "Fremen" Velkovski Yedda
Albert Krzysztof Szumny Yue Lin Ho
Aleh Suprunovich Kyrylo Yatsenko Yuhang Guo
Alexander Bezzubov Lars Vogel Yunbin Liu
Alexandre Garnier Laxman Yunhai Luo
Alfred Myers Lazar95 Yusuke SATO
Alpha Hinex Leonard Laszlo Zheeeng
Amanda Dillon Lin Hsu ajax333221
Andrei Dascalu Linus Heckemann alamier
Andrew Layman Liu Lantao albert
Andrew MacFie Logan Hasson alex-koziell
Andrew Metcalf Louise Corrigan allen joslin
Andrew Murphy Luc Morin anguiao
AndyGee Lukas Röllin atalakam
AnneTheAgile Marcin Sędłak-Jakubowski axmbo
Anthony Loiseau Marie-Helene Burle banxi1988
Anton Trunov Marius Žilėnas bob
Antonello Piemonte Markus KARG branchzero
Antonino Ingargiola Marti Bolivar bripmccann
Atul Varma Mashrur Mia (Sa'ad) brotherben
Awc Cho Masood Fallahpoor cangyin
Ben Sima Mathieu Dubreuilh chen
Benjamin Dopplinger Matthew Miner chengz
Bill Zhao Matthieu Moy curiositer
Borek Bernard Michael MacAskill delta4d
BranchZero Sun Michael Sheaver devwebcl
Brett Cannon Michael Welch dualsky
Buzut Michiel van der Wulp evanderiel
C Nguyen Mike Charles eyherabh
Cadel Watson Mike Pennisi flip111
CaoWeiwei Mike Thibodeau flyingzumwalt
Carlos Martín Nieto Moriaty0o0 goekboet
Carlos Tafur Niels Widger grgbnc
Chaitanya Gurrapu Nils Reuße guan wang
Changwoo Park Oling Cat haripetrov
Cheng Liang Olleg Samoylov hasan
ChrisChan2015 Owen hasban12138
Christoph Prokop Pablo Schläpfer i-give-up
Christopher Wilson Pascal Berger ijessie
Chuckie Chen Pascal Borreli iprok
CodingSpiderFox Patrick Steinhardt jckling
Cory Donnelly Pavel Janík jingsam
Cullen Rhodes Paweł Krupiński johnhar
Cyril Perry laggardkernel
Damien Tournoud Peter Kokot leo
Dan Schmidt Phil Mitchell leo108
Daniel Shahaf Philippe Blain leshiv
Daniel Sturm Philippe Miossec lilydjwg
Daniele Tricoli Qiu Chaofan lingr7
Daniil Larionov Rafi liuxilu
Danny Lin Raphael R liwenzhuo
David Rogers Ray Chen ljporljp
Davide Angelocola Razon Yang luozexuan
Denis Savitskiy Rei maks
Dexter Rex Kerr marjune
Dexter Morganov Reza Ahmadi mmikeww
DiamondeX Richard Hoyle moonlitusun
Dieter Ziller Ricky Senft moralok
Dino Karic Rintze M. Zelle morstar
Dmitri Tikhonov Rob Blanco mosdalsvsocld
Dmitriy Smirnov Robert P. Goldman mowangjuanzi
Duncan Dean Robert P. J. Day myd7349
Eden Hochbaum Rohan D'Souza neo1218
Eric Henziger Roman Kosenko networm
Excimer Gong Ronald Wampler nicktime
Explorare Ryan Yin omvjro
Ezra Buehler Rüdiger Herrmann ousugo
Felix Nehrke SATO Yusuke patrick96
Feng Hao Sam Ford paveljanik
Filip Kucharczyk Sam Joseph pedrorijo91
Fornost461 Sanders Kleinfeld peterwwillis
Frank Sarah Schneider petsuter
Frederico Mazzone Saurav Sachidanand pityonline
Frej Drejhammar Scott Bronson puxiao
Gc Sean Head rahrah
Geno1024 Sebastian Krause rmzelle
Gerry Severino Lorilla Jr roife
Guthrie McAfee Armstrong Shengbin Meng root
HairyFotr Shi Yan [email protected]
Hamidreza Mahdavipanah Siarhei Bobryk secondwtq
Hao Gu Siarhei Krukau shukebeta
Haruo Nakayama SkyBlueEE shutaozhenzhen
Helmut K. C. Tessarek Skyper spacewander
Hidde de Vries Snehal Shekatkar td2014
HonkingGoose Song Li twekberg
Howard Stephan van Maris uerdogan
IceNature Steve ZHANG un1versal
Ignacy Steve Zhang wang yuchi
Ilker Cat Steven Roddis wangfpp
Jan Groenewald SudarsanGP xJom
Jason Suhaib Mujahid xtreak
Jaswinder Singh Sven Selberg yakirwin
Jean-Noël Avila Thanix yikakia
Jeroen Oortwijn Thomas Ackermann yikang
Jim Hill Thomas Hartmann yionr
Jimgao Tom Schady zhch
Jinbao Zhang Tomoki Aonuma zhou
Joel Davies Tong Hui zwPapEr
Johannes Dewender Tony Joseph zyw_0618
Johannes Schindelin Tvirus ᐯᕮᒪᗝᑕᕮᒣ
John Lin Tyler Cipriani 刘方杰
Jon Forrest Ud Yzr 啊咪咪小熊
Jon Freed Vadim Markovtsev 夏恺(Xia Kai)
Jordan Hayashi Vangelis Katsikaros 晓荷
Joris Valette Victor Ma 狂飙
Josh Byster Vitaly Kuznetsov 狄卢
Joshua Webb WQR1994 王顶
Jun Shaw Weisi Dai 诺墨
Junjie Yuan Whitebox 谭九鼎
Justin Clift William Gathoye 非法操作
Kaartic Sivaraam William Turrell 靳阳
章节 | 译者 | 审校者 |
---|---|---|
1. 起步 |
||
1.1 关于版本控制 |
||
1.2 Git 简史 |
||
1.3 Git 基础 |
||
1.4 命令行 |
||
1.5 安装 Git |
||
1.6 初次运行 Git 前的配置 |
||
1.7 获取帮助 |
||
1.8 总结 |
||
2. Git 基础 |
||
2.1 获取 Git 仓库 |
||
2.2 记录每次更新到仓库 |
||
2.3 查看提交历史 |
||
2.4 撤消操作 |
||
2.5 远程仓库的使用 |
||
2.6 打标签 |
||
2.7 Git 别名 |
||
2.8 总结 |
||
3. Git 分支 |
||
3.1 分支简介 |
||
3.2 分支的新建与合并 |
||
3.3 分支管理 |
||
3.4 分支开发工作流 |
||
3.5 远程分支 |
||
3.6 变基 |
||
3.7 总结 |
Jun995@GitHub |
|
4. 服务器上的 Git |
||
4.1 协议 |
||
4.2 在服务器上搭建 Git |
||
4.3 生成 SSH 公钥 |
||
4.4 配置服务器 |
||
4.5 Git 守护进程 |
||
4.6 Smart HTTP |
||
4.7 GitWeb |
||
4.8 GitLab |
||
4.9 第三方托管的选择 |
||
4.10 总结 |
||
5. 分布式 Git |
||
5.1 分布式工作流程 |
||
5.2 向一个项目贡献 |
||
5.3 维护项目 |
||
5.4 总结 |
||
6. GitHub |
||
6.1 账户的创建和配置 |
||
6.2 对项目做出贡献 |
||
6.3 维护项目 |
||
6.4 管理组织 |
||
6.5 脚本 GitHub |
||
6.6 总结 |
||
7. Git 工具 |
||
7.1 选择修订版本 |
||
7.2 交互式暂存 |
||
7.3 储藏与清理 |
||
7.4 签署工作 |
||
7.5 搜索 |
||
7.6 重写历史 |
||
7.7 重置揭密 |
||
7.8 高级合并 |
||
7.9 Rerere |
||
7.10 使用 Git 调试 |
||
7.11 子模块 |
||
7.12 打包 |
||
7.13 替换 |
||
7.14 凭证存储 |
||
7.15 总结 |
||
8. 自定义 Git |
||
8.1 配置 Git |
||
8.2 Git 属性 |
||
8.3 Git 钩子 |
||
8.4 使用强制策略的一个例子 |
||
8.5 总结 |
||
9. Git 与其他系统 |
||
9.1 作为客户端的 Git |
||
9.2 迁移到 Git |
||
9.3 总结 |
||
10. Git 内部原理 |
||
10.1 底层命令和高层命令 |
||
10.2 Git 对象 |
||
10.3 Git 引用 |
||
10.4 包文件 |
||
10.5 引用规范 |
||
10.6 传输协议 |
||
10.7 维护与数据恢复 |
||
10.8 环境变量 |
||
10.9 总结 |
||
A1. 其它环境中的 Git |
||
A1.1 图形界面 |
||
A1.2 Visual Studio 中的 Git |
||
A1.3 Visual Studio Code 中的 Git |
||
A1.4 Eclipse 中的 Git |
||
A1.5 IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine 中的 Git |
||
A1.6 Sublime Text 中的 Git |
||
A1.7 Bash 中的 Git |
||
A1.8 Zsh 中的 Git |
||
A1.9 Powershell 中的 Git |
||
A1.10 总结 |
||
A2. 将 Git 嵌入你的应用 |
||
A2.1 命令行 Git 方式 |
||
A2.2 Libgit2 |
||
A2.3 JGit |
||
A3. Git 命令 |
||
A3.1 设置与配置 |
||
A3.2 获取与创建项目 |
||
A3.3 快照基础 |
||
A3.4 分支与合并 |
||
A3.5 项目分享与更新 |
||
A3.6 检查与比较 |
||
A3.7 调试 |
||
A3.8 补丁 |
||
A3.9 邮件 |
||
A3.10 外部系统 |
||
A3.11 管理 |
||
A3.12 底层命令 |
引言
你将花费你生命中的若干小时来阅读有关 Git 的相关内容。 让我们用几分钟时间来介绍下我们将给你讲解的内容。 下面是本书正文十章和附录三章的快速总结。
在 第一章 ,我们将介绍版本控制系统(VCSs)和 Git 的基本概念——不涉及技术内容,仅仅是什么是 Git, 为什么它会成为 VCSs 大家庭中的一员,它与其它 VCSs 的区别,以及为什么那么多人都在使用 Git。 然后,我们将介绍如何下载 Git 以及如果你的系统没有安装 Git,如何为第一次运行做准备。
在 第二章 ,我们将阐述 Git 的基本使用——包含你在使用 Git 时可能遇到的 80% 的情形。 通过阅读本章,你应该能够克隆仓库、查看项目历史、修改文件和贡献更改。 如果本书在此刻自燃,你应该已经能够使用已经学到的漂亮有用的 Git 知识获取到另外一份拷贝。
第三章 关注于 Git 的分支模型。分支模型通常被认为是 Git 的杀手级特性。 这里,你将学习到究竟是什么让 Git 与众不同。学习完本章,你可能需要一段时间来思考, 在 Git 分支成为你的生活的一部分之前,你到底是如何生活的。
第四章 关注于服务器端的 Git。本章面向那些希望在你自己的组织或个人服务器搭建用于合作的 Git 的读者。 如果你希望让别人处理这些事务,我们也会探讨一些托管选项。
第五章 将阐述多种分布式工作流的细节,以及如何使用 Git 实现它们。 学习完本章,你应该能够在多个远程仓库之间游刃有余,通过电子邮件使用 Git, 熟练地处理多个远程分支和合作者贡献的补丁。
第六章 介绍 GitHub 托管服务以及深层次的工具。我们将涵盖注册与账户管理, 创建和使用 Git 仓库,贡献项目的普通工作流以及接受他人的贡献,GitHub 的可编程接口和那些能够让你的生活变得更简单的小技巧。
第七章 关于 Git 的高级命令。你将学习到一些高级主题,诸如掌握可怕的“reset”命令, 使用二分搜索识别错误,编辑历史,细节版本选择等等。本章的介绍将丰富你的 Git 知识,让你成为一个真正的大师。
第八章 关于 Git 环境的自定义配置,包括设置用于增强或促进自定义策略的钩子脚本, 以及按照你所需要的方式进行工作的环境配置。我们还会介绍构建你自己的脚本集,以增强自定义提交策略。
第九章 对比 Git 和其它 VCSs,包括在 Subversion(SVN)的世界使用 Git 以及从其它 VCSs 迁移到 Git。 很多组织仍在使用 SVN,并且也没有计划改变,此时,你将了解到 Git 不可思议的能力——本章将展示, 在你不得不使用 SVN 服务器的时候如何协同合作。我们还将介绍如何从不同系统导入项目, 以便你能够全身心投入 Git 的怀抱。
第十章 深入 Git 隐晦而漂亮的实现细节。现在,你已经知道所有有关 Git 的知识, 能够熟练运用 Git 的强大优雅的功能。接下来,你可以继续学习 Git 如何存储对象、 Git 的对象模型是怎样的、打包文件的细节、服务器协议等更多知识。 本书自始至终都将引用本章的内容,以便你能够在当时就可以深入了解。 但是,如果你像我们一样希望深入学习技术细节,你可能想先阅读第十章。我们将选择权交给你。
在 附录 A ,我们学习多个在特定环境中使用 Git 的实例。 我们涵盖了许多不同的 GUI 和 IDE 编程环境,你可能会想在这些环境中使用 Git,以及你可以使用哪些环境。 如果你想在 shell、IDE 或文本编辑器中使用 Git,请阅读本章。
在 附录 B ,我们探讨通过类似 libgit2 和 JGit 的工具编写 Git 脚本、扩展 Git。 如果你对编写复杂、快速的自定义工具感兴趣,需要了解 Git 的底层访问,本章就是你所需要了解的。
最后在 附录 C ,我们一次性浏览 Git 的所有主要命令,复习在本书中介绍的内容, 回忆我们能够使用这些命令做什么。如果你需要知道本书中我们使用了哪些特定 Git 命令,你可以在这里查阅。
下面让我们开始吧。
起步
本章为 Git 入门。 我们从介绍版本控制工具的背景知识开始,然后讲解如何在你的系统上运行 Git,最后是关于如何设置 Git 以便开始工作。 通过本章的学习,你应该能了解为什么 Git 这么流行,为什么你应该使用 Git 以及你应该如何设置以便使用 Git。
关于版本控制
什么是“版本控制”?我为什么要关心它呢? 版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。 在本书所展示的例子中,我们对保存着软件源代码的文件作版本控制,但实际上,你可以对任何类型的文件进行版本控制。
如果你是位图形或网页设计师,可能会需要保存某一幅图片或页面布局文件的所有修订版本(这或许是你非常渴望拥有的功能),采用版本控制系统(VCS)是个明智的选择。 有了它你就可以将选定的文件回溯到之前的状态,甚至将整个项目都回退到过去某个时间点的状态,你可以比较文件的变化细节,查出最后是谁修改了哪个地方,从而找出导致怪异问题出现的原因,又是谁在何时报告了某个功能缺陷等等。 使用版本控制系统通常还意味着,就算你乱来一气把整个项目中的文件改的改删的删,你也照样可以轻松恢复到原先的样子。 但额外增加的工作量却微乎其微。
本地版本控制系统
许多人习惯用复制整个项目目录的方式来保存不同的版本,或许还会改名加上备份时间以示区别。 这么做唯一的好处就是简单,但是特别容易犯错。 有时候会混淆所在的工作目录,一不小心会写错文件或者覆盖意想外的文件。
为了解决这个问题,人们很久以前就开发了许多种本地版本控制系统,大多都是采用某种简单的数据库来记录文件的历次更新差异。
其中最流行的一种叫做 RCS,现今许多计算机系统上都还看得到它的踪影。 RCS 的工作原理是在硬盘上保存补丁集(补丁是指文件修订前后的变化);通过应用所有的补丁,可以重新计算出各个版本的文件内容。
集中化的版本控制系统
接下来人们又遇到一个问题,如何让在不同系统上的开发者协同工作? 于是,集中化的版本控制系统(Centralized Version Control Systems,简称 CVCS)应运而生。 这类系统,诸如 CVS、Subversion 以及 Perforce 等,都有一个单一的集中管理的服务器,保存所有文件的修订版本,而协同工作的人们都通过客户端连到这台服务器,取出最新的文件或者提交更新。 多年以来,这已成为版本控制系统的标准做法。
这种做法带来了许多好处,特别是相较于老式的本地 VCS 来说。 现在,每个人都可以在一定程度上看到项目中的其他人正在做些什么。 而管理员也可以轻松掌控每个开发者的权限,并且管理一个 CVCS 要远比在各个客户端上维护本地数据库来得轻松容易。
事分两面,有好有坏。 这么做最显而易见的缺点是中央服务器的单点故障。 如果宕机一小时,那么在这一小时内,谁都无法提交更新,也就无法协同工作。 如果中心数据库所在的磁盘发生损坏,又没有做恰当备份,毫无疑问你将丢失所有数据——包括项目的整个变更历史,只剩下人们在各自机器上保留的单独快照。 本地版本控制系统也存在类似问题,只要整个项目的历史记录被保存在单一位置,就有丢失所有历史更新记录的风险。
分布式版本控制系统
于是分布式版本控制系统(Distributed Version Control System,简称 DVCS)面世了。 在这类系统中,像 Git、Mercurial 以及 Darcs 等,客户端并不只提取最新版本的文件快照, 而是把代码仓库完整地镜像下来,包括完整的历史记录。 这么一来,任何一处协同工作用的服务器发生故障,事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作,实际上都是一次对代码仓库的完整备份。
更进一步,许多这类系统都可以指定和若干不同的远端代码仓库进行交互。籍此,你就可以在同一个项目中,分别和不同工作小组的人相互协作。 你可以根据需要设定不同的协作流程,比如层次模型式的工作流,而这在以前的集中式系统中是无法实现的。
Git 简史
同生活中的许多伟大事物一样,Git 诞生于一个极富纷争大举创新的年代。
Linux 内核开源项目有着为数众多的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补丁和保存归档的繁琐事务上(1991-2002年间)。 到 2002 年,整个项目组开始启用一个专有的分布式版本控制系统 BitKeeper 来管理和维护代码。
到了 2005 年,开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束,他们收回了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区(特别是 Linux 的缔造者 Linus Torvalds)基于使用 BitKeeper 时的经验教训,开发出自己的版本系统。 他们对新的系统制订了若干目标:
-
速度
-
简单的设计
-
对非线性开发模式的强力支持(允许成千上万个并行开发的分支)
-
完全分布式
-
有能力高效管理类似 Linux 内核一样的超大规模项目(速度和数据量)
自诞生于 2005 年以来,Git 日臻成熟完善,在高度易用的同时,仍然保留着初期设定的目标。 它的速度飞快,极其适合管理大项目,有着令人难以置信的非线性分支管理系统(参见 Git 分支)。
Git 是什么?
那么,简单地说,Git 究竟是怎样的一个系统呢? 请注意接下来的内容非常重要,若你理解了 Git 的思想和基本工作原理,用起来就会知其所以然,游刃有余。 在学习 Git 时,请尽量理清你对其它版本管理系统已有的认识,如 CVS、Subversion 或 Perforce, 这样能帮助你使用工具时避免发生混淆。尽管 Git 用起来与其它的版本控制系统非常相似, 但它在对信息的存储和认知方式上却有很大差异,理解这些差异将有助于避免使用中的困惑。
直接记录快照,而非差异比较
Git 和其它版本控制系统(包括 Subversion 和近似工具)的主要差别在于 Git 对待数据的方式。 从概念上来说,其它大部分系统以文件变更列表的方式存储信息,这类系统(CVS、Subversion、Perforce 等等) 将它们存储的信息看作是一组基本文件和每个文件随时间逐步累积的差异 (它们通常称作 基于差异(delta-based) 的版本控制)。
Git 不按照以上方式对待或保存数据。反之,Git 更像是把数据看作是对小型文件系统的一系列快照。 在 Git 中,每当你提交更新或保存项目状态时,它基本上就会对当时的全部文件创建一个快照并保存这个快照的索引。 为了效率,如果文件没有修改,Git 不再重新存储该文件,而是只保留一个链接指向之前存储的文件。 Git 对待数据更像是一个 快照流。
这是 Git 与几乎所有其它版本控制系统的重要区别。 因此 Git 重新考虑了以前每一代版本控制系统延续下来的诸多方面。 Git 更像是一个小型的文件系统,提供了许多以此为基础构建的超强工具,而不只是一个简单的 VCS。 稍后我们在Git 分支讨论 Git 分支管理时,将探究这种方式对待数据所能获得的益处。
近乎所有操作都是本地执行
在 Git 中的绝大多数操作都只需要访问本地文件和资源,一般不需要来自网络上其它计算机的信息。 如果你习惯于所有操作都有网络延时开销的集中式版本控制系统,Git 在这方面会让你感到速度之神赐给了 Git 超凡的能量。 因为你在本地磁盘上就有项目的完整历史,所以大部分操作看起来瞬间完成。
举个例子,要浏览项目的历史,Git 不需外连到服务器去获取历史,然后再显示出来——它只需直接从本地数据库中读取。 你能立即看到项目历史。如果你想查看当前版本与一个月前的版本之间引入的修改, Git 会查找到一个月前的文件做一次本地的差异计算,而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。
这也意味着你在离线或者没有 VPN 时,几乎可以进行任何操作。 如你在飞机或火车上想做些工作,就能愉快地提交(到你的 本地 副本,还记得吗?), 直到有网络连接时再上传。如你回家后 VPN 客户端不正常,那么也仍能工作。 使用其它系统的话,做到这些是不可能或很费力的。 比如,用 Perforce 的话,没有连接服务器时几乎不能做什么事;而用 Subversion 和 CVS 的话, 你能修改文件,但不能向数据库提交修改(因为你的本地数据库离线了)。 这样似乎问题不大,但是你可能会惊喜地发现它带来的巨大的不同。
Git 保证完整性
Git 中所有的数据在存储前都计算校验和,然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层,是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件,Git 就能发现。
Git 用以计算校验和的机制叫做 SHA-1 散列(hash,哈希)。 这是一个由 40 个十六进制字符(0-9 和 a-f)组成的字符串,基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样:
24b9da6552252987aa493b52f8696cd6d3b00373
Git 中使用这种哈希值的情况很多,你将经常看到这种哈希值。 实际上,Git 数据库中保存的信息都是以文件内容的哈希值来索引,而不是文件名。
Git 一般只添加数据
你执行的 Git 操作,几乎只往 Git 数据库中 添加 数据。 你很难使用 Git 从数据库中删除数据,也就是说 Git 几乎不会执行任何可能导致文件不可恢复的操作。 同别的 VCS 一样,未提交更新时有可能丢失或弄乱修改的内容。但是一旦你提交快照到 Git 中, 就难以再丢失数据,特别是如果你定期的推送数据库到其它仓库的话。
这使得我们使用 Git 成为一个安心愉悦的过程,因为我们深知可以尽情做各种尝试,而没有把事情弄糟的危险。 更深度探讨 Git 如何保存数据及恢复丢失数据的话题,请参考撤消操作。
三种状态
现在请注意,如果你希望后面的学习更顺利,请记住下面这些关于 Git 的概念。 Git 有三种状态,你的文件可能处于其中之一: 已提交(committed)、已修改(modified) 和 已暂存(staged)。
-
已修改表示修改了文件,但还没保存到数据库中。
-
已暂存表示对一个已修改文件的当前版本做了标记,使之包含在下次提交的快照中。
-
已提交表示数据已经安全地保存在本地数据库中。
这会让我们的 Git 项目拥有三个阶段:工作区、暂存区以及 Git 目录。
工作区是对项目的某个版本独立提取出来的内容。 这些从 Git 仓库的压缩数据库中提取出来的文件,放在磁盘上供你使用或修改。
暂存区是一个文件,保存了下次将要提交的文件列表信息,一般在 Git 仓库目录中。 按照 Git 的术语叫做“索引”,不过一般说法还是叫“暂存区”。
Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分,从其它计算机克隆仓库时,复制的就是这里的数据。
基本的 Git 工作流程如下:
-
在工作区中修改文件。
-
将你想要下次提交的更改选择性地暂存,这样只会将更改的部分添加到暂存区。
-
提交更新,找到暂存区的文件,将快照永久性存储到 Git 目录。
如果 Git 目录中保存着特定版本的文件,就属于 已提交 状态。 如果文件已修改并放入暂存区,就属于 已暂存 状态。 如果自上次检出后,作了修改但还没有放到暂存区域,就是 已修改 状态。 在 Git 基础 一章,你会进一步了解这些状态的细节, 并学会如何根据文件状态实施后续操作,以及怎样跳过暂存直接提交。
命令行
Git 有多种使用方式。 你可以使用原生的命令行模式,也可以使用 GUI 模式,这些 GUI 软件也能提供多种功能。 在本书中,我们将使用命令行模式。 这是因为首先,只有在命令行模式下你才能执行 Git 的 所有 命令,而大多数的 GUI 软件只实现了 Git 所有功能的一个子集以降低操作难度。 如果你学会了在命令行下如何操作,那么你在操作 GUI 软件时应该也不会遇到什么困难,但是,反之则不成立。 此外,由于每个人的想法与侧重点不同,不同的人常常会安装不同的 GUI 软件,但 所有 人一定会有命令行工具。
假如你是 macOS 用户,我们希望你懂得如何使用终端(Terminal);假如你是 Windows 用户,我们希望你懂得如何使用命令窗口(Command Prompt)或 PowerShell。 如果你尚未掌握以上技能,我们建议你先停下来快速学习一下,本书中的讲述和举例将用到这些技能。
安装 Git
在你开始使用 Git 前,需要将它安装在你的计算机上。 即便已经安装,最好将它升级到最新的版本。 你可以通过软件包或者其它安装程序来安装,或者下载源码编译安装。
本书写作时使用的 Git 版本为 2.8.0。 我们使用的大部分命令仍然可以在很古老的 Git 版本上使用,但也有少部分命令不好用或者在旧版本中的行为有差异。 因为 Git 在保持向后兼容方面表现很好,本书使用的这些命令在 2.8 之后的版本应该有效。 |
在 Linux 上安装
如果你想在 Linux 上用二进制安装程序来安装基本的 Git 工具,可以使用发行版包含的基础软件包管理工具来安装。
以 Fedora 为例,如果你在使用它(或与之紧密相关的基于 RPM 的发行版,如 RHEL 或 CentOS),你可以使用 dnf
:
$ sudo dnf install git-all
如果你在基于 Debian 的发行版上,如 Ubuntu,请使用 apt
:
$ sudo apt install git-all
要了解更多选择,Git 官方网站上有在各种 Unix 发行版的系统上安装步骤,网址为 https://git-scm.com/download/linux。
在 macOS 上安装
在 Mac 上安装 Git 有多种方式。 最简单的方法是安装 Xcode Command Line Tools。 Mavericks (10.9) 或更高版本的系统中,在 Terminal 里尝试首次运行 'git' 命令即可。
$ git --version
如果没有安装过命令行开发者工具,将会提示你安装。
如果你想安装更新的版本,可以使用二进制安装程序。 官方维护的 macOS Git 安装程序可以在 Git 官方网站下载,网址为 https://git-scm.com/download/mac。
你也可以将它作为 GitHub for macOS 的一部分来安装。 它们的图形化 Git 工具有一个安装命令行工具的选项。 你可以从 GitHub for macOS 网站下载该工具,网址为 https://mac.github.com。
在 Windows 上安装
在 Windows 上安装 Git 也有几种安装方法。 官方版本可以在 Git 官方网站下载。 打开 https://git-scm.com/download/win,下载会自动开始。 要注意这是一个名为 Git for Windows 的项目(也叫做 msysGit),和 Git 是分别独立的项目;更多信息请访问 http://msysgit.github.io/。
要进行自动安装,你可以使用 Git Chocolatey 包。 注意 Chocolatey 包是由社区维护的。
另一个简单的方法是安装 GitHub Desktop。 该安装程序包含图形化和命令行版本的 Git。 它也能支持 Powershell,提供了稳定的凭证缓存和健全的换行设置。 稍后我们会对这方面有更多了解,现在只要一句话就够了,这些都是你所需要的。 你可以在 GitHub for Windows 网站下载,网址为 GitHub Desktop 网站。
从源代码安装
有人觉得从源码安装 Git 更实用,因为你能得到最新的版本。 二进制安装程序倾向于有一些滞后,当然近几年 Git 已经成熟,这个差异不再显著。
如果你想从源码安装 Git,需要安装 Git 依赖的库:autotools、curl、zlib、openssl、expat 和 libiconv。
如果你的系统上有 dnf
(如 Fedora)或者 apt
(如基于 Debian 的系统),
可以使用对应的命令来安装最少的依赖以便编译并安装 Git 的二进制版:
$ sudo dnf install dh-autoreconf curl-devel expat-devel gettext-devel \
openssl-devel perl-devel zlib-devel
$ sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev \
gettext libz-dev libssl-dev
为了添加文档的多种格式(doc、html、info),需要以下附加的依赖:
$ sudo dnf install asciidoc xmlto docbook2X
$ sudo apt-get install asciidoc xmlto docbook2x
使用 RHEL 和 RHEL 衍生版,如 CentOS 和 Scientific Linux 的用户需要
开启 EPEL 库
以便下载 |
如果你使用基于 Debian 的发行版(Debian/Ubuntu/Ubuntu-derivatives),你也需要 install-info
包:
$ sudo apt-get install install-info
如果你使用基于 RPM 的发行版(Fedora/RHEL/RHEL衍生版),你还需要 getopt
包
(它已经在基于 Debian 的发行版中预装了):
$ sudo dnf install getopt
此外,如果你使用 Fedora/RHEL/RHEL衍生版,那么你需要执行以下命令:
$ sudo ln -s /usr/bin/db2x_docbook2texi /usr/bin/docbook2x-texi
以此来解决二进制文件名的不同。
当你安装好所有的必要依赖,你可以继续从几个地方来取得最新发布版本的 tar 包。 你可以从 Kernel.org 网站获取,网址为 https://www.kernel.org/pub/software/scm/git, 或从 GitHub 网站上的镜像来获得,网址为 https://github.com/git/git/releases。 通常在 GitHub 上的是最新版本,但 kernel.org 上包含有文件下载签名,如果你想验证下载正确性的话会用到。
接着,编译并安装:
$ tar -zxf git-2.8.0.tar.gz
$ cd git-2.8.0
$ make configure
$ ./configure --prefix=/usr
$ make all doc info
$ sudo make install install-doc install-html install-info
完成后,你可以使用 Git 来获取 Git 的更新:
$ git clone git://git.kernel.org/pub/scm/git/git.git
初次运行 Git 前的配置
既然已经在系统上安装了 Git,你会想要做几件事来定制你的 Git 环境。 每台计算机上只需要配置一次,程序升级时会保留配置信息。 你可以在任何时候再次通过运行命令来修改它们。
Git 自带一个 git config
的工具来帮助设置控制 Git 外观和行为的配置变量。
这些变量存储在三个不同的位置:
-
/etc/gitconfig
文件: 包含系统上每一个用户及他们仓库的通用配置。 如果在执行git config
时带上--system
选项,那么它就会读写该文件中的配置变量。 (由于它是系统配置文件,因此你需要管理员或超级用户权限来修改它。) -
~/.gitconfig
或~/.config/git/config
文件:只针对当前用户。 你可以传递--global
选项让 Git 读写此文件,这会对你系统上 所有 的仓库生效。 -
当前使用仓库的 Git 目录中的
config
文件(即.git/config
):针对该仓库。 你可以传递--local
选项让 Git 强制读写此文件,虽然默认情况下用的就是它。 (当然,你需要进入某个 Git 仓库中才能让该选项生效。)
每一个级别会覆盖上一级别的配置,所以 .git/config
的配置变量会覆盖 /etc/gitconfig
中的配置变量。
在 Windows 系统中,Git 会查找 $HOME
目录下(一般情况下是 C:\Users\$USER
)的 .gitconfig
文件。
Git 同样也会寻找 /etc/gitconfig
文件,但只限于 MSys 的根目录下,即安装 Git 时所选的目标位置。
如果你在 Windows 上使用 Git 2.x 以后的版本,那么还有一个系统级的配置文件,Windows XP 上在
C:\Documents and Settings\All Users\Application Data\Git\config
,Windows Vista 及其以后的版本在
C:\ProgramData\Git\config
。此文件只能以管理员权限通过 git config -f <file>
来修改。
你可以通过以下命令查看所有的配置以及它们所在的文件:
$ git config --list --show-origin
用户信息
安装完 Git 之后,要做的第一件事就是设置你的用户名和邮件地址。 这一点很重要,因为每一个 Git 提交都会使用这些信息,它们会写入到你的每一次提交中,不可更改:
$ git config --global user.name "John Doe"
$ git config --global user.email [email protected]
再次强调,如果使用了 --global
选项,那么该命令只需要运行一次,因为之后无论你在该系统上做任何事情, Git 都会使用那些信息。
当你想针对特定项目使用不同的用户名称与邮件地址时,可以在那个项目目录下运行没有 --global
选项的命令来配置。
很多 GUI 工具都会在第一次运行时帮助你配置这些信息。
文本编辑器
既然用户信息已经设置完毕,你可以配置默认文本编辑器了,当 Git 需要你输入信息时会调用它。 如果未配置,Git 会使用操作系统默认的文本编辑器。
如果你想使用不同的文本编辑器,例如 Emacs,可以这样做:
$ git config --global core.editor emacs
在 Windows 系统上,如果你想要使用别的文本编辑器,那么必须指定可执行文件的完整路径。 它可能随你的编辑器的打包方式而不同。
对于 Notepad++,一个流行的代码编辑器来说,你可能想要使用 32 位的版本, 因为在本书编写时 64 位的版本尚不支持所有的插件。 如果你在使用 32 位的 Windows 系统,或在 64 位系统上使用 64 位的编辑器,那么你需要输入如下命令:
$ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin"
Vim、Emacs 和 Notepad++ 都是流行的文本编辑器,通常程序员们会在 Linux 和 macOS 这类基于 Unix 的系统或 Windows 系统上使用它们。 如果你在使用其他的或 32 位版本的编辑器,请在 git config core.editor 命令 中查看设置为该编辑器的具体步骤。 |
如果你不这样设置编辑器,那么当 Git 试图启动它时你可能会被弄糊涂、不知所措。 例如,在 Windows 上 Git 在开始编辑时可能会过早地结束。 |
检查配置信息
如果想要检查你的配置,可以使用 git config --list
命令来列出所有 Git 当时能找到的配置:
$ git config --list
user.name=John Doe
[email protected]
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...
你可能会看到重复的变量名,因为 Git 会从不同的文件中读取同一个配置(例如:/etc/gitconfig
与 ~/.gitconfig
)。
这种情况下,Git 会使用它找到的每一个变量的最后一个配置。
你可以通过输入 git config <key>
: 来检查 Git 的某一项配置:
$ git config user.name
John Doe
由于 Git 会从多个文件中读取同一配置变量的不同值,因此你可能会在其中看到意料之外的值而不知道为什么。 此时,你可以查询 Git 中该变量的 原始 值,它会告诉你哪一个配置文件最后设置了该值:
|
获取帮助
若你使用 Git 时需要获取帮助,有三种等价的方法可以找到 Git 命令的综合手册(manpage):
$ git help <verb>
$ git <verb> --help
$ man git-<verb>
例如,要想获得 git config
命令的手册,执行
$ git help config
这些命令很棒,因为你随时随地可以使用而无需联网。
如果你觉得手册或者本书的内容还不够用,你可以尝试在 Freenode IRC 服务器 https://freenode.net 上的 #git
或 #github
频道寻求帮助。
这些频道经常有上百人在线,他们都精通 Git 并且乐于助人。
此外,如果你不需要全面的手册,只需要可用选项的快速参考,那么可以用 -h
选项获得更简明的 ``help'' 输出:
$ git add -h
usage: git add [<options>] [--] <pathspec>...
-n, --dry-run dry run
-v, --verbose be verbose
-i, --interactive interactive picking
-p, --patch select hunks interactively
-e, --edit edit current diff and apply
-f, --force allow adding otherwise ignored files
-u, --update update tracked files
--renormalize renormalize EOL of tracked files (implies -u)
-N, --intent-to-add record only the fact that the path will be added later
-A, --all add changes from all tracked and untracked files
--ignore-removal ignore paths removed in the working tree (same as --no-all)
--refresh don't add, only refresh the index
--ignore-errors just skip files which cannot be added because of errors
--ignore-missing check if - even missing - files are ignored in dry run
--chmod (+|-)x override the executable bit of the listed files
总结
你应该已经对 Git 是什么、Git 与你可能正在使用的集中式版本控制系统有何区别等问题有了基本的了解。 现在,在你的系统中应该也有了一份能够工作的 Git 版本。 是时候开始学习有关 Git 的基础知识了。
Git 基础
如果你只想通过阅读一章来学习 Git,那么本章将是你的不二选择。 本章涵盖了你在使用 Git 完成各种工作时将会用到的各种基本命令。 在学习完本章之后,你应该能够配置并初始化一个仓库(repository)、开始或停止跟踪(track)文件、暂存(stage)或提交(commit)更改。 本章也将向你演示了如何配置 Git 来忽略指定的文件和文件模式、如何迅速而简单地撤销错误操作、如何浏览你的项目的历史版本以及不同提交(commits)之间的差异、如何向你的远程仓库推送(push)以及如何从你的远程仓库拉取(pull)文件。
获取 Git 仓库
通常有两种获取 Git 项目仓库的方式:
-
将尚未进行版本控制的本地目录转换为 Git 仓库;
-
从其它服务器 克隆 一个已存在的 Git 仓库。
两种方式都会在你的本地机器上得到一个工作就绪的 Git 仓库。
在已存在目录中初始化仓库
如果你有一个尚未进行版本控制的项目目录,想要用 Git 来控制它,那么首先需要进入该项目目录中。 如果你还没这样做过,那么不同系统上的做法有些不同:
在 Linux 上:
$ cd /home/user/my_project
在 macOS 上:
$ cd /Users/user/my_project
在 Windows 上:
$ cd /c/user/my_project
之后执行:
$ git init
该命令将创建一个名为 .git
的子目录,这个子目录含有你初始化的 Git 仓库中所有的必须文件,这些文件是 Git 仓库的骨干。
但是,在这个时候,我们仅仅是做了一个初始化的操作,你的项目里的文件还没有被跟踪。
(参见 Git 内部原理 来了解更多关于到底 .git
文件夹中包含了哪些文件的信息。)
如果在一个已存在文件的文件夹(而非空文件夹)中进行版本控制,你应该开始追踪这些文件并进行初始提交。
可以通过 git add
命令来指定所需的文件来进行追踪,然后执行 git commit
:
$ git add *.c
$ git add LICENSE
$ git commit -m 'initial project version'
稍后我们再逐一解释这些指令的行为。 现在,你已经得到了一个存在被追踪文件与初始提交的 Git 仓库。
克隆现有的仓库
如果你想获得一份已经存在了的 Git 仓库的拷贝,比如说,你想为某个开源项目贡献自己的一份力,这时就要用到 git clone
命令。
如果你对其它的 VCS 系统(比如说 Subversion)很熟悉,请留心一下你所使用的命令是"clone"而不是"checkout"。
这是 Git 区别于其它版本控制系统的一个重要特性,Git 克隆的是该 Git 仓库服务器上的几乎所有数据,而不是仅仅复制完成你的工作所需要文件。
当你执行 git clone
命令的时候,默认配置下远程 Git 仓库中的每一个文件的每一个版本都将被拉取下来。
事实上,如果你的服务器的磁盘坏掉了,你通常可以使用任何一个克隆下来的用户端来重建服务器上的仓库
(虽然可能会丢失某些服务器端的钩子(hook)设置,但是所有版本的数据仍在,详见 在服务器上搭建 Git )。
克隆仓库的命令是 git clone <url>
。
比如,要克隆 Git 的链接库 libgit2
,可以用下面的命令:
$ git clone https://github.com/libgit2/libgit2
这会在当前目录下创建一个名为 “libgit2” 的目录,并在这个目录下初始化一个 .git
文件夹,
从远程仓库拉取下所有数据放入 .git
文件夹,然后从中读取最新版本的文件的拷贝。
如果你进入到这个新建的 libgit2
文件夹,你会发现所有的项目文件已经在里面了,准备就绪等待后续的开发和使用。
如果你想在克隆远程仓库的时候,自定义本地仓库的名字,你可以通过额外的参数指定新的目录名:
$ git clone https://github.com/libgit2/libgit2 mylibgit
这会执行与上一条命令相同的操作,但目标目录名变为了 mylibgit
。
Git 支持多种数据传输协议。
上面的例子使用的是 https://
协议,不过你也可以使用 git://
协议或者使用 SSH 传输协议,比如 user@server:path/to/repo.git
。
在服务器上搭建 Git 将会介绍所有这些协议在服务器端如何配置使用,以及各种方式之间的利弊。
记录每次更新到仓库
现在我们的机器上有了一个 真实项目 的 Git 仓库,并从这个仓库中检出了所有文件的 工作副本。 通常,你会对这些文件做些修改,每当完成了一个阶段的目标,想要将记录下它时,就将它提交到仓库。
请记住,你工作目录下的每一个文件都不外乎这两种状态:已跟踪 或 未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件,在上一次快照中有它们的记录,在工作一段时间后, 它们的状态可能是未修改,已修改或已放入暂存区。简而言之,已跟踪的文件就是 Git 已经知道的文件。
工作目录中除已跟踪文件外的其它所有文件都属于未跟踪文件,它们既不存在于上次快照的记录中,也没有被放入暂存区。 初次克隆某个仓库的时候,工作目录中的所有文件都属于已跟踪文件,并处于未修改状态,因为 Git 刚刚检出了它们, 而你尚未编辑过它们。
编辑过某些文件之后,由于自上次提交后你对它们做了修改,Git 将它们标记为已修改文件。 在工作时,你可以选择性地将这些修改过的文件放入暂存区,然后提交所有已暂存的修改,如此反复。
检查当前文件状态
可以用 git status
命令查看哪些文件处于什么状态。
如果在克隆仓库后立即使用此命令,会看到类似这样的输出:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
这说明你现在的工作目录相当干净。换句话说,所有已跟踪文件在上次提交后都未被更改过。 此外,上面的信息还表明,当前目录下没有出现任何处于未跟踪状态的新文件,否则 Git 会在这里列出来。 最后,该命令还显示了当前所在分支,并告诉你这个分支同远程服务器上对应的分支没有偏离。 现在,分支名是“master”,这是默认的分支名。 我们在 Git 分支 中会详细讨论分支和引用。
现在,让我们在项目下创建一个新的 README
文件。
如果之前并不存在这个文件,使用 git status
命令,你将看到一个新的未跟踪文件:
$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add <file>..." 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
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: README
只要在 Changes to be committed
这行下面的,就说明是已暂存状态。
如果此时提交,那么该文件在你运行 git add
时的版本将被留存在后续的历史记录中。
你可能会想起之前我们使用 git init
后就运行了 git add <files>
命令,开始跟踪当前目录下的文件。
git add
命令使用文件或目录的路径作为参数;如果参数是目录的路径,该命令将递归地跟踪该目录下的所有文件。
暂存已修改的文件
现在我们来修改一个已被跟踪的文件。
如果你修改了一个名为 CONTRIBUTING.md
的已被跟踪的文件,然后运行 git status
命令,会看到下面内容:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
文件 CONTRIBUTING.md
出现在 Changes not staged for commit
这行下面,说明已跟踪文件的内容发生了变化,但还没有放到暂存区。
要暂存这次更新,需要运行 git add
命令。
这是个多功能命令:可以用它开始跟踪新文件,或者把已跟踪的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态等。
将这个命令理解为“精确地将内容添加到下一次提交中”而不是“将一个文件添加到项目中”要更加合适。
现在让我们运行 git add
将“CONTRIBUTING.md”放到暂存区,然后再看看 git status
的输出:
$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
现在两个文件都已暂存,下次提交时就会一并记录到仓库。
假设此时,你想要在 CONTRIBUTING.md
里再加条注释。
重新编辑存盘后,准备好提交。
不过且慢,再运行 git status
看看:
$ vim CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
怎么回事?
现在 CONTRIBUTING.md
文件同时出现在暂存区和非暂存区。
这怎么可能呢?
好吧,实际上 Git 只不过暂存了你运行 git add
命令时的版本。
如果你现在提交,CONTRIBUTING.md
的版本是你最后一次运行 git add
命令时的那个版本,而不是你运行 git commit
时,在工作目录中的当前版本。
所以,运行了 git add
之后又作了修订的文件,需要重新运行 git add
把最新版本重新暂存起来:
$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: README
modified: CONTRIBUTING.md
状态简览
git status
命令的输出十分详细,但其用语有些繁琐。
Git 有一个选项可以帮你缩短状态命令的输出,这样可以以简洁的方式查看更改。
如果你使用 git status -s
命令或 git status --short
命令,你将得到一种格式更为紧凑的输出。
$ git status -s
M README
MM Rakefile
A lib/git.rb
M lib/simplegit.rb
?? LICENSE.txt
新添加的未跟踪文件前面有 ??
标记,新添加到暂存区中的文件前面有 A
标记,修改过的文件前面有 M
标记。
输出中有两栏,左栏指明了暂存区的状态,右栏指明了工作区的状态。例如,上面的状态报告显示:
README
文件在工作区已修改但尚未暂存,而 lib/simplegit.rb
文件已修改且已暂存。
Rakefile
文件已修改,暂存后又作了修改,因此该文件的修改中既有已暂存的部分,又有未暂存的部分。
忽略文件
一般我们总会有些文件无需纳入 Git 的管理,也不希望它们总出现在未跟踪文件列表。
通常都是些自动生成的文件,比如日志文件,或者编译过程中创建的临时文件等。
在这种情况下,我们可以创建一个名为 .gitignore
的文件,列出要忽略的文件的模式。
来看一个实际的 .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 的数字)。
使用两个星号(**
)表示匹配任意中间目录,比如 a/**/z
可以匹配 a/z
、 a/b/z
或 a/b/c/z
等。
我们再看一个 .gitignore
文件的例子:
# 忽略所有的 .a 文件
*.a
# 但跟踪所有的 lib.a,即便你在前面忽略了 .a 文件
!lib.a
# 只忽略当前目录下的 TODO 文件,而不忽略 subdir/TODO
/TODO
# 忽略任何目录下名为 build 的文件夹
build/
# 忽略 doc/notes.txt,但不忽略 doc/server/arch.txt
doc/*.txt
# 忽略 doc/ 目录及其所有子目录下的 .pdf 文件
doc/**/*.pdf
GitHub 有一个十分详细的针对数十种项目及语言的 |
在最简单的情况下,一个仓库可能只根目录下有一个 多个 |
查看已暂存和未暂存的修改
如果 git status
命令的输出对于你来说过于简略,而你想知道具体修改了什么地方,可以用 git diff
命令。
稍后我们会详细介绍 git diff
,你通常可能会用它来回答这两个问题:当前做的哪些更新尚未暂存?
有哪些更新已暂存并准备好下次提交?
虽然 git status
已经通过在相应栏下列出文件名的方式回答了这个问题,但 git diff
能通过文件补丁的格式更加具体地显示哪些行发生了改变。
假如再次修改 README 文件后暂存,然后编辑 CONTRIBUTING.md
文件后先不暂存,
运行 status
命令将会看到:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: README
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
要查看尚未暂存的文件更新了哪些部分,不加参数直接输入 git diff
:
$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
Please include a nice description of your changes when you submit your PR;
if we have to read the whole diff to figure out why you're contributing
in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.
If you are starting to work on a particular area, feel free to submit a PR
that highlights your work in progress (and note in the PR title that it's
此命令比较的是工作目录中当前文件和暂存区域快照之间的差异。 也就是修改之后还没有暂存起来的变化内容。
若要查看已暂存的将要添加到下次提交里的内容,可以用 git diff --staged
命令。
这条命令将比对已暂存文件与最后一次提交的文件差异:
$ git diff --staged
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+My Project
请注意,git diff 本身只显示尚未暂存的改动,而不是自上次提交以来所做的所有改动。
所以有时候你一下子暂存了所有更新过的文件,运行 git diff
后却什么也没有,就是这个原因。
像之前说的,暂存 CONTRIBUTING.md
后再编辑,可以使用 git status
查看已被暂存的修改或未被暂存的修改。
如果我们的环境(终端输出)看起来如下:
$ git add CONTRIBUTING.md
$ echo '# test line' >> CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: CONTRIBUTING.md
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
现在运行 git diff
看暂存前后的变化:
$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 643e24f..87f08c8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -119,3 +119,4 @@ at the
## Starter Projects
See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
+# test line
然后用 git diff --cached
查看已经暂存起来的变化( --staged
和 --cached
是同义词):
$ git diff --cached
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
Please include a nice description of your changes when you submit your PR;
if we have to read the whole diff to figure out why you're contributing
in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.
If you are starting to work on a particular area, feel free to submit a PR
that highlights your work in progress (and note in the PR title that it's
Git Diff 的插件版本
在本书中,我们使用 |
提交更新
现在的暂存区已经准备就绪,可以提交了。
在此之前,请务必确认还有什么已修改或新建的文件还没有 git add
过,
否则提交的时候不会记录这些尚未暂存的变化。
这些已修改但未暂存的文件只会保留在本地磁盘。
所以,每次准备提交前,先用 git status
看下,你所需要的文件是不是都已暂存起来了,
然后再运行提交命令 git commit
:
$ git commit
这样会启动你选择的文本编辑器来输入提交说明。
启动的编辑器是通过 Shell 的环境变量 |
编辑器会显示类似下面的文本信息(本例选用 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
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
# new file: README
# modified: CONTRIBUTING.md
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283C
可以看到,默认的提交消息包含最后一次运行 git status
的输出,放在注释行里,另外开头还有一个空行,供你输入提交说明。
你完全可以去掉这些注释行,不过留着也没关系,多少能帮你回想起这次更新的内容有哪些。
更详细的内容修改提示可以用 |
退出编辑器时,Git 会丢弃注释行,用你输入的提交说明生成一次提交。
另外,你也可以在 commit
命令后添加 -m
选项,将提交信息与命令放在同一行,如下所示:
$ git commit -m "Story 182: Fix benchmarks for speed"
[master 463dc4f] Story 182: Fix benchmarks for speed
2 files changed, 2 insertions(+)
create mode 100644 README
好,现在你已经创建了第一个提交!
可以看到,提交后它会告诉你,当前是在哪个分支(master
)提交的,本次提交的完整 SHA-1 校验和是什么(463dc4f
),以及在本次提交中,有多少文件修订过,多少行添加和删改过。
请记住,提交时记录的是放在暂存区域的快照。 任何还未暂存文件的仍然保持已修改状态,可以在下次提交时纳入版本管理。 每一次运行提交操作,都是对你项目作一次快照,以后可以回到这个状态,或者进行比较。
跳过使用暂存区域
尽管使用暂存区域的方式可以精心准备要提交的细节,但有时候这么做略显繁琐。
Git 提供了一个跳过使用暂存区域的方式,
只要在提交的时候,给 git commit
加上 -a
选项,Git 就会自动把所有已经跟踪过的文件暂存起来一并提交,从而跳过 git add
步骤:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: CONTRIBUTING.md
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 file changed, 5 insertions(+), 0 deletions(-)
看到了吗?提交之前不再需要 git add
文件“CONTRIBUTING.md”了。
这是因为 -a
选项使本次提交包含了所有修改过的文件。
这很方便,但是要小心,有时这个选项会将不需要的文件添加到提交中。
移除文件
要从 Git 中移除某个文件,就必须要从已跟踪文件清单中移除(确切地说,是从暂存区域移除),然后提交。
可以用 git rm
命令完成此项工作,并连带从工作目