【Git】版本控制管理(第二版) 前言 第一章 第二章

资源

Git版本控制管理 第2版 （美）罗力格（美）麦卡洛著.pdf
密码:esjj

前言

• 本书读者
  本书假定读者熟悉并使用过UNIX shell.基本的shell命令，以及通用的编程概念。
• 假定的框架
  书中有少量示例需要用到root权限,此时，你自然应该能清楚理解root权限的职责。

本书结构

本书是按照一系列渐进式主题进行组织编排的，每一个主题都建立在之前介绍的概念之上。本书前11章讲解的是与一个版本库相关的概念和操作，这些内容是在多个版本库上进行复杂操作（将在本书后10章涉及）的基础。
如果你已经安装了 Git,甚至曾经简单使用过，那么你可能用不到前两章中Git相关的介绍性知识和安装信息。
第3章的知识对你来说也是可有可无。
第4章介绍的概念是深入掌握Git对象模型的基础，读者可以通过第4章清楚理解Git 更为复杂的操作
第5章〜第11章更为详细地讲解了 Git的各个主题。
第5章讲解了索引和文件管理。
第6章〜第10章讨论了生成提交和使用提交来形成坚实的开发路线的基础。
第7章介绍了分支，你可以在一个本地版本库中使用分支操作多条不同的开发路线。
第8章解释了diff的来历和使用。
Git提供了丰富、强大的功能来加入到开发的不同分支。第9章介绍了合并分支和解决分支冲突的基础。对Git模型的个关键洞察力是意识到Git执行的所有合并是发生在当前工作目录上下文的本地版本库中的。第10章和第11章讲解了在开发版本库内进行更改、储藏、跟踪和恢复日常开发的操作。
第12章讲解了命名数据以及与另外一个远程版本库交换数据的基础知识一旦掌握了合并的基础知识，与多个版本库进行交互就变成了一个交换步骤加一个合并步骤的简单组合。交换步骤是第12章中新出现的概念，而合并步骤则是在第9章讲解的.
第13章则从哲学角度对全局的版本库管理提供了抽象的讲解：它还为第14章建立了 一个环境，使得使用Git原生的传输协议无法直接交换版本库信息时，能够打补丁。
接下来的4章则涵盖了一些有意思的高级主题：使用钩子（第15章）、将项目和多个版本库合并到一个超级项目中（第16章），以及与SVN版本库进行交互（第17章、 第18章）。
第19章和第20章提供了一些更为高级的示例和提示、技巧、技术，从而使你成为真正的Git大师。
最后，第21章介绍了 GitHub,并解释了 Git如何围绕着版本控制开启了一个有创造力的社会发展进程。

此外，读者应该熟悉基本的shell命令，以用来操作文件和目录。许多示例会包含一些命令，来完成添加/删除目录、复制文件和创建简单的文件等操作。

$ cp file.txt copy-of-file.txt//拷贝file.txt为新文件copy-of-file.txt
$ mkdir newdirectory
$ rm file
$ rmdir somedir
$ echo "Test line" > file//把字符串追加输入到文件中
$ echo "Another line" >> file

第一章 介绍

总结在开头

术语总结

术语名字	英文名字	术语介绍	作用和影响
源代码控制系统	(Source Code Control System, SCCS )	运行在UNIX系统上的最早的VCS。	SCCS提供的数据存储中心称为“版本库"(repository),而这个基本概念一直沿用至今。提供了一个简单的锁模型来保证开发过程有序
安全散列函数	（SHA1）	通用加密散列函数	来命名和识别数据库中的对象。用散列指纹来唯一标识文件的内容，Git沿用了这个概念。从内部实现上来说，Git的文件标识符基于文件的内容，这是一个叫做“内容可寻址文件存储”(Content Addressable File Store, CAFS )的概念。
修订控制系统	(Revision Control System, RCS)	由 Walter F. Tichy 于 20 世纪 80 年代早期引入	RCS引入了双向差异的概念，来提高文件不同版本的存储效率
并行版本系统	(Concurrent Version System, CVS)	由Dick Grune于1986年设计并最初实现。由Dick Grune于1986年设计并最初实现。CVS变得非常流行，并且成为开源社区(http:www.opensource.org )许多年的事实标准。	CVS相对RCS有多项优势，包括分布式开发和版本库范围内对整个“模块”的更改集。 此外，CVS引入了一个关于“锁”的新范式。CVS给予每个开发人员对于自己的私有版本写的权限。 因此，不同开发人员的改动可以自动合并。
版本控制系统	Subversion (SVN )	SVN于2001年问世，迅速风靡了开源社区。	不像CVS, SVN以原子方式提交改动部分，并且更好地支持分支。
BitKeeper和Mercurial	淘汰了中心版本库的概念， 取而代之的，数据的存储是分布式的，每个开发人员都拥有自己可共享的版本库副本。 Git也是这种**端点对端点(Peer to Peer)**的模型。

