[Remix]说文解字–计算机相关词汇–Git相关
(Remix)Explain and translate computer-related vocabulary
计算机中那些单词的故事——Git系列(一)
声明：本文可能更多本着挖掘历史和记录学习的感性角度，并没有具体关于 Git 的操作讲解，后续应该会有工作流相关研读，侧重学习理解、逻辑和实际应用场景。其中有一些感性认识，如果感兴趣请留言，有错误也请指正。
本篇文章着重 Git 发展历史，从历史场景了解版本控制系统演进，Git 作为分布式版本控制的特性以及Git基础概念–状态
✓ 0x00 Git 历史与简介
提到 Git 就离不开版本控制，版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。
[P.S] 抛离 Git，想想你交论文的时候每次写的version*.**，也有根据时间去区分的，时间能够描述顺序，想想如果老师跟你说我觉得还是你上上上次那哪天那次给我那版还不错，因为勤劳修改版本多的同学肯定是疯了，哈哈哈。
版本控制系统大致可以分为：
1.本地版本控制系统
问题：许多人习惯用复制整个项目目录的方式来保存不同的版本，或许还会改名加上备份时间以示区别。这么做唯一的
好处就是简单，但是特别容易犯错。有时候会混淆所在的工作目录，一不小心会写错文件或者覆盖意想外的文件。解决办法：应用某种简单的数据库来记录文件的历次更新差异。
2.集中化的版本控制系统
问题：如何让在不同系统上的开发者协同工作？于是，集中化的版本控制系统
（Centralized Version Control Systems，简称 CVCS）应运而生。解决办法：通过单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
3.分布式版本控制系统
问题：很明显，单一集中式管理，对集中管理产生了依赖，一旦集中管理出现问题，后果也是不堪设想。
如果中心数据库所在的磁盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历史，只剩下人们在各自机器上保留的单独快照。本地版本控制系统也存在类似问题，只要整个项目的历史记录被保存在单一位置，就有丢失所有历史更新记录的风险。
解决办法：分布式版本控制系统（Distributed Version Control System，简称 DVCS）能够完美解决集中管理系统的问题。像_Git_、Mercurial、Bazaar 以及 Darcs 等。客户端并不只提取最新版本的文件快照，而是把代码仓库完整地镜像下来。这么一来，任何一处协同工作用的服务器发生故障，事后都可以用任何一个镜像出来的本地仓库恢复。因为每一次的克隆操作，实际上都是一次对代码仓库的完整备份.
[P.S] 其实版本控制的历史和互联网的应用服务发展很像，从单体，集中式到分布式。直觉上，很多东西是相通的，很有意思，为了办成一件事，条件不够就创造条件。首先，在单机时，要考虑变化的维度，出现了本地版本控制；后来，为了合作，需要大家在同一个空间进行交互，增加了中心管理维度，产生了集中式版本管理。为了保证本机也会有远端的版本，本地复制了远端完整备份，也就是增加了本地备份远端的维度，这样就算远端一时挂掉，本地也会有个本地同步远端时刻的状态可以供本地基于此状态进行修改。
Git相比其他版本控制系统的优势
1.Git 直接记录快照，而非差异比较
Git 和其它版本控制系统（包括 Subversion 和近似工具）的主要差别在于 Git对待数据的方法。概念上来区分，其它大部分系统以文件变更列表的方式存储信息。这类系统（CVS、Subversion、Perforce、Bazaar 等等）将它们保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异。
Git 更像是把数据看作是对小型文件系统的一组快照。每次你提交更新，或在 Git 中保存项目状态时，它主要对当时的全部文件制作一个快照并保存这个快照的索引。为了高效，如果文件没有修改，Git 不再重新存储该文件，而是只保留一个链接指向之前存储的文件。Git 对待数据更像是一个快照流。
这是 Git 与几乎所有其它版本控制系统的重要区别。Git 考虑了以前每一代版本控制系统延续下来的诸多方面。
[P.S] 怀疑因为 Linus 社区中大牛都是精通系统编程，Git 上有很多系统编程的极客技术的影子
2.Git 近乎所有操作都是本地执行
在 Git 中的绝大多数操作都只需要访问本地文件和资源，一般不需要来自网络上其它计算机的信息。
Git 不需外连到服务器去获取历史，然后再显示出来——它只需直接从本地数据库中读取。你能立即看到项目历史。如果你想查看当前版本与一个月前的版本之间引入的修改，Git 会查找到一个月前的文件做一次本地的差异计算，而不是由远程服务器处理或从远程服务器拉回旧版本文件再来本地处理。
[P.S] 确切的说，本地数据库保存了同步远端数据库的状态。
3.Git 保证完整性
Git 中所有数据在存储前都计算校验和，然后以校验和来引用。这意味着在 Git 会记录所有任何时刻对任何文件内容或目录内容更改，这也是 Git 的哲学。若你在传送过程中丢失信息或损坏文件，Git 也能发现。
Git 用以计算校验和的机制叫做SHA-1散列（hash，哈希）。这是一个由40个十六进制字符（0-9 和 a-f）组成字符串，基于Git 中文件的内容或目录结构计算出来。Git 数据库中保存的信息都是以文件内
容的哈希值来索引，而不是文件名。24b9da6552252987aa493b52f8696cd6d3b00373
Git 数据库中保存的信息都是以文件内容的哈希值来索引，而不是文件名。
4.Git 一般只添加数据
执行 Git 操作，几乎只往 Git 数据库中增加数据。很难让 Git 执行任何不可逆操作，或者让它以任何方式清除数据。同别的 VCS 一样，未提交更新时有可能丢失或弄乱修改的内容；但是一旦你提交快照到 Git 中，就难以再丢失数据，特别是如果你定期的推送数据库到其它仓库的话。
[P.S] Git 和系统编程的极客和大牛脱不开关系
Git本地的三种状态
Git 有三种状态，你的文件可能处于其中之一：已提交（committed）、已修改（modified）和已暂存（staged）。已提交表示数据已经安全的保存在本地数据库中。已修改表示修改了文件，但还没保存到数据库中。已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次提交的快照中。
有状态变量就会有状态空间，Git项目的三个工作区域的概念：工作目录、Git仓库以及暂存区域。
工作目录是对项目的某个版本独立提取出来的内容。这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改。
暂存区域是一个文件，保存了下次将提交的文件列表信息，一般在 Git 仓库目录中。有时候也被称作”索引“，不过一般说法还是叫暂存区域
Git仓库目录是 Git 用来保存项目的元数据和对象数据库的地方。这是 Git 中最重要的部分，从其它计算机克隆仓库时，拷贝的就是这里的数据。
基本的Git工作流程如下：
- 在工作目录中修改文件。
- 暂存文件，将文件的快照放入暂存区域。
- 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。
如果 Git 目录中保存着的特定版本文件，就属于已提交状态。如果作了修改并已放入暂存区域，就属于已暂存状态。如果自上次取出后，作了修改但还没有放到暂存区域，就是已修改状态。
[P.S] 虽然本地仓库与远端仓库不是实时同步，但是能够作为本地与远端通信的代理。
✓ 0x01 Git 中的单词 (附)
git --help
add – Add file contents to the index
bisect – Find by binary search the change that introduced a bug
branch – List, create, or delete branches
checkout – Checkout a branch or paths to the working tree
clone – Clone a repository into a new directory
commit – Record changes to the repository
diff – Show changes between commits, commit and working tree, etc
fetch – Download objects and refs from another repository
grep – Print lines matching a pattern
init – Create an empty Git repository or reinitialize an existing one
log – Show commit logs
merge – Join two or more development histories together
mv – Move or rename a file, a directory, or a symlink
pull – Fetch from and merge with another repository or a local branch
push – Update remote refs along with associated objects
rebase – Forward-port local commits to the updated upstream head
reset – Reset current HEAD to the specified state
rm – Remove files from the working tree and from the index
show – Show various types of objects
status – Show the working tree status
tag – Create, list, delete or verify a tag object signed with GPG
参考文献
[1] Scott Chacon, Ben Straub Pro Git (Second Edition) [M]. Apress
[2] Manual of Git
