关于Git版本回退

  最近公司使用了git，之前都使用的是svn，git玩得不是很溜，现在重新学习一下。

  今天主要探讨的是回退，因为最近我们分支上有人做了回退操作，我这边pull拉取，发现出了问题，部分文件没有跟着远端版本回退，纳闷了很久，最后通过 执行 git reset <回退版本> 后，重新 commit 解决了。

  参考了这些资料，写得还是蛮不错的：

先看原理：

  三种 reset 的区别

  https://www.cnblogs.com/kidsitcn/p/4513297.html

 https://git-scm.com/book/zh/v2/Git-%E5%B7%A5%E5%85%B7-%E9%87%8D%E7%BD%AE%E6%8F%AD%E5%AF%86#_git_reset

  soft reset

--soft参数告诉Git重置HEAD到另外一个commit，但也到此为止。如果你指定--soft参数，Git将停止在那里而什么也不会根本变化。这意味着index,working copy都不会做任何变化，所有的在original HEAD和你重置到的那个commit之间的所有变更集都放在stage(index)区域中。

 

  hard reset

--hard参数将会blow out everything.它将重置HEAD返回到另外一个commit(取决于~12的参数），重置index以便反映HEAD的变化，并且重置working copy也使得其完全匹配起来。这是一个比较危险的动作，具有破坏性，数据因此可能会丢失！如果真是发生了数据丢失又希望找回来，那么只有使用：git reflog命令了。makes everything match the commit you have reset to.你的所有本地修改将丢失。如果我们希望彻底丢掉本地修改但是又不希望更改branch所指向的commit，则执行git reset --hard = git reset --hard HEAD. i.e. don't change the branch but get rid of all local changes.另外一个场景是简单地移动branch从一个到另一个commit而保持index/work区域同步。这将确实令你丢失你的工作，因为它将修改你的work tree！

 

 mixed reset 

--mixed是reset的默认参数，也就是当你不指定任何参数时的参数。它将重置HEAD到另外一个commit,并且重置index以便和HEAD相匹配，但是也到此为止。working copy不会被更改。所有该branch上从original HEAD（commit）到你重置到的那个commit之间的所有变更将作为local modifications保存在working area中，（被标示为local modification or untracked via git status)，但是并未staged的状态，你可以重新检视然后再做修改和commit

再看使用方式

  三种reset的使用方式：

 https://www.cnblogs.com/songzhenhua/p/11246929.html

--hard：(1) 要放弃目前本地的所有改变時，即去掉所有add到暂存区的文件和工作区的文件，可以执行 git reset -hard HEAD 来强制恢复git管理的文件夹的內容及状态；(2) 真的想抛弃目标节点后的所有commit（可能觉得目标节点到原节点之间的commit提交都是错了，之前所有的commit有问题）。

--soft：原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)，所以假如我们之前工作目录没有改过任何文件，也没add到暂存区，那么使用reset --soft后，我们可以直接执行 git commit 將 index暂存区中的內容提交至 repository 中。为什么要这样呢？这样做的使用场景是：假如我们想合并「当前节点」与「reset目标节点」之间不具太大意义的 commit 记录(可能是阶段性地频繁提交,就是开发一个功能的时候，改或者增加一个文件的时候就commit，这样做导致一个完整的功能可能会好多个commit点，这时假如你需要把这些commit整合成一个commit的时候)時，可以考虑使用reset --soft来让 commit 演进线图较为清晰。总而言之，可以使用--soft合并commit节点。

--mixed（默认）：(1)使用完reset --mixed后，我們可以直接执行 git add 将這些改变果的文件內容加入 index 暂存区中，再执行 git commit 将 Index暂存区 中的內容提交至Repository中，这样一样可以达到合并commit节点的效果（与上面--soft合并commit节点差不多，只是多了git add添加到暂存区的操作）；(2)移除所有Index暂存区中准备要提交的文件(Staged files)，我们可以执行 git reset HEAD 来 Unstage 所有已列入 Index暂存区 的待提交的文件。(有时候发现add错文件到暂存区，就可以使用命令)。(3)commit提交某些错误代码，或者没有必要的文件也被commit上去，不想再修改错误再commit（因为会留下一个错误commit点），可以回退到正确的commit点上，然后所有原节点和reset节点之间差异会返回工作目录，假如有个没必要的文件的话就可以直接删除了，再commit上去就OK了。

 

目前来说，我这里只用到了hard 和 mixed：

hard 我用来做远端的版本回退，一般是 首先进行 git reset --hard <指定版本> ， 之后使用 git push -f 进行强制推送，将最新版本覆盖成老版本，达到远端回退的目的。

 

mixed 我这里的使用方法如下：

   在其他人进行了分支回退，你会发现部分文件在你进行 pull 的时候无法回退，这些文件会出现在你的 push 文件中，但是不会出现在你的 commit 中，参考上面的文档，可以知道，这是因为pull的时候，执行的是 merge 操作，部分新增部分会遗留下来，虽然你本地的 commit 没有这些文件，但是你push 的时候，不仅会记录你本次的 commit 还会记录 这些遗留的文件，如果这个时候你一不小心 push 了，就会导致把别人原本回退的东西又重新提交，而且 log 线里最新的提交中还会出现之前修改的记录。

  这时候，可以进行 git reset <回退的版本号> ， 之后提交时，原本 pull 时没有一起回退的文件，因为 reset 将这部分文件清除出了 index 区，因此此时这部分文件就会出现在你的 commit 列表中，将这些文件 revert 一下，或者修改，然后提交 push，这样就保证了本次 push 的文件没有远端回退的内容了。