主页
文章
分类
标签
关于
Git的撤销修改
Git入门
发布于: 2025-3-11   更新于: 2025-3-11   收录于: Git
文章字数: 1528   阅读时间: 4 分钟   阅读量:

撤销修改

各种情况

当我们需要撤销修改时，我们需要先确定我们当前处于哪个步骤，大部分情况如下：

  • 我们修改了一个文件，但是还没有add到暂存区中
  • 我们修改了一个文件，并且已经add到了暂存区当中，但是没有提交
  • 我们修改了一个文件，add到了暂存区当中，而且commit了，但是没push到远程仓库上
  • 我们修改了一个文件，add和commit都做了，还push到了远程仓库上

第一种情况

我们接着上一章的操作，我们修改一下test.txt中的内容：

1

this is the third commit

然后我们再git status看一下当前的状态:

1
2
3
4
5
6
7
8

git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git restore <file>..." to discard changes in working directory)
#         modified:   test.txt

# no changes added to commit (use "git add" and/or "git commit -a")

它会提示我们修改了test.txt，但是还没有添加到暂存区中，它还提示我们可以使用git restore <file> ...来取消修改：

1

git restore test.txt

当我们执行完毕后，就会发现刚刚的修改没了。

这里要注意的是 git restore 与Git 2.23版本引入，在此之前我们需要使用 git checkout -- <file> 来取消修改

第二种情况

同样修改test.txt：

1

this is the third commit

但是这次我们先add到暂存区当中，然后来看status：

1
2
3
4
5
6

git add test.txt
git status
# On branch master
# Changes to be committed:
#   (use "git restore --staged <file>..." to unstage)
#         modified:   test.txt

它会提示我们已将test.txt的修改存入了暂存区，同样也提示我们可以使用 git restore --staged <file>... 来撤销修改

1
2
3
4
5
6
7
8
9

git restore --staged test.txt
git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git restore <file>..." to discard changes in working directory)
#         modified:   test.txt

# no changes added to commit (use "git add" and/or "git commit -a")

这个时候我们可以看到，刚刚文件恢复到了添加进暂存区的状态，也就是刚刚的第一种情况。

同样在旧版本下，我们可以使用 git reset HEAD <file> 来撤销修改

第三种情况

请参考上一章的内容，直接进行版本回退 git reset --hard HEAD^，回到上一个版本即可。

1
2
3
4
5
6

# 回退到上一个提交
git reset --hard HEAD^
# 保留工作区更改（仅重置提交历史）
git reset --soft HEAD^
# 保留工作区和暂存区更改（仅重置提交历史）
git reset --mixed HEAD^

第四种情况

  • 方案 1：创建反向提交（推荐） 这是最安全的方式，不会修改提交历史，适合多人协作的场景。

  1. 使用 git revert 创建反向提交

    1

    git revert HEAD
    • git revert 会创建一个新的提交，撤销指定提交的更改。
    • HEAD 表示撤销最近一次提交。

  2. 推送反向提交到远程仓库

    1

    git push
    • 将反向提交推送到远程仓库，其他人拉取代码时会自动应用这些更改。

  3. 示例

    • 假设你提交了一个错误的修改： 
      1
2
3

      git log --oneline
# abc123 (HEAD -> master) 添加了错误的修改
# def456 上一次提交
    • 使用 git revert 撤销： 
      1

      git revert abc123
    • 这会生成一个新的提交，撤销 abc123 的更改： 
      1
2
3
4

      git log --oneline
# 789xyz (HEAD -> master) Revert "添加了错误的修改"
# abc123 添加了错误的修改
# def456 上一次提交

  4. 优点

    • 不会修改提交历史，适合多人协作。
    • 操作简单，风险低。

  5. 缺点

    • 提交历史中会多出一条反向提交记录。
  • 方案 2：回退并强制推送（慎用） 这种方式会修改提交历史，适合个人项目或团队明确允许的情况下使用。

  1. 使用 git reset 回退提交

    1

    git reset --hard HEAD^
    • HEAD^ 表示回退到上一个提交。
    • --hard 会丢弃工作区和暂存区的所有更改。

  2. 强制推送到远程仓库

    1

    git push --force
    • --force 会强制覆盖远程仓库的提交历史。

  3. 示例

    • 假设你提交了一个错误的修改： 
      1
2
3

      git log --oneline
# abc123 (HEAD -> master) 添加了错误的修改
# def456 上一次提交
    • 使用 git reset 回退： 
      1

      git reset --hard def456
    • 强制推送： 
      1

      git push --force

  4. 优点

    • 提交历史保持干净，没有多余的反向提交。

  5. 缺点

    • 会修改提交历史，可能导致其他人拉取代码时出现问题。
    • 需要团队明确允许使用 --force。

3. 注意事项

  1. 强制推送的风险

    • git push --force 会覆盖远程仓库的提交历史，可能导致其他人的工作丢失。
    • 如果其他人已经基于你的错误提交进行了开发，强制推送会导致他们的分支出现问题。

  2. 团队协作中的最佳实践

    • 尽量使用 git revert，避免修改提交历史。
    • 如果必须使用 git reset --hard 和 git push --force，请提前通知团队成员。

  3. 备份当前状态

    • 在执行任何撤销操作前，建议备份当前分支： 
      1

      git branch backup-branch
    • 如果操作出错，可以恢复到备份分支： 
      1

      git checkout backup-branch
Git
Git的版本回退