1.1 背景

在整个工作中持续性地备份和存档是非常明智的。
对于文本和代码项目，备份策略通常包括版本控制，或者叫**“对变更进行追踪管理”。 每个开发人员每天都会进行若干个变更。这些持续增长的变更，加在一起可以构成一个版本库**，用于项目描述，团队沟通和产品管理。版本控制具有举足轻重的作用，只要定制好工作流和项目目标，版本控制是最高效的组织管理方式。

一个可以管理和追踪软件代码或其他类似内容的不同版本的工具，通常称为：版本控制系统（VCS ）,或者源代码管理器（SCM ）,或者修订控制系统（RCS）,或者其他各种和“修订”、“代码”、“内容”、“版本”、“控制”、“管理”和“系统” 等相关的叫法。

每个 工具都出于同样的目的：开发以及维护开发出来的代码、方便读取代码的历史版本、记录所有的修改。在本书中，“版本控制系统”（VCS）一词就是泛指一切这样的工具。

Git这款功能强大、灵活而且低开销的VCS,它可以让协同开发成为一种乐趣Git由Linus Torvalds发明，起初是为了方便管理Linux内核的开发工作。

1.2 Git的诞生

通常来说，当工具跟不上项目需求时，开发人员就会开发一个新的工具.
如果有着充分的需求、理性的洞察以及良好的动机，则完全可以创造一个新的VCS。

那么，这些已经存在的VCS到底存在什么缺陷？ Linus没能在现有VCS中找到的有关特性到底是哪些？让我们来看看。

• 有助于分布式开发
  分布式开发有很多方面，Linus希望有一个新的VCS能够尽可能覆盖这些方面， 它必须允许并行开发，各人可以在自己的版本库中独立且同时地开发，而不需要 与一个中心版本库时刻同步（因为这样会造成开发瓶颈）.它必须允许许多开发人 员在不同的地方，甚至是离线的情况下，无障碍地开发。
• 能够胜任上千开发人员的规模
• 性能优异
• • 不管是个人的更新操作，还是网络传输操作，都需要保证执行速度。为了节约存储空间，从而节约传输时间，需要使用“压缩”和“差异比较”技术。另外，使用分布式开发模型，而非集中式模型，同样也确保了网络的不确定因素不会影响到日常开发的效率。
• 保持完整性和可靠性
• • Git使用一个叫做**“安全散列函数”（SHA1）的通用加密散列函数**，来命名和识别数据库中的对象。虽然也许理论上不是绝对的，但是在实践中，已经证实这是足够可靠的方式。
• 强化责任
• • 版本控制系统的一个关键方面，就包括能够定位谁改动了文件，甚至改动的原因。Git对每一个有文件改动的提交（Git把一个历史版本叫做一个“提交”）强制使用“改动日志”，“改动日志”中存储的信息由开发人员、项目需求、管理策略等决定。Git 确保被VCS管理的文件不会被莫名地修改，因为Git可以对所有的改动进行责任追踪。
• 不可变性
• • Git数据库的设计同时也意 味着存储在版本数据库中的整个历史也是不可变的。使用不可变的对象有诸多优势，包括快速比较相同性。（VSCODE也有这样的功能？）
• 支持并且鼓励基于分支的开发
• • 几乎所有的VCS都支持在同一个项目中存在多个“支线例如，代码变更的一 条支线叫做“开发”，而同时又存在另一条支线叫做“测试”。每个VCS同样可以 将一条支线分叉为多条支线，在以后再将差异化后的支线合并。就像大多数VCS 一样，Git把这样的支线叫做“分支”，并且给每个分支都命名。
    伴随着分支的就是合并，Linus不仅希望通过简单的分支功能来促进丰富的开发 分支，还希望这些分支的合并可以变得简单容易。因为通常来说，分支的合并是各VCS使用中最为困难和痛苦的操作，所以，能够提供一个简单、清晰、快速的合并功能，是非常必要的。
