上一节简单介绍了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
命令仅仅创建一个新分支,并不会自动切换到新分支中去。
完。
本文部分内容参考以下链接:
廖雪峰--Git教程
Git 分支 - 分支简介