git的使用——reset

git reset 命令用于回退版本，可以指定退回某一次提交的版本。
有三种命令方式

git reset [--soft |--mixed |--hard][HEAD]

知识前提：git重要的三个工作区域：

1. 工作区(Working Directory）：写代码的目录。就是项目代码存放的目录（git add 之前的目录）。
2. 暂存区（index/stage）：工作区与版本库之间的缓冲地带。用 git add 把文件添加进去，实际上就是把文件修改添加到暂存区，查看记录 git status
3. 仓库区：git commit 提交到本地分支的，查看记录 git log

–mixed为默认的，可以不用带该参数

1. 用于重置暂存区的文件，此时历史记录与上一次的提交(commit)保持一致，工作区文件内容保持不变（有上次修改的内容）。移动 HEAD 指针，改变暂存区内容，但不会改变工作区
2. 原有文件内容的变更 ：修改内容还在，变成未add的状态
3. 目录结构的变更（增加或者删除文件）： 新增文件： 还存在，变成未add的状态(目录结构中文件变成红色，需要执行命令git add . 再执行git commit ) 删除文件：目录结构中还是没有，可以直接执行git commit

–soft用于回退到某个版本

1. 仅仅移动当前 Head 指针，不会改变工作区和暂存区的内容
2. 原有文件内容的变更 ：修改内容还在，变成已add的状态（未commit）
3. 目录结构的变更（增加或者删除文件）： 新增文件：还存在，变成已add的状态(目录结构中文件变成绿色，可以再次执行git commit )； 删除文件：目录结构中还是没有，可以直接执行git commit

–hard 参数撤销工作区中所有未提交的修改内容，

1. 将暂存区与工作区都回到上一次版本，并删除之前的所有信息提交，当前 HEAD 指针、工作区和暂存区内容全部改变
2. 原有文件内容的变更 ：修改内容丢失（修改的代码不会变成未add的状态）
3. 目录结构的变更（增加或者删除文件）：新增文件丢失、删除的文件相当于没删

使用场景

–mixed

1 使用完 reset --mixed 后，执行 git add 将这些改变过的文件內容加入 暂存区（index）中，再执行 git commit 将 Index 暂存区中的內容提交至仓库（ Repository ）中，这样一样可以达到合并 commit 节点的效果
2 也可以用于发现add错误了，可以执行git reset HEAD来重置暂存区（index）的文件

–soft

1 使用完reset --soft后，commit_id之后提交的内容会被放入暂存区（index）中，此时已经add了，可以直接执行commit，将commit_id之后的提交作为一个commit来统一进行提交，减少不必要的log记录

–hard

1 使用 git reset --hard HEAD（HEAD也可以是某个commit_id) 来强制恢复 git 管理的文件夹的內容及状态；此时目标节点(commit_id)后的所有提交都会被删除

 git log // 查询要回滚的 commit_id// 这里的commit_id是当前提交错误的想要撤回的commit之前的那个正确的commit// 执行前，先将本地代码切换到对应分支
 git reset --hard commit_id // HEAD 就会指向这个commit_id的提交记录
 git push origin HEAD--force // 强制推送到远端

这种操作存在一个问题，服务器上的代码虽然被还原了，但假如有多个人在这个分支上开发，他们本地的版本依然是比服务器上的版本高的，所以，别人再重新提交(push)代码的话，你撤销的操作又会被重新，你上面的操作也就白操作了。解决办法是，让别人把本地的分支先删掉，然后重新从服务器上拉取分支,或者你在对方提交完所有本地代码之后对方没有再进行修改代码，这个时候你提交了，发现你提交的有问题，再进行reset操作，然后让对方拉取（pull）最新的代码也ok，最主要的就是对方本地没有你要reset的代码即可
2 误删恢复
如果回滚代码之后发现复制错了 commit_id，或者误删了某次 commit 记录，也可以通过下方代码恢复：

git relog // 复制要恢复操作的前面的 hash 值
git reset --hard hash // 将 hash 换成要恢复的历史记录的 hash 值