• 完整的版本库
• • 为了让各个开发人员不需要查询中心服务器就可以得到历史修订信息，每个人 版本库中都有一份关于每个文件的完整历史修订信息就非常重要。
• 一个清晰的内部设计
• • Git的对象模型拥有者简单的结构，并且能够保存原始数据最基本的部分和目录结构，能够记录变更内容等。再将这个对象模型和全局唯一标识符技术相结合，便可以得到一个用于分布式开发环境中的清晰数据对象。

1.3 先例

源代码控制系统(Source Code Control System, SCCS )是UNIX上最初的几个系统之一。这是有证可查的可以运行在UNIX系统上的最早的VCS。
SCCS提供的数据存储中心称为“版本库"(repository ),而这个基本概念一直沿用至今， SCCS同样提供了一个简单的锁模型来保证开发过程有序。如果一个开发人员需要运行或者测试一个程序，他需要将该程序解锁并检出。然而，如果他想修改某个文件，他则需要锁定并检出(通过UNIX文件系统执行的转换)。当编辑完成以后，他又可以将文件检入到版本库中并解锁它。
修订控制系统(Revision Control System, RCS )由 Walter F. Tichy 于 20 世纪 80 年代早期引入[“RCS: A System fbr Version Control,” Software Practice and Experience 15(7) (1985): 637-654.]0 RCS引入了双向差异的概念，来提高文件不同版本的存储效率。
并行版本系统(Concurrent Version System, CVS )由Dick Grune于1986年设计并最初实现。CVS变得非常流行，并且成为开源社(http:www.opensource.org )区许多年的事实标准。 CVS相对RCS有多项优势，包括分布式开发和版本库范围内对整个“模块”的更改集。 此外，CVS引入了一个关于“锁”的新范式。而之前的系统需要开发人员在修改某个文件之前先锁定它，一个文件同时只允许一个开发人员进行修改，所有需要修改这个文件的开发人员需要有序等候。CVS给予每个开发人员对于自己的私有版本写的权限。 因此，不同开发人员的改动可以自动合并，除非两个开发人员尝试修改同一行。如果出现修改同一行的情况，那这一行将会作为“冲突”被标记出来，由开发人员手动去解决。这个关于“锁”的新规则使得多个开发人员可以并行地编写代码。
Subversion (SVN ) SVN于2001年问世，迅速风靡了开源社区。不像CVS, SVN以原子方式提交改动部分，并且更好地支持分支。
BitKeeper和Mercurial则彻底抛弃了上述所有解决方案。它们淘汰了中心版本库的概念， 取而代之的，数据的存储是分布式的，每个开发人员都拥有自己可共享的版本库副本。 Git也是这种端点对端点(Peer to Peer)的模型。
最后，Mercurial和Monotone首创了用散列指纹来唯一标识文件的内容，Git沿用了这个概念。从内部实现 上来说，Git的文件标识符基于文件的内容，这是一个叫做“内容可寻址文件存储”(Content Addressable File Store, CAFS )的概念。

1.4 时间线

Git于2005年 4月诞生了。
4月7日，Git从以下提交起，正式成为自托管项目。
不久之后，Linux内核的第一个提交也诞生了。
这一次提交将整个Linux内核导入Git版本库中’。这次提交的统计信息如下：
17291 files changed, 6718755 insertions(+), 0 deletions(-)
是的，这次提交足足引入了 670万行代码！
仅仅过了 3个小时，Linux内核第一次用Git打上了补丁。Linus在2005年4月20日 向Linux内核邮件列表正式宣布，用上Git了 !
大概两个月以后，版本号为2.6.12的Linux内核正式发布，所用VCS正是Git。
其中最受欢迎的一 就是：全局信息追踪器(Global Information Tracker )

第二章 安装Git

