Git之版本回退与前进

我们对已经提交到demo.txt文件再做一次修改，添加上天气情况，则修改好的文件内容为：

之后不要忘了提交到仓库。

 

那么此时，我们就有了三个不同版本的文件了，分别是：

Create a new file：

Add week：

Add weather：

像这样，我们频繁的修改文件，又频繁的提交文件到版本库里，像极了我们玩游戏的时候，不停的闯关，不停的存档读档等。为了方便记忆和演示，我们只编辑了一个两三行的文件来进行修改和提交。而在实际工作中，面对的往往是数以千行记的代码或文件，或数以十记的各种版本号，我们很难记住哪个版本对文件的哪部分内容进行了哪些修改。此时我们可以查看历史记录：

 

git log命令会从近到远的显示我们对文件做的修改和文件的版本号，即我们的提交日志。如果我们只想看到提交的版本号和说明的话，就对刚才的命令加上相应的参数再试一次

 

我们可以看到，这一串串字母和数字相结合出现的内容其实就是我们每次提交的commit id，即版本号。和SVN不一样，Git所使用的版本号并不是递增的阿拉伯数字，而是通过SHA1计算出来的一个使用十六进制表示的数字。而至于为什么Git要使用这么长一串数字来作为版本号的原因，那自然也是清晰可见的。我们知道，Git是分布式版本控制系统，那么既然是分布式的，就不可避免的会出现多人同时在同一个版本库里工作的情况，如果只是单纯的使用阿拉伯数字来定义版本号，那么解决工作中的版本号冲突的问题可能比解决工作更频繁。

当我们需要进行版本回退的工作时，我们首先要知道当前版本是哪个版本，通常在Git中，使用HEAD来表示当前版本，HEAD^代表上一个版本，HEAD^^代表上上一个版本，HEAD~100代表往前数的第100各版本。

如果我们要把当前的版本Add weather回退到之前的Add week版本，那就可以这样操作：

 

然后我们查看一下回退之后的文件内容，发现确实回退了。

 

此时，我们再看一下历史记录

 

发现之前最新的那个版本Add weather已经不见了，也就是说我们现在要想再回来的话已经回不来了。但是，真的是这样的吗？其实，只要我们当前的Git窗口没有关闭，我们往上查找之前使用过git log的那个命令，找到Add weather的版本号，之后再使用命令即可：

 

查看一下文件内容，发现确实已经是最新的那个版本了。

 

也就说，我们不仅可以从现在回退到之前的任何一个版本，也可以从之前的版本回到之后的版本中。

Git的版本回退速度非常快，这是因为在Git内部有一个指向当前版本号的HEAD指针，当我们进行回退版本的操作时，实际上就是把HEAD指针的指向从最新版本指向了想回退的版本，然后顺便也把工作区的文件给更新了。

                

之前所说的那种回退版本之后又前进版本的方法只适用于没有退出git的命令窗口的情况，当我们电脑关机之后，git命令窗口退出了之后，我们其实也可以使版本前进的。

首先我们使用git reflog命令来查看我们想要前进的版本的版本号，这个命令记录了我们的命令：

 

查找到之后，我们便可以使用reset命令来使版本前进了。

 

总结：版本回退前，使用git log来查看提交历史，以便确定我们要回退的版本号；版本前进前，使用git reflog查看历史命令，以便确定要前进的版本号。

git reset与git revert

假设有提交过程A -> B -> C，现在想回退到B：

方法一：reset到B，丢失C：

A -> B

方法二：再提交一个revert反向修改，变成B：

A -> B -> C -> B

C还在，但是两个B是重复的

根据实际需求，也许C就是瞎提交错了（比如把密码提交上去了），必须reset；如果C就是单纯修改，现在又要改回来，将来可能再改成C，那就revert