【Git笔记2】必知习惯和如何版本回退

     良好的习惯会让工作和生活如鱼得水，在使用git的时候有些必知习惯和概念你要get一下，总有些许失误，如：已经提交了不合适的修改到版本库时还没有把自己的本地版本库推送到远程，想要撤销本次提交，或者已经push到远程库想要回退（撤销）。今天我们接着上篇 【Git笔记1】本地项目与GitHub远程仓库互联，趁热打铁，开始实操，来看看怎么处理这些问题。

简单的必知习惯

       

• 要随时掌握工作区的状态，使用git status命令。

• 如果git status告诉你有文件被修改过，用git diff可以查看修改内容。

     假设在上篇readme.txt.txt的原文有如下内容：（版本1）

      Git is a versioncontrol system.

      Git is free software.

     更改： （版本2）内容没变但是修改了文件名字。 git bash输入：

git status	
git diff

     可以看到我们在master分支，与远端的master数据共享，修改了文件名字，可以看到消息是：相当是删除了，然后新建了一个readme.txt。

如何回退版本？

      先浏览一波要用到的git命令：

git reset --hard HEAD^   //回退上个版本	
git reset --hard <commit_id的前几个数字>   //回退到指定的版本

git log    //查看commit的历史记录	
git log git log --pretty=oneline //查看提交日志	
git reflog  //记录你的每一次命令：

场景1：

已经提交了不合适的修改到版本库时，同时，你还没有把自己的本地版本库推送到远程，想要撤销本次提交。

更改（版本3）并提交：

Git is a distributed version controlsystem.

Git is free software distributed under theGPL.

     完蛋，改错了！Git的commit好比一个快照。一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作，而不是把几个月的工作成果全部丢失。

     想查看提交日志怎么办？ 这时我们用git log命令查看：

还可以使用git log git log --pretty=oneline，它比git log表达的信息量少些。

     注意：

看到的一大串类似 144b8216657d 的是 commit id （版本号），是一个SHA1计算出来的一个非常大的数字，用十六进制表示。

每提交一个新版本，实际上Git就会把它们自动串成一条时间线。 如果使用可视化工具（SourceTree，有机会介绍一下怎么用，目前还是基本上用命令行，为啥？ 显得高端呗，哈哈）查看Git历史，就可以更清楚地看到提交历史的时间线。

     把readme.txt回退到上一个版本，也就是add distributed的那个版本，怎么做呢？

Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交 144b8216657d... ，上一个版本就是 HEAD^ ，上上一个版本就是 HEAD^^ ，当然往上100个版本是HEAD~100。

我们要把当前版本append GPL回退到上一个版本adddistributed，就可以使用git reset命令：

git reset --hard HEAD^      

 使用：cat readme.txt 查看一下。

看下log，发现没有append GP。

如何再回去append GPL版本呢？只要上面窗口还没有关闭，那么就可以通过那个append GPL的commit id是144b8216...，于是就可以指定回到未来的某个版本：gitreset --hard 144b 操作一波。

注意 ：

• 关于HEAD的介绍。Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向append GPL，然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

• 关闭了窗口，看不到commit id，还是有解决办法的。 Git提供了一个命令git reflog用来记录你的每一次命令。快速查到commit id。

场景2：

已经提交了不合适的修改到版本库时，同时已经push到远端。 希望能够回退到以前的版本。

step1： 先在本地回退到相应的版本

git reset --hard <版本号>

注意：

• 使用 --hard 参数会抛弃当前工作区的修改

• 使用 --soft 参数的话会回退到之前的版本，但是保留当前工作区的修改，可以重新提交

step2：为了覆盖掉远端的版本信息，使远端的仓库也回退到相应的版本，需要加上参数--force

git push origin <分支名> --force

因为，如果此时使用三步走的最后一步的话，会提示本地的版本落后于远端的版本；

git push origin <分支名>

必知的概念

  

1、工作区

在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区：

2、版本库（Repository）

工作区有一个隐藏目录 .git ，这个不算工作区，而是Git的版本库。Git的版本库里存了很多东西，最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

• 第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

• 第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在git commit就是往master分支上提交更改。总结一句话：需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。大兄弟，来实践一波，更改readme.txt(版本4)

Git is a distributedversion control system.

Git is freesoftware distributed under the GPL.

Git has a mutable indexcalled stage.

然后，在工作区新增一个LICENSE文本文件（内容随便写）。 先用git status查看一下状态：

Git清楚地告诉我们在master分支，readme.txt被修改了，而LICENSE还从来没有被添加过到版本区，所以它的状态是Untracked。

使用命令git add xxx，把readme.txt和LICENSE都添加后，用git status再查看一下：

现在，暂存区的状态就变成这样了。

所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

现在版本库变成了这样，暂存区就没有任何内容了。

      快点实践起来吧！不要有拖延症，现在学到就是挣到！欢迎关注小白，和小白一起变秃。

来和小伙伴们一起向上生长呀！

扫描下方二维码，添加小詹微信，可领取千元大礼包并申请加入 Python 学习交流群，群内仅供学术交流，日常互动，如果是想发推文、广告、砍价小程序的敬请绕道！一定记得备注「 交流学习 」，我会尽快通过好友申请哦！

👆长按识别，添加微信

（添加人数较多，请耐心等待）

👆长按识别，关注小詹

（扫码回复 1024 领取程序员大礼包）

推荐阅读： （点击标题即可跳转）