2.1 使用Linux上的二进制发行版

Linux厂商提供预编译的二进制包，以便于安装新的应用程序、工具和实用程序。

2.1.1 Debian/Ubuntu

在大多数Debian和Ubuntu系统中，Git是很多包的集合，其中的每个包都可以根据需 要独立安装。在12.04版本前，Git的主要包称为git-core。当12.04版本时，则简称为git, 而且相关义档则存在git-doc中。当然还有其他不同的包可使用。
git-arch
git-cvs
git-svn
如果你需要将一个项目从Arch、CVS或者SVN转变为Git,或者反过来，则需要 安装一个或多个以上这些包。
git-gui
gitk
gitweb
如果你更倾向于在图形界面的应用程序或者Web浏览器上浏览你的版本库，那就 适当安装这些包。git-gui是Git的一种基于Tcl/Tk的图形用户界面；gitk是另一 种用Tcl/Tk编写的但更侧重于项目历史可视化的Git浏览器。gitweb则是用Perl 写的，用于在浏览器里显示Git版本库。
git-daemon-run
安装这个包，就能共享你的版本库。它建立了一个守护进程服务，使你能够通过接受匿名下载请求的方式来共享你的版本库。
警告
Debian和Ubuntu提供了 一个叫git的包，但它并属于本书讨论的Git版本控制系统。git是一个完全不同的程序，称为**GNU交互工具(GNU
Interactive Tools)**小心不要意外安装了错误的包!

2.1.2其他发行版

为了在其他Linux发行版上安装Git,要找到合适的包，并用该发行版原生的包管理器来安装。
在Gentoo系统中，使用emerge命令。
在Fedora中，使用yum命令。
Fedora的git大致上相当于Debian的gito其他i386 Fedora软件包包括以下儿令。
git.i386Git的核心工具。
git-all.i386用来获取其他Git工具的元软件包。
git-daemon.i386：Git协议守护进程。
git-debuginfo.i386：git包的调试信息。
git-gui.i386：Git的GUI工具。
git-svn.i386：用来导入SVN库的Git工具。
gitk.i386：Git版本树可视化工具。

2.2 获取源代码

想从官方来源下载Git代码，或者想要最新版本的Git,可以访问Git的主版本库。

$ wget http://git-core.googlecode.com/files/git-1.7.9.tar.gz
$ tar xzf git-1.7.9.tar.gz
$ cd git-1.7.9

2.4 在 Windows 上安装 Git

Windows上有两种互相竞争的Git包:基于Cygwin的Git和称为“原生”版本的msysGit。
最初，只支持Cygwin版本的Git,而msysGit是实验版而且不稳定，但是在本书出版之时，两种版本都已经可以很好地运行并支持几乎同样的功能。但是Gitl.6.0版本中，有个非常重要的例外：msysGit尚未完全正确支持git-svn功能“如果需要在Git和SVN之间交互操作，那么必须使用Cygwin版本的Git。除此之外，可以按个人的偏好选择 所用的版本。

• 如果你已经在Windows上使用Cygwin 了，就使用Cygwin版本的Git,因为这样它可以与Cygwin的设置的交互操作得更好。比如，所有Cygwin风格的文件名会适用于Git,重定向程序的输入、输出会始终完全按预期工作。
• 如果没有使用Cygwin,那么msysGit的安装更加容易，因为它有自己的独立安装程序。
• 如果想让Git集成在Windows资源管理器shell中（比如，在一个文件夹右击并选 择Git GUI Here或Git Bash Here命令）,就安装msysGit。如果你想要这个功能但是更喜欢使用Cygwin,那你可以两个都安装，这不会造成损害。

2.4.2 安装独立的 Git (msysGit）

在Windows系统上很容易安装msysGit ,因为该安装包已包含它所有的依赖关系。它甚至有Secure Shell （ SSH ）命令来生成版本库维护者需要的控制访问权限的密钥。msysGit能很好地与Windows风格的原生应用程序（如Windows资源管理器shell）集成。
该通知涉及Windows风格和UNIX风格的换行符（即CRLF和LF ）之间的不兼容性。
勾选如图2-5所示那两个相关的复选框。

• Add "Git Bash Here"
• Add "Git GUI Here"