git的一些简单使用

文件状态

git status

命令可以让我们时刻掌握仓库当前的状态

1、代码未add前，在工作区的状态



2、代码经过add，把文件添加到暂存区以后



3、用命令

git commit

告诉Git，把文件提交到仓库以后



虽然Git告诉我们readme.txt被修改了（没有add以及commit以前，只是简单的修改了代码），但如果能看看具体修改了什么内容，自然是很好的。比如你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的readme.txt，所以，需要用

git diff

这个命令看看：

版本回退

版本回退是在你编写代码的过程中，由于出现了某种错误，而需要返回上一个版本的情况。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个

commit

恢复，然后继续工作，而不是把几个月的工作成果全部丢失。

我们每次commit都会生成一个新的版本，在实际工作中，我们脑子里不可能记得一个几千行的文件每次都改了什么内容，不然要版本控制系统干什么。版本控制系统肯定有某个命令可以告诉我们历史录

1、在Git中，我们用

git log

命令查看：

2、git log

命令显示从最近到最远的提交日志，我们可以看到3次提交， 如果嫌输出信息太多，看得眼花缭乱的，可以试试加上

--pretty=oneline

参数：



需要友情提示的是，你看到的一大串类似

3628164...882e1e0

的是

commit id

（版本号），和SVN不一样，Git的

commit id

不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示，而且你看到的

commit id

和我的肯定不一样，以你自己的为准。为什么

commit id

需要用这么一大串数字表示呢？因为Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了。

那么到底版本回退该怎么做呢？首先，Git必须知道当前版本是哪个版本，在Git中，用

HEAD

表示当前版本，也就是最新的提交

3628164...882e1e0

（注意我的提交ID和你的肯定不一样），上一个版本就是

HEAD^

，上上一个版本就是

HEAD^^

，当然往上100个版本写100个

^

比较容易数不过来，所以写成

HEAD~100

。

1>版本回退，就可以使用

git reset

命令(我们也可以取ID号的前几位，而不必都写上)：



2>版本回退，我们也可以利用

HEAD~x（上一个版本就是
HEAD^
，上上一个版本就是[code]HEAD^^

，当然往上100个版本写100个

^

比较容易数不过来，所以写成

HEAD~100

。）[/code]

--hard

参数的意义就是可以让你看到当前的版本回退的位置



3、还有一个问题就是如果你已经实现了版本的回退，然而我发现并不是我代码的问题，我回退错了，我不想回退了，或者是我Git已经关闭了，找不到新版本的

commit id

怎么办？

Git提供了一个命令

git reflog

用来记录你的每一次命令：



这样我就可以通过找到新版本的

commit id，进行反回退

小结

现在总结一下：

HEAD

指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令

git reset --hard commit_id

。

穿梭前，用

git log

可以查看提交历史，以便确定要回退到哪个版本。

要重返未来，用

git reflog

查看命令历史，以便确定要回到未来的哪个版本。

工作区和暂存区

 

工作区（Working Directory）

就是你在电脑里能看到的目录，比如我的

learngit

文件夹就是一个工作区：

版本库（Repository）

工作区有一个隐藏目录

.git

，这个不算工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支

master

，以及指向

master

的一个指针叫

HEAD

。

所以，

git add

命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行

git commit

就可以一次性把暂存区的所有修改提交到分支。

管理修改

 Git管理的是修改，而不是文件

下面我们就用实例来证明，首先我们先修改一个文件，修改完以后我们用add把文件加到暂存区中，然后在继续修改此文件，然后再用commit进行提交，然后利用status来查看

第一次修改 ----->

git add

------> 第二次修改 ---->

git commit---->status

 

我们可以看到怎么第二次的修改没有被提交，为什么呢？

你看，我们前面讲了，Git管理的是修改，当你用

git add

命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，

git commit

只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。

 

那怎么提交第二次修改呢？你可以继续

git add

再

git commit

，也可以别着急提交第一次修改，先

git add

第二次修改，再

git commit

，就相当于把两次修改合并后一块提交了：

第一次修改 ->

git add

-> 第二次修改 ->

git add

->

git commit

小结

现在，你又理解了Git是如何跟踪修改的，每次修改，如果不

add

到暂存区，那就不会加入到

commit

中。

撤销修改

1、如果当你修改了代码，然后又发现修改错误以后，想撤销前面的操作的时候该怎么办呢？

既然错误发现得很及时，就可以很容易地纠正它。你可以删掉最后一行，手动把文件恢复到上一个版本的状态。如果用

git status

查看一下：



你可以发现，Git会告诉你，

git checkout -- file

可以丢弃工作区的修改：



2、如果当你修改了代码，已经add到暂存区而没有进行commit操作的时候，想撤销前面的操作的时候该怎么办呢？

Git同样告诉我们，用命令

git reset HEAD file

可以把暂存区的修改撤销掉（unstage），重新放回工作区：



然后再通过第一种的情况来想撤销前面的操作

小结

又到了小结时间。

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令

git checkout -- file

。

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令

git reset HEAD file

，就回到了场景1，第二步按场景1操作。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

删除文件

在Git中，删除也是一个修改操作，我们实战一下，先添加一个新文件test.txt到Git并且提交：



一般情况下，你通常直接在文件管理器中把没用的文件删了，或者用

rm

命令删了：



这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，

git status

命令会立刻告诉你哪些文件被删除了：



现在你有两个选择，一是确实要从版本库中删除该文件，那就用命令

git rm

删掉，并且

git commit

：



现在，文件就从版本库中被删除了。

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：



 转自：http://www.cnblogs.com/luxiaojun/p/5944145.html