本文基于Pro.Git.2nd版本的一个读书笔记，鉴于之前的笔记，不堪入目，老男人只能重新来过，争取用一个月的时间，完成该读书笔记，一般是周末更新或不定期更新。
1.1 版本控制
版本控制系统，可记录项目文件的变化，因此可检索特定的项目版本，
本地化的版本控制系统
大多数人能够想到的版本控制方式，拷贝一个项目的完整副本，这种方式很简单，也容易引发错误，比如忘记项目副本的保存位置，或是不经意之间，在副本中，放入了错误的文件，因此开发了本地化的版本控制系统，并使用数据库，来保存项目版本的变化。
此时最流行的VCS工具为RCS，直到今天还在使用，RCS可保存一个补丁集合（特殊格式），基于这些补丁，可获取项目的不同版本。
中心式版本控制系统
之后遇到的一个主要问题，协作开发，中心式版本控制系统(CVCSs)可解决这类问题，这些系统(CVS,Subversion,Perforce)将包含一个服务器，其中保存着项目的不同版本，而多个客户端可登录服务器，修改项目文件，这一度变成版本控制的标准流程。
相对于本地化的VCS（版本控制系统），管理员无需理会每个客户端的本地数据库，只需要管理服务器，同样CVCSs也存在缺陷，如果服务器一旦停机，所有人都无法工作，或者服务器的硬盘损坏，又没有备份，开发项目将全部丢失，本地VCS也存在相同的问题，如果开发项目只有一个存储位置，就存在全部丢失的风险
分布式版本控制系统
在分布式版本控制系统(DVCS)中，比如Git,Mercurial,Bazaar和Darcs，客户端需要镜像服务器的所有数据，即使服务器停机，客户端之间也能进行协作，客户端的所有数据，还可重新复制回服务器。
这些DVCS都支持多个远程仓库的协同，以及分组的开发协作，并能够使用多种方法，实现项目数据的同步，也能够提供不同的工作流，比如分层模式。
1.2 Git简史
linux内核是一个巨大的开源软件项目，在1991-2002年间，linux内核的维护，基本靠补丁和归档文件，从2002年开始，linux内核项目使用了一个收费的DVCS工具BitKeeper，直到2005年，linux内核开发社区与BitKeeper的关系破裂，导致BitKeeper收回了免费使用权，而linux开发社区不得不基于BitKeeper的使用经验，开发一个属于自己的版本控制系统，新系统必须具备以下特性，
* 速度
* 设计简单
* 支持非线性开发（允许上千个并行分支）
* 分布式
* 高效管理大型项目，比如Linux内核
自2005年诞生以来，Git不断改进，增强易用性，依旧保持初心，比如快速，大型项目的高效管理，强大的分支系统。
1.3 Git基础
理解Git的工作原理，有助于Git的高效使用，而其他VCS（CVS,SubversionPerforce）的使用经验，无助于Git的使用，甚至会产生一些混乱，了解不同系统之间的差异，可避免混乱。
快照记录
Git和其他VCS的主要区别，Git只关注数据，而其他VCS则关注变更信息的保存，类似一个基于文件的变更列表，这些VCS（(CVS, Subversion, Perforce, Bazaar等）会保存一个文件集合，以及基于时间的文件变更，因此又称为渐变式（delta-based）版本控制。
Git会将数据，视为一组快照，每当用户完成提交，或是保存项目状态后，Git都会记录此刻的项目状态，为了实现高性能，未被修改的文件，不会再次保存，而是生成一个链接，因此称之为快照流，
完美的本地操作
Git只需本地资源，就能完成大多数操作，无需联网，而CVCS（中心式VCS）的大多数操作，都存在网络开销，因为在Git中，整个项目的开发数据，已镜像到本地磁盘，所以大多数操作可瞬间完成。比如无需链接服务器，就能查找项目的历史记录，如果用户想了解不同项目版本的差异，Git可基于本地数据库，列出相关的差异，而无需链接远程服务器，获取之前的项目版本。另外有个小问题，当用户处于离线状态，依然可以将修改，提交到本地数据库，之后在使用网络连接，推送到远程服务器，所以无需联网，用户也能进行版本控制，这在其他VCS中，是不可思议的艰巨任务，在离线状态下， Subversion和CVS只提供文件编辑，而无法提交（提交的意义在于，将开发或修改，纳入到版本控制中）。
数据的完整性
Git的每次存储，都会给出一个校验，以标识文件或目录的变更，这是创造Git的初始目标之一，所有的传输错误和文件损坏，都能被发现，Git校验机制为SHA1编码，一共40个字符，使用16进制表示（40*4,160bit），比如24b9da6552252987aa493b52f8696cd6d3b00373，事实上Git存入数据库的文件，并未使用文件名进行区分，而是SHA1哈希值。
添加数据
Git的大多数操作，只是将数据添加到数据库，而撤销操作或清除数据的任务，会相当困难，但与其他VCS一样，用户可以丢弃或清除，未提交的变更，如果数据一旦提交给Git，数据的清除，则相当困难，尤其是，定期推送到远程仓库的数据，基于上述机理，Git具备更好的抗风险能力，同时也更易完成数据的恢复。
数据的三种状态
Git为项目文件，提供了三种状态，已提交（committed），已修改（modified）和已暂存（staged），
- 已提交是指，数据已保存到本地数据库
- 已修改是指，文件已修改，但未提交到本地数据库
- 已暂存是指，标记一个已修改文件，可进行提交
Git项目有三个组成部分，Git仓库目录(Git repository directory)，工作目录(working directory)，暂存区(staging area)，
Git目录可保存开发项目的原始数据和对象数据库，这是最重要的部分，用户可将该目录，克隆到其他计算机，工作目录可从Git目录中，获取某个项目版本，并放入本地磁盘，以供后续开发，暂存区是一个文件，通常保存在Git目录中，其中包含了下一次提交的相关信息，而Git称其为索引（index）。基本的Git工作流如下，
- 在工作目录中，修改文件
- 挑选已完成的变更，放入暂存区，等待下一次提交
- 将暂存区的变更，提交到Git目录，即保存一次项目快照
1.4 安装Git
命令行
Git的用法有很多方式，最基本的方法，使用命令行，当然也存在功能不一的图形界面，这里只使用命令行，因为命令行可以运行所有的Git命令，而图形界面只能提供Git命令的一个子集，同时图形界面不够直观，无法给出完整的信息。
安装Git
在使用Git之前，需要安装，或是升级到最新版本，本书对应的Git版本为2.8.0，用户可选择安装包，或是下载源码包进行编译，
linux安装
在linux中，可选择Git安装包，或者通过包管理工具，如果是基于RPM的发行版本，比如Fedora，RHEL，CentOS，
$ sudo dnf install git-all
如果是基于Debian的发行版本，比如Ubuntu，
$ sudo apt install git-all
更多细节，可参考https://git-scm.com/download/linux，注，译者尝试上述安装方法，发现会装入很多垃圾，因此建议安装最简版本，sudo apt install git，如果需要其他扩展，后续再单独安装。
macOS安装
（略）
Windows安装
（略）
源码包安装
（略）
1.5 初始配置
在运行Git之前，首先需要配置Git运行环境，当然只需配置一次，而后续的版本更新，则无需重新配置，同时使用命令，也可以修改配置，Git的配置工具为git config，它可获取和设定配置变量，这些变量保存在三个位置，
- /etc/gitconfig，优先级最低，对于系统的所有用户和仓库，都有效，如果git config添加–system选项，可读写该文件，因为这是一个系统配置文件，用户需要获得管理员或超级用户的权限，才能修改它。
- ~/.gitconfig或~/.config/git/config，用户配置，使用–global选项，可使Git读写这些文件，并会影响到，用户进入的所有本地仓库。
- Git目录的config文件（比如.git/config,优先级最高），即用户进入的当前仓库，使用–local选项，Git可读写这类文件，同时该选项也是缺省参数
这三类文件存在优先级，可相互覆盖，比如.git/config可覆盖/etc/gitconfig，在Windows系统中，Gilt将$HOME（通常是C:\Users\$USER）目录中，查找.gitconfig，基于MSys的根目录（即安装Git的目录），还可查找/etc/gitconfig，如果Git使用2.x或更高的Windows版本，还能包含系统级的配置文件（XP路径为C:\Documents and Settings\All Users\Application Data\Git\config，Vista或更高版本的路径为C:\ProgramData\Git\config），管理员可使用git config -f ，修改上述配置文件的存储位置，使用git config --list --show-origin，可查看上述配置文件，提供的所有配置数据。
用户标识
首先设定用户的名称和邮件地址，每次Git提交，都将附带这些信息，比如，
$ git config --global user.name “John Doe”
$ git config --global user.email [email protected]
由于上述信息属于当前用户，所以使用了–global选项，如果某个特定项目，需要特定的用户名和邮件地址，可省略选项，等同于使用–local选项，为当前项目，设定特殊的用户名和邮件地址。
文本编辑器
配置一个默认的文本编辑器，当Git需要用户输入文本时，将自动开启文本编辑器，如果不设置，Git将使用系统的默认编辑器，如果将Emacs指定为默认编辑器，可使用，
$ git config --global core.editor emacs
在Windows系统中，指定文本编辑器，需提供完整的路径，比如Notepad++，最好选择32bit版本，因为64bit版本还无法支持所有的插件，如下，假定Windows为32bit系统，
$ git config --global core.editor “‘C:/Program Files/Notepad++/notepad++.exe’ -multiInst -nosession”
如果Windows为64bit系统，指定一个32bit的文本编辑器，需使用，
$ git config --global core.editor “‘C:/Program Files (x86)/Notepad++/notepad++.exe’ -multiInst -nosession”
确认配置
使用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
…
三个config文件之间存在覆盖关系，Git只会选择优先级最高的配置，使用配置名称，也可查看Git的特定配置，比如，
$ git config user.name
John Doe
由于Git能读取三个配置文件，所以可能会出现未预期的配置数据，使用–show-origin选项，将显示，特定配置的最终设定来自哪个配置文件，以及配置数据
$ git config --show-origin rerere.autoUpdate
file:/home/johndoe/.gitconfig false
1.6 获取帮助
当需要帮助时，可使用两种方式，获取Git命令的帮助说明，
$ git help <verb>
$ man git-<verb>
比如，获取git config的帮助
$ git help config
即使在离线状态下，用户也可获得上述帮助，如果问题依然存在，可登录Freenode IRC服务器（https://freenode.net）的#git或#github频道，用户能找到数百个Git达人，向他们寻求帮助，另外在实际应用中，用户未必需要一个完整的帮助说明，这时可在help命令中，添加-h或–help选项，用户将得到一个简单的帮助说明。
