本篇博客部分来自pro git 和廖雪峰的gitl教程
版本控制
-
本控制系统（VCS version control system）
是一种记录一个或若干文件内容变化，
以便将来查阅特定版本修订情况的系统。 在本书所展示的例子中，我们对保存着软件源代码
的文件作版本控制，但实际上，你可以对任何类型的文件进行版本控制。 -
. 本地版本控制
其中最流行的一种叫做 RCS，现今许多计算机系统上都还看得到它的踪影。 甚至在流行的
Mac OS X 系统上安装了开发者工具包之后，也可以使用 rcs 命令。 它的工作原理是在硬盘
上保存补丁集（补丁是指文件修订前后的变化）；通过应用所有的补丁，可以重新计算出各
个版本的文件内容。
- 集中化的版本控制系统
为协同工作开发的版本
控制系统统（Centralized Version Control Systems，简称 CVCS）应运而生。 这类系统，诸如
CVS、Subversion 以及 Perforce 等，都有一个单一的集中管理的服务器，保存所有文件的修
订版本，而协同工作的人们都通过客户端连到这台服务器，取出最新的文件或者提交更新。
多年以来，这已成为版本控制系统的标准做法。 - 缺点：。 这么做最显而易见的缺点是中央服务器的单点故障。。 如果宕机一小
时，那么在这一小时内，谁都无法提交更新，也就无法协同工作。 如果中心数据库所在的磁
盘发生损坏，又没有做恰当备份，毫无疑问你将丢失所有数据——包括项目的整个变更历
史，只剩下人们在各自机器上保留的单独快照。
分布式版本控制系统
于是分布式版本控制系统（Distributed Version Control System，简称 DVCS） 。 在这
类系统中，像 Git、Mercurial、Bazaar 以及 Darcs 等，客户端并不只提取最新版本的文件快
照，而是把代码仓库完整地镜像下来。 这么一来，任何一处协同工作用的服务器发生故障，
事后都可以用任何一个镜像出来的本地仓库恢复。 因为每一次的克隆操作，实际上都是一次
对代码仓库的完整备份。 因为每一次的克隆操作，实际上都是一次
对代码仓库的完整备份。
Git 简史
同生活中的许多伟大事物一样，Git 诞生于一个极富纷争大举创新的年代。
Linux 内核开源项目有着为数众广的参与者。 绝大多数的 Linux 内核维护工作都花在了提交补
丁和保存归档的繁琐事务上（1991－2002年间）。 到 2002 年，整个项目组开始启用一个专
有的分布式版本控制系统 BitKeeper 来管理和维护代码。
到了 2005 年，开发 BitKeeper 的商业公司同 Linux 内核开源社区的合作关系结束，他们收回
了 Linux 内核社区免费使用 BitKeeper 的权力。 这就迫使 Linux 开源社区（特别是 Linux 的
缔造者 Linus Torvalds）基于使用 BitKcheper 时的经验教训，开发出自己的版本系统。 他们
对新的系统制订了若干目标：
速度
简单的设计
对非线性开发模式的强力支持（允许成千上万个并行开发的分支）
完全分布式
有能力高效管理类似 Linux 内核一样的超大规模项目（速度和数据量）
Git 基础
- 直接记录快照，而非差异比较
- 近乎所有操作都是本地执行
- Git 保证完整性
Git 中所有数据在存储前都计算校验和，然后以校验和来引用。 这意味着不可能在 Git 不知情
时更改任何文件内容或目录内容。 - Git 一般只添加数据
三种状态
- 已提交（committed）
数据已经安全的保存在本地数据库中。 - 已修改（modified）
已修改表示修改了文件，但
还没保存到数据库中。 - 已暂存（staged）
已暂存表示对一个已修改文件的当前版本做了标记，使之包含在下次
提交的快照中。
由此引入 Git 项目的三个工作区域的概念：Git 仓库、工作目录以及暂存区域。image.png
Git 工作流程：
- 在工作目录中修改文件。
- 暂存文件，将文件的快照放入暂存区域。
- 提交更新，找到暂存区域的文件，将快照永久性存储到 Git 仓库目录。
记录每次更新到仓库
工作目录下的每一个文件都不外乎这两种状态：已跟踪或未跟踪。 已跟踪的文件
是指那些被纳入了版本控制的文件，在上一次快照中有它们的记录，在工作一段时间后，它
们的状态可能处于未修改，已修改或已放入暂存区。 工作目录中除已跟踪文件以外的所有其
它文件都属于未跟踪文件，它们既不存在于上次快照的记录中，也没有放入暂存区。 初次克
隆某个仓库的时候，工作目录中的所有文件都属于已跟踪文件，并处于未修改状态。
- 关于git的基本操作
git基础指令
网友评论