Git误操作急救手册

Git误操作急救手册大纲

一、常见误操作场景分类

提交相关：误提交敏感信息、提交信息错误、漏提交文件
分支相关：误删分支、错误合并分支、误切换分支
历史记录相关 ：误执行git reset、误用git rebase导致历史混乱
远程仓库相关：误推送、误强制推送覆盖他人代码

二、核心急救工具箱

无论遇到什么问题，这几个命令是你最可靠的帮手，请务必掌握。

git reflog ------ 时光机
- 作用：记录你在本地仓库的每一次HEAD变动（包括reset、rebase、merge等）。几乎所有"丢失"的提交，都能在这里找到它们的哈希值，是找回误操作的第一选择。
- 提示：reflog 是本地特有的，你的同事无法看到你的操作历史。
git fsck ------ 遗失物品招领处
- 作用：当 reflog 也找不到某次提交时（例如，reflog 条目过期），可以用它来检查仓库完整性，找出所有未被任何引用指向的"悬空对象"（dangling commits）。
git cherry-pick ------ 精准移植
- 作用：选择某一个或某几个特定的提交，将其应用到当前分支。这对于从误删的分支中恢复特定的功能修改非常有用。
git revert ------ 安全的后悔药
- 作用：通过创建一个新的提交来撤销某次旧提交的更改。它不会修改项目历史，是团队协作中撤销已推送提交的最安全方式。

三、常见误操作修复方案

1. 提交相关 (Commit)

症状 A：提交信息写错了，或漏提交了几个文件。
- 解药：
  
  bash
  复制代码
```
# 1. 将漏掉的文件添加到暂存区
git add <遗漏的文件>
# 2. 修改最近一次的提交：可以同时修改提交信息，并包含新添加的更改
git commit --amend
```
- 注意：如果这个提交已经推送到远程，修改后再次推送时需要使用 --force-with-lease。

症状 B：不小心提交了敏感信息（密码、密钥等）。

解药 (本地提交，尚未推送)：

bash

复制代码

# 撤销最近一次提交，但保留所有更改在工作区，方便你手动删除敏感文件
git reset --soft HEAD~1
# 然后删除敏感文件，重新提交

解药 (已推送到远程)：这需要重写历史，风险较高。

bash

复制代码

# 1. 使用 git filter-repo (推荐) 或 git filter-branch 彻底从历史中抹去敏感文件
# 例如：删除整个项目历史中的 'config/passwords.txt' 文件
git filter-repo --force --invert-paths --path 'config/passwords.txt'
# 2. 强制推送重写后的历史 (务必通知所有协作者，他们的本地历史需要和远程重新同步)
git push origin --force --all

2. 分支相关 (Branch)

症状 A：手快删错了分支。

解药：

bash

复制代码

# 1. 立刻用 git reflog 找到你删除前所在分支的最后一次提交哈希
git reflog
# 2. 基于这个哈希值重新创建分支
git checkout -b <被删除的分支名> <找到的commit-hash>

症状 B：合并了一个错误的分支，或者合并后发现有严重冲突。

解药 (合并正在进行中，尚未提交)：

bash

复制代码

# 直接中止这次合并，回到合并前的状态
git merge --abort

解药 (合并已经提交)：

bash

复制代码

# 回退到合并前的状态（ORIG_HEAD 是 Git 在执行危险操作前自动保存的指针）
git reset --hard ORIG_HEAD

3. 历史记录相关 (History)

症状 A：执行了 git reset --hard，发现回滚过头了，丢失了后续的代码。

解药：

bash

复制代码

# 1. 别慌！立即使用 git reflog 找到你执行 reset 操作之前的那个提交哈希
git reflog
# 2. 强硬地 reset 回去
git reset --hard <找到的commit-hash>

症状 B：git rebase 过程中出现冲突，不知道怎么处理，或者想放弃。

解药：

bash

复制代码

# 想放弃？直接中止变基，回到操作前的状态
git rebase --abort
# 想继续？先解决冲突文件，然后
git add <已解决冲突的文件>
git rebase --continue

4. 远程仓库相关 (Remote)

症状 A：错误地推送了本地的错误分支，或者推送了包含敏感信息的提交。

解药 (撤销这次推送的影响)：

bash

复制代码

# 最安全的方式：使用 git revert 在本地生成一个反提交，再推送
git revert <错误的提交哈希>  # 这会生成一个新的提交，内容与错误提交相反
git push origin <分支名>

# 如果你确定要覆盖远程，可以使用 --force-with-lease（比 --force 更安全）
# 先本地回滚到正确状态，然后
git push origin <分支名> --force-with-lease

症状 B：手贱用了 git push --force，覆盖了同事推送到远程的代码。
- 解药：
  1. 立即停止所有操作！
  2. 联系被覆盖代码的同事：他们本地通常还有最新的代码。让他们从本地重新推送。
  3. 尝试从远程恢复：一些Git托管平台（如GitHub、GitLab、Bitbucket）有"回收站"或"事件恢复"功能，可以找回被强制推送覆盖的旧分支状态（有时间限制）。检查你的仓库设置。

四、防患于未然：最佳实践

养成好习惯：
- 提交前，三思 ：git diff 看看改了啥，git status 看看要提交啥。
- 提交信息，写清楚：为团队和自己留下清晰的日志。
使用"后悔药"的"药引"：
- git stash ：在进行 git pull、rebase 等可能造成冲突的操作前，先用 git stash 把工作区临时保存起来。
- 分支保护 ：在远程仓库（如GitHub）上，将 main/master 等重要分支设置为"受保护分支"，禁止直接推送和强制推送。
关键节点，打上标记：
- git tag ：对每个发布的版本，使用 git tag v1.0.0 这样的方式打上标签，这是一个永远不会移动的"锚点"。

五、附录：紧急情况处理流程

STOP！ 立即停止所有可能造成进一步覆盖的操作。不要关闭终端窗口！
深呼吸 ，然后执行 git status 和 git reflog，观察当前状态和最近的移动记录。
定位问题点 ：在 reflog 中找到误操作前的那个状态（通常是 HEAD@{n}）。
选择工具：
- 只是想撤销？ ➔ git reset --hard HEAD@{n}
- 只想恢复某个文件？ ➔ git checkout <commit-hash> -- <file-path>
- 想撤销远程推送？ ➔ git revert 或 git push --force-with-lease
验证与同步：确认本地代码恢复正确后，如果涉及远程分支，谨慎地同步到远程。

Git误操作急救手册

Git误操作急救手册大纲

一、常见误操作场景分类

二、 核心急救工具箱

三、 常见误操作修复方案

1. 提交相关 (Commit)

2. 分支相关 (Branch)

3. 历史记录相关 (History)

4. 远程仓库相关 (Remote)

四、 防患于未然：最佳实践

五、 附录：紧急情况处理流程

二、核心急救工具箱

三、常见误操作修复方案

四、防患于未然：最佳实践

五、附录：紧急情况处理流程