git介绍

2018-04-23 本文已影响0人 _npc_

本篇博客部分来自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基础指令