您现在的位置是:首页 >其他 >Git回滚详解网站首页其他

Git回滚详解

定栓 2024-06-17 11:19:00
简介Git回滚详解

此文在阅读前需要有一定的git命令基础,若基础尚未掌握,建议先阅读这篇文章Git命令播报详版

在利用git协作过程中,经常需要进行代码的撤销操作,这个行为可能发生在工作区,暂存区或者仓库区(或版本库)。

我们先讨论在工作区与暂存区发生的撤销行为,这里会有两个命令提供帮助,git restoregit checkout

后面我们会讨论在仓库区发生的撤销行为,这里同样会有两个命令提供帮助,git resetgit revert

git restore

git restore主要是在工作区与暂存区之间进行撤销操作。

撤销工作区文件更改

我们在工作区修改了某个文件,然后我们想放弃此次修改,那么可以使用git restore pathspec

修改文件后,我们查看文件状态,可以看到文件状态已经变化

git status -s

输出:
 M README.md

撤销修改后查看状态,可看到工作区已经干净

git restore README.md 

git status

输出:
...
nothing to commit, working tree clean

如果我们同时修改了多个文件,想全部撤销,则可以执行git restore .命令

结论:git restore pathspec指令使得在工作空间但是不在暂存区的文件撤销更改(内容恢复到没修改之前的状态)。

撤销暂存区文件更改

git restore --staged pathspec指令将暂存区的文件撤回到工作区,但不会更改文件的内容。

我们将某个文件进行修改并添加到暂存区,查看状态

git status 

输出:
...
Changes to be committed:
  ...
        modified:   README.md

进行撤销后,再进行状态的查看

git restore --staged README.md  

git status

输出:
...
Changes not staged for commit:
  ...
        modified:   README.md
...

如果我们想撤销暂存区的所有文件改动到工作区,则可以执行git restore --staged .命令

从上面我们能看出git restore命令的局限性:

  1. 它无法直接对暂存区的文件撤销到原始未修改状态。
  2. 也没有能力直接将工作区与暂存区文件同时撤销到原始未修改状态。

接下来我们可以看看git checkout的表现。

git checkout

git checkout [<commit>] [--] <filePath>语法:

  • checkout命令主要是覆盖工作区(如果<commit>不省略,也会替换暂存区中相应的文件),且不会改变 HEAD 指针。
  • <commit> 是可选项,如果省略则默认是从暂存区检出。这和下面将要讲述的 git reset重置大不相同,重置的默认值是HEAD,即等于git reset HEAD
  • 为了避免路径<filePath>和引用(或者提交)<commit> 同名而冲突,可以在<filePath>前用两个连续的短线减号作为分隔。如git checkout HEAD -- <filePath>

语法示例:

  • 当执行 git checkout . 或者 git checkout <filePath> 命令时,会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险,会清除工作区中改动。
  • 当执行 git checkout HEAD . 或者 git checkout HEAD <filePath> 命令时,会用 HEAD 提交的全部或者部分文件替换暂存区以及工作区中的文件。这个命令也是极具危险性的,因为不但会清除工作区中的改动,也会清除暂存区中的改动。

git revert

git revert -n commit-id:只会反做commit-id对应的内容,然后重新commit一个信息,不会影响其他的commit内容

比如,我们commit了三个版本(版本一、版本二、 版本三),突然发现版本二不行(如:有bug),想要撤销版本二,但又不想影响撤销版本三的提交,就可以用 git revert 命令来反做版本二,生成新的版本四,这个版本四里会保留版本三的东西,但撤销了版本二的东西。如下图所示:

git revert -n commit-idA..commit-idB:反做commit-idA到commit-idB之间的所有commit

注意:使用-n是应为revert后,需要重新提交一个commit信息,然后在推送。如果不使用-n,指令后会弹出编辑器用于编辑提交信息

适用场景:如果我们想撤销之前的某一版本,但是又想保留该目标版本后面的版本,记录下这整个版本变动流程,就可以用这种方法。

冲突解决

git revert操作过程中,冲突难以避免,下面有几种解决方式

  • git revert --abort:冲突发生后,当前的操作会回到指令执行之前的样子,回到原始的状态,相当于什么事没有发生
  • git revert --quit:冲突发生后,从反做操作行为中退出,该指令会保留文件冲突
  • git revert --skip:冲突发生后,跳过此次反做操作
  • git revert --continue:冲突发生后,解决冲突并add后,执行该命令,会继续之前的操作流程
  • 冲突发生后,也可以手动操作。
      git add .
      git commit -m "提交的信息"
      git push
    

具体操作

先查看历史提交记录

git log --oneline

输出:
0681044 (HEAD -> dev, origin/dev) v3
3a854db v2
fc00739 v1
8785cc6 dev提交
709627d Initial commit

