git二次提交及撤回

接下来我们用情境式学习来看看git的二次提交及相关操作。

假设我现在有新的一份日记，是9号到15号的，相比之前我们说的9号到14号，它多了一天对么？那它就是已经被我们修改过后的文件了，此处的修改无论是增添还是删除都被视为修改。接下来我们试着将它提交到我们的本地仓库，那提交的过程中是将新的文件复制一份吗？显然不是，咱们就继续看看。下面为了体现出每次提交的都是文件的变更，在谈论到提交时，会用“更改”替代“文件”

打开命令行（win+R）→cd 文件名→(昨天我们进行了一次提交，可先查看状态）→git add 新文件→git commit -m “提交新增加了一天我的日记”→git log

接下来在提交中可能会发生的：

情景一：将更改放进暂存区里之后突然发现不想提交这份文件了

将更改放进暂存区里之后突然发现不想提交这份文件了，也就是想把放到暂存区中的更改撤回，那该怎么办？

输入：

git restore --staged 新文件名

就可以把文件从暂存区中撤回到工作目录，而且文件是完好的，即我们的日记文件依旧比之前第一次提交的新增加了一天。

也可以用

git reset 新文件名

作用和restore一样。备注：reset还可以用到更多的场景中去。

情景二：已经放进暂存区、已经执行git commit的命令了，突然发现想撤回

这一步操作该如何做？

这还取决于你因为什么原因而想撤回这一步操作

场景一：发现提交信息填写有误，需要重新填写

输入

git reset --soft HEAD~1

这表明会将HEAD指针前移到前一个提交，并且不会动暂存区和咱们工作目录里的东西！也就是会把更改退回到暂存区里

场景二：发现遗漏了一些文件

输入

git reset --soft HEAD~1

是的，跟上面的场景用的是同一个指令

场景三：诶不对，突然发现某个代码里有错误要修复

git reset --soft HEAD~1

还是用这个！因为万一我们暂存区里有很多文件，而只是一个代码需要修复，那就没必要回到工作目录了，只是后面要再add一下修复好的代码，再commit

场景四：我有两个提交历史，即我前面进行了多次的commit,然后想我的提交历史log整洁一些

git reset --soft HEAD~2

这会使得HEAD指针回退到前前一个提交，即撤回两次提交，然后将两次提交的更改都撤回到暂存区里，然后我们可以进行commit，进行一次提交就可以实现我们的合并提交。

细心的小伙伴就会发现~后面跟着的就是我们想撤回到哪次提交。

为了总结方便，咱们把以上四个场景统一归类为一个场景：git reset --soft HEAD~N

即想把提交撤回，但更改依旧需要留在暂存区里面,

接下来是新的场景：

场景一：你发现提交的文件还要再做修改，并不只是一部分文件要修改，而是大部分

git reset --mixed HEAD~1

用这条命令就会撤销提交，而且不会保留在暂存区，而是直接回到我们的工作目录。

场景二：同时提交多个文件，然后突然发现某些文件并不需要被提交了

git reset --mixed HEAD~N

是的没错还是用这个，它可以帮你把文件退回到工作目录，接着你就可以重新选择文件进行add

有人可能会问，为什么我不用上面那个soft呢？直接回退到暂存区，然后对暂存区的文件提交之前进行重新选择呢？其实是可以的，用git commit file1.txt -m "只提交 file1.txt 的更改",但是那些不想提交的文件还是会留在暂存区，mixed的灵活程度更高，因为就算你把文件都退回到工作目录，你依旧可以把要想提交的文件重新进行add

以上两个场景都是把更改退回到工作目录，都是用git reset --mixed HEAD~N,这时候的场景就适用于你想要对文件进行修改的时候。同样地我们也把它们弄成一个场景。看到这里想必你可以猜出来有第三种就是既不在暂存区也不会在工作目录，那就是彻底重置（即删除了）。

用git reset --hard HEAD~N

好了明天要中秋啦，祝各位中秋节快乐，如果有空咱们明天接着讲！