GIT--版本控制系统(二)

上一节简单介绍了Git入门和部分指令的使用，你已学会了：

• 简单Git的储存原理
• 上传文件到版本库
• 文件状态，工作区·缓存区和版本库的文件对比

接下来还会继续讲解几个Git常用而且重要的指令。

版本倒退

上章说了，版本控制系统的特点就是能控制项目版本最新修改前的状态，使用时光机回到你想到达的状态。

可是时光机也不能盲目时光倒流呀，它也有时间和地点的确定，而commit_id就是我们的地址和上传时间，每次提交一个新版本，Git会自动生成一段十六进制的id，我们可以使用$ git log指令：

从上图看出，默认不用任何参数的话，git log 会按提交时间列出所有的更新，最近的更新排在最上面。看到了吗，每次更新都有一个 'SHA-1' 校验(commit_id)和作者的名字 和 电子邮件地址、提交时间，最后缩进一个段落显示提交说明。

$ git log还有一些相当实用的指令，比如有大量的修改历史时，还可以使用--pretty选项来显示不一样的提交历史，例如oneline可以把每个提交用一行显示：

其他的选项有兴趣的可以看下<<get log 查看提交历史>>这篇文章。

就这样，我们轻易的获得了每次提交commit_id。首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，上一个版本就是HEAD^， 上上一个版本就是HEAD^^ ， 当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

我们先回退上一个版本：

$ git reset --hard HEAD^

当前版本就为 399691b 前缀id的版本。

换言之，如果想回到最新修改那一次，就必须知道最新那一次的commit_id，如果Git窗口未关闭，我们可以上滚窗口去找那个id。可是事情总有万一，万一窗口被关闭了呢？

我们还可以使用命令$ git reflog,该命令可以查看所有分支的所有操作记录（包括commit和reset的操作），包括已经被删除的commit记录，git log则不能察看已经删除了的commit记录。这样可以看到你所有commit_id 。再使用$ git reset --hard+id的形式，可以自由的在你的所有提交版本间自由穿梭，这可是记事本可无法做到的。

有了id之后你甚至可以：

• $ git show+id，查看某次提交后更新了什么
• git diff [commit-from]..[commit-to]，对比某两次提交的差异。

分支

几乎所有的版本控制系统都以某种形式支持分支。 使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。 在很多版本控制系统中，这是一个略微低效的过程——常常需要完全创建一个源代码目录的副本。对于大项目来说，这样的过程会耗费很多时间。

有人把 Git 的分支模型称为它的`‘必杀技特性’'，也正因为这一特性，使得 Git 从众多版本控制系统中脱颖而出。

Git 的分支，其实本质上仅仅是指向提交对象的可变指针。 Git 的默认分支名字是 master。 在多次提交操作之后，你其实已经有一个指向最后那个提交对象的 master 分支。 它会在每次的提交操作中自动向前移动。

Git 的 “master” 分支并不是一个特殊分支。 它就跟其它分支完全没有区别。 之所以几乎每一个仓库都有 master 分支，是因为 git init 命令默认创建它，并且大多数人都懒得去改动它。

Git 是怎么创建新分支的呢？ 很简单，它只是为你创建了一个可以移动的新的指针。 比如，创建一个 testing 分支， 你需要使用 git branch 命令：

$ git branch testing

这会在当前所在的提交对象上创建一个指针。

那么，Git 又是怎么知道当前在哪一个分支上呢？ 也很简单，它有一个名为HEAD的特殊指针。 请注意它和许多其它版本控制系统（如 Subversion 或 CVS）里的HEAD概念完全不同。 在 Git 中，它是一个指针，指向当前所在的本地分支（译注：将HEAD想象为当前分支的别名）。 在本例中，你仍然在master分支上。 因为git branch命令仅仅创建一个新分支，并不会自动切换到新分支中去。

HEAD 指向当前所在的分支。

完。

本文部分内容参考以下链接：
廖雪峰--Git教程
Git 分支 - 分支简介