在日常的多人协作时，Git的场景并非就像我们基本操作篇那样一帆风顺，还会有各种各样的问题：
我对这个模块的改动不够好，感觉自己的想法是错误的，越改越坏了，得重新拉取项目吗？
我刚提交了代码，结果发现还有一点点需要修改的地方，必须得再次走一遍流程吗？
其实这些情况都是对于Git的本地仓库管理不熟练导致的，快来了解一下这些问题的解决方式吧。
本地仓库与远程仓库
当我们从GitLab/GitHub上拉取代码时，那个具体的网址就是Git为你准备的远程仓库，可以供与你一起协作开发的Developer所看到。类似于这样:
而当你clone到本地，Git就会在你的当前文件夹中创建一个本地仓库，用于维护你的状态。类似于这样：
其实这个概念就可以按照分布式来理解：**每个人都拥有一个完整的版本库，远程主机只是负责交换信息而已。**所以，我们日常开发的流程应该是：
1.对代码修改完成后拉取远程仓库最新信息，这样所有的信息都在你的本地库了；
2.对本地库的冲突进行解决，保证最后是一个完善的版本；
3.将本地库推送到远程，告知所有人你所做的修改。
那么，该怎么具体的管理本地仓库呢？
仓库状态
首先，我们得需要了解仓库是否“干净”。
git status
通过该命令让我们时刻掌握仓库当前的状态(哪些文件被修改)，但是它只知道该文件被修改过，并不清楚修改的细节。如果需要明确的看到文件的哪一部分被修改过，需要执行以下命令：
git diff 文件名
左侧的符号代表着对文件进行的具体操作（+新增、-删除）。
版本控制
在进行开发的过程中，经常会遇到撤销改动的操作，要分三种情况来进行回退：
1.并未进行add操作
如果你只是简单的修改了文件，而没有进行git的相关操作，只需要使用如下命令直接撤销即可：
指定具体的文件
$ git checkout -- readme.txt
恢复所有文件
$ git checkout .
git checkout 是用版本库里的版本替换当前正在编辑的版本，也就是说会将文件恢复到最近一次的commit的版本。
2.add之后
如果你已经进行了add操作，再执行checkout时会恢复到add的版本，因为add之后它就被加入暂存区了。所以需要先把它拿出来：
$ git reset HEAD readme.txt
拿出来之后，上一次版本就会是最近一次commit的版本，再使用checkout即可：
$ git checkout -- readme.txt
3.commit之后
如果你已经进行了commit，这次修改就已经正式进入版本库，不能再通过reset直接拿出来了。这个时候就需要工作区回退到上一个版本，然后再将改动推送到仓库（用旧的再覆盖一次新的）。
那么该如何查看版本信息呢？
命令显示从最近到最远的提交日志
git log
从这个完成的版本信息可以看出，每一个版本都会有一个唯一的commit id，并且对于提交的版本，Git会把它们自动串成一条时间线按照最新的展示。回退版本时，需要考虑到两个应用场景：
1.这个版本已经出错了，需要回到之前稳定的版本；
$ git reset --hard 1094a
--hard
删除工作空间改动代码，撤销commit，撤销git add .
也就是说完成这个操作后，就恢复到了上一次的commit状态。
2.版本没错，commit之后又做了修改，想整合成一个commit进行推送；
使用commit id指定回到某个版本：
$ git reset --soft 1094a
--soft
不删除工作空间改动代码，撤销commit，不撤销git add .
完成这个操作后，你的代码还是这次修改完之后的，只不过是没有了commit信息。
值得注意的是：版本号只需要写前几位就可以了，Git会自动去找。
回退完版本之后，你本地的内容已经是你想要的了，接下来就是将你的相关信息告诉其他人：
git push -f origin master