对提交信息为v1的进行反做

git revert -n fc00739

输出:
Auto-merging README.en.md
CONFLICT (content): Merge conflict in README.en.md
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
error: could not revert fc00739... v1
...

出现冲突,进行修改,重新添加文件到暂存区,并进行提交

git add .

git revert --continue

输出:
hint: Waiting for your editor to close the file... unix2dos: converting file D:/project/personal/gittestproject/.git/COMMIT_EDITMSG to DOS format...
dos2unix: converting file D:/project/personal/gittestproject/.git/COMMIT_EDITMSG to Unix format...
[dev 972bfce] Revert "v2"
 2 files changed, 2 insertions(+), 2 deletions(-)

推送到远程

git push

查看提交历史记录

git log --oneline 

输出:
77adce6 (HEAD -> dev, origin/dev) Revert "v1"
0681044 v3
3a854db v2
fc00739 v1
8785cc6 dev提交
709627d Initial commit

git reset

先通过举个例子,来一个感性的认识。下面这两条命令让 hotfix 分支向后回退两个提交。

git checkout hotfix
git reset HEAD~2

仓库区HEAD指针指向当前分支最新提交,回退两个提交后,hotfix 分支末端的两个提交现在变成了孤儿提交,如果你的提交还没有提交到远程,可以如上所示,直接用git reset撤销这些提交。

若之前提交已经提交到远程,使用git reset进行回退后,再使用git push提交更改,此时会报错,因为我们本地库HEAD指向的版本比远程库的要旧。所以我们要用git push -f强制推上去,就可以了,那么回退就成功了!

适用场景: 如果想恢复到之前某个提交的版本,且那个版本之后提交的版本我们都不要了,就可以用这种方法。

reset 的作用

为了演示下面这些例子,假设我们修改了 file.txt 文件并第三次提交它。 现在的历史看起来是这样的:

现在,假设我们运行git reset HEAD~(后面可能会跟不同的参数)。

第 1 步:移动 HEAD(–soft)

reset 做的第一件事是移动所在分支 HEAD 的指向。

运行 git reset HEAD~ –-soft 将会指向 9e5e6a4,这与checkout通过切换分支来改变 HEAD 自身不同。

结合上图,我们理解一下发生的事情:它本质上是撤销了上一次 git commit 命令。 当你在运行 git commit 时,Git 会创建一个新的提交,并移动当前所在分支 HEAD 的指向,使之指向最新提交。 当你将它 reset --softHEAD~HEAD 的父结点)时,其实就是把该分支移回原来的位置,而不会改变暂存区和工作区。

具体表现是:撤销上一次git commit的文件,将其放在暂存区,并与暂存区文件进行合并(如果有相同文件改动的话),工作区没有改变

第 2 步:更新暂存区(–mixed)

接下来,git reset HEAD~ –-mixed 会用 HEAD 指向的当前快照的内容来更新暂存区。

这也是默认行为,即可以忽略选项,git reset HEAD~

现在再看一眼上图,理解一下发生的事情:它依然会撤销一上次提交,但还会取消所有暂存。 于是,我们回滚到了所有 git addgit commit 的命令执行之前。

具体表现是:撤销上一次git commit的文件,并取消所有暂存区文件,将其与工作区文件进行合并(如果有相同文件改动的话)

第 3 步:更新工作区(–hard)

如果使用 –-hard 选项,git reset HEAD~ --hard 要做的的第三件事情就是让工作区看起来像暂存区。

现在让我们回想一下刚才发生的事情:你撤销了最后的提交(git commit )、git add 和工作区中的所有工作。

必须注意,–hard 标记是 reset 命令唯一的危险用法,它也是 Git 会真正地销毁数据的仅有的几个操作之一。其他任何形式的 reset 调用都可以轻松撤消,但是 –hard 选项不能,因为它强制覆盖了工作区中的文件。

具体表现是:撤销暂存区与工作区所有文件改动

顺序总结

reset 命令会以特定的顺序重写这三棵树,在你指定以下选项时停止:

  1. 移动 HEAD 指向的分支 (若指定了 --soft,则到此停止)
  2. 重置 index 以便和 HEAD 相匹配 (若未指定,或指定 --mixed,则到此停止)
  3. 使工作区看起来像暂存区 (若指定 --hard

reset与revert的区别

  • git reset 是回滚到对应的commit-id,相当于是删除了commit-id以后的所有的提交,并且不会产生新的commit-id记录,如果要推送到远程服务器的话,需要强制推送-f
  • git revert 是反做撤销其中的commit-id,然后重新生成一个commit-id。本身不会对其他的提交commit-id产生影响,如果要推送到远程服务器的话,就是普通的操作git push就好了
风语者!平时喜欢研究各种技术,目前在从事后端开发工作,热爱生活、热爱工作。