Git 冷命令拯救崩溃现场的全面指南

Git 冷命令拯救崩溃现场的全面指南

• • 5个鲜为人知但救命的Git命令，专治误删、错提交、远程失联等
  • 摘要
  • 一、git reflog：Git终极后悔药
  • • 1.1 崩溃场景
    • 1.2 reflog原理
    • 1.3 实战案例
    • • 案例1：恢复误删分支
      • 案例2：找回硬重置丢失的代码
      • 案例3：恢复误删的提交
    • 1.4 高级技巧
    • • 技巧1：精确查找特定操作
      • 技巧2：结合git log使用
      • 技巧3：恢复到特定时间点
    • 1.5 注意事项
  • 二、git fsck：数据恢复神器
  • • 2.1 崩溃场景
    • 2.2 fsck原理
    • 2.3 实战案例
    • • 案例1：恢复已暂存但未提交的文件
      • 案例2：恢复误删的stash
      • 案例3：批量恢复悬空文件
    • 2.4 高级技巧
    • • 技巧1：按时间筛选悬空对象
      • 技巧2：查找特定内容的悬空对象
      • 技巧3：恢复整个目录结构
    • 2.5 注意事项
  • 三、git cherry-pick：精准迁移提交
  • • 3.1 崩溃场景
    • 3.2 cherry-pick原理
    • 3.3 实战案例
    • • 案例1：纠正提交到错误分支
      • 案例2：从dev分支移植特定修复到main
      • 案例3：批量迁移多个提交
    • 3.4 高级技巧
    • • 技巧1：保留原提交信息
      • 技巧2：处理冲突的高级策略
      • 技巧3：批量操作和自动化
    • 3.5 注意事项
  • 四、git fetch –prune：清理远程失联
  • • 4.1 崩溃场景
    • 4.2 fetch –prune原理
    • 4.3 实战案例
    • • 案例1：清理所有已删除的远程分支
      • 案例2：配置自动清理
      • 案例3：预览将被清理的分支
      • 案例4：清理特定远程仓库
    • 4.4 高级技巧
    • • 技巧1：结合其他命令使用
      • 技巧2：在脚本中安全使用
      • 技巧3：处理特殊情况
    • 4.5 注意事项
  • 五、git revert：安全回滚远程提交
  • • 5.1 崩溃场景
    • 5.2 revert原理
    • 5.3 实战案例
    • • 案例1：撤销最近一次提交
      • 案例2：撤销指定提交
      • 案例3：撤销多个连续提交
      • 案例4：撤销合并提交
    • 5.4 高级技巧
    • • 技巧1：批量撤销并压缩为一个提交
      • 技巧2：撤销但不自动提交
      • 技巧3：处理复杂的冲突场景
    • 5.5 注意事项
  • 六、额外福利：两个实用命令
  • • 6.1 git bisect：二分法定位Bug
    • 6.2 git worktree：多工作目录并行开发
  • 七、总结与最佳实践
  • • 7.1 5个命令速查表
    • 7.2 应急响应流程图
    • 7.3 预防措施
    • 7.4 学习路径
  • 八、结语

5个鲜为人知但救命的Git命令，专治误删、错提交、远程失联等

摘要

在日常开发中，你是否经历过这些"崩溃时刻"？

• 熬夜写的代码，手滑 git reset –hard 直接清空
• 刚提交完发现漏了关键文件，不想留垃圾 commit
• 把配置密钥提交上去，想撤回又怕丢代码
• 本地回退后 push 被拒，强推又怕覆盖队友代码
• 甚至仓库损坏、远程失联，项目直接卡住动不了

网上大部分教程都只讲 add/commit/push 三板斧，真正能救场的冷门实用命令却很少有人总结。本文基于2026年最新实践，为你带来5个鲜为人知但极度救命的Git冷命令，覆盖误删找回、错误提交、仓库修复、安全强推等高频崩溃场景。

学会之后，99%的Git事故都能从容解决！

一、git reflog：Git终极后悔药

1.1 崩溃场景

场景1：误删本地分支

# 手滑删除了重要分支
git branch -D feature/important-feature
# 完了！分支不见了，但还没推送到远程

场景2：硬重置导致代码丢失

# 想回退到上一个版本，结果…
git reset –hard HEAD~3
# 糟糕！最近3次提交的代码全没了！

场景3：误删提交历史

# 想清理提交记录，结果…
git rebase -i HEAD~5
# 不小心把重要的提交删掉了！

1.2 reflog原理

reflog（引用日志） 是Git的隐藏日志，记录HEAD和分支的所有移动历史。每当分支切换、提交或重置时，Git都会自动记录这些操作。

关键特性：

• 记录所有HEAD移动历史
• 默认保留90天（可配置）
• 只记录本地操作
• 不会被 git push 推送到远程

1.3 实战案例

案例1：恢复误删分支

# 1. 查看reflog，找到分支删除前的提交
git reflog

# 输出示例：
# abc1234 (HEAD -> main) HEAD@{0}: reset: moving to HEAD~3
# def5678 HEAD@{1}: commit: Add new feature
# ghi9012 HEAD@{2}: commit: Fix bug
# jkl3456 HEAD@{3}: checkout: moving from feature/important-feature to main

# 2. 找到分支最后的位置（jkl3456）
# 3. 基于该提交创建新分支
git checkout -b feature/important-feature jkl3456

# 4. 验证分支恢复成功
git log –oneline

案例2：找回硬重置丢失的代码

# 1. 查看reflog，找到重置前的状态
git reflog

# 输出示例：
# abc1234 (HEAD -> main) HEAD@{0}: reset: moving to HEAD~3
# def5678 HEAD@{1}: commit: Latest changes
# ghi9012 HEAD@{2}: commit: More changes
# jkl3456 HEAD@{3}: commit: Even more changes

# 2. 找到重置前的提交（def5678）
# 3. 创建救援分支
git checkout -b rescue/fix def5678

# 4. 将需要的代码合并到主分支
git checkout main
git merge rescue/fix –no-ff

# 5. 删除救援分支
git branch -d rescue/fix

案例3：恢复误删的提交

# 1. 查看reflog，找到被删除的提交
git reflog

# 输出示例：
# abc1234 (HEAD -> main) HEAD@{0}: rebase -i (finish): returning to refs/heads/main
# def5678 HEAD@{1}: rebase -i (pick): Fix critical bug
# ghi9012 HEAD@{2}: rebase -i (start): checkout main
# jkl3456 HEAD@{3}: commit: Add new feature (被误删的提交)

# 2. 找到被删除的提交哈希（jkl3456）
# 3. 使用cherry-pick恢复该提交
git cherry-pick jkl3456

1.4 高级技巧

技巧1：精确查找特定操作

# 只显示与reset相关的操作
git reflog | grep reset

# 只显示与checkout相关的操作
git reflog | grep checkout

# 显示最近24小时的操作
git reflog –since="24 hours ago"

技巧2：结合git log使用

# 查看reflog中某个提交的详细信息
git show abc1234

# 查看reflog中某个提交的差异
git diff abc1234^..abc1234

# 查看reflog中某个提交的文件列表
git show –name-only abc1234

技巧3：恢复到特定时间点

# 查看特定时间点的状态
git reflog –date=iso

# 恢复到特定时间点
git reset –hard "HEAD@{2026-04-26 15:30:00}"

1.5 注意事项

⚠️ 重要提醒：

二、git fsck：数据恢复神器

2.1 崩溃场景

场景1：误删已暂存但未提交的文件

# 文件已经git add，但还没commit
git add important-file.txt

# 然后不小心删除了文件
rm important-file.txt

# 常规方法无法恢复！

场景2：stash被误删

# 保存了重要修改到stash
git stash save "Important changes"

# 然后误删了stash
git stash drop stash@{0}

# 完了！重要修改没了！

场景3：悬空对象恢复

# 仓库出现损坏或数据丢失
git fsck
# 输出：dangling blob 1234567…

2.2 fsck原理

git fsck（文件系统检查）用于验证Git对象数据库的完整性，可以找到"悬空对象"（dangling objects）——那些不再被任何引用指向的对象。

悬空对象类型：

• dangling commit：完整的提交记录，包含作者、时间、消息和tree结构
• dangling blob：单个文件内容，无路径信息
• dangling tree：目录结构快照，对应某次提交中的文件夹布局

2.3 实战案例

案例1：恢复已暂存但未提交的文件

# 1. 扫描悬空对象
git fsck –lost-found

# 输出示例：
# dangling blob 1234567890abcdef1234567890abcdef12345678
# dangling blob abcdef1234567890abcdef1234567890abcdef12

# 2. 查看悬空对象内容
git show 1234567890abcdef1234567890abcdef12345678

# 3. 找到目标文件后，保存到新文件
git show 1234567890abcdef1234567890abcdef12345678 > recovered-file.txt

# 4. 验证文件内容
cat recovered-file.txt

案例2：恢复误删的stash

# 1. 查找所有悬空提交（stash本质是特殊提交）
git fsck –no-reflogs | grep "dangling commit"

# 输出示例：
# dangling commit abc1234567890def1234567890def1234567890
# dangling commit def4567890123abc4567890123abc4567890123

# 2. 查看每个悬空提交的详细信息
git show abc1234567890def1234567890def1234567890

# 3. 找到目标stash后，创建新分支
git checkout -b recovered-stash abc1234567890def1234567890def1234567890

# 4. 将修改应用到当前分支
git checkout main
git merge recovered-stash –squash
git commit -m "Recover from deleted stash"

案例3：批量恢复悬空文件

# 1. 找出所有悬空blob
git fsck –lost-found | grep "dangling blob" | awk '{print $3}' > dangling_blobs.txt

# 2. 批量查看并保存
while read blob; do
echo "Processing blob: $blob"
git show $blob > "recovered_$blob.txt"
done < dangling_blobs.txt

# 3. 使用编辑器打开文件，查找目标内容
code recovered_*.txt

2.4 高级技巧

技巧1：按时间筛选悬空对象

# 查看最近3天的悬空对象
git fsck –no-reflog | grep "dangling commit" | awk '{print $3}' | \\
while read hash; do
echo "=================================================="
echo "Commit: $hash"
git log -1 –format="%ai %s" $hash
done | grep "$(date -d '3 days ago' +%Y-%m-%d)"

技巧2：查找特定内容的悬空对象

# 查找包含特定关键词的悬空blob
git fsck –lost-found | grep "dangling blob" | awk '{print $3}' | \\
while read blob; do
if git show $blob | grep -q "IMPORTANT_KEYWORD"; then
echo "Found in blob: $blob"
git show $blob > "recovered_$blob.txt"
fi
done

技巧3：恢复整个目录结构

# 1. 找到悬空tree对象
git fsck –lost-found | grep "dangling tree"

# 2. 查看tree对象内容
git ls-tree abc1234567890def1234567890def1234567890

# 3. 恢复整个目录
git read-tree abc1234567890def1234567890def1234567890
git checkout-index -a -f

2.5 注意事项

⚠️ 重要提醒：

三、git cherry-pick：精准迁移提交

3.1 崩溃场景

场景1：提交到错误分支

# 本应该提交到feature分支，结果提交到了main分支
git checkout main
git add .
git commit -m "New feature implementation"

# 完了！提交错分支了！

场景2：需要从其他分支移植特定功能

# dev分支有个重要修复，需要同步到main分支
# 但不想合并整个dev分支

场景3：撤销错误提交后重新应用

# 不小心把提交推到了错误的远程分支
# 需要撤销后重新推到正确分支

3.2 cherry-pick原理

git cherry-pick 用于选择性地将单个或多个提交从一个分支复制到另一个分支。它允许你"挑选"特定的提交应用到当前分支，而不必合并整个分支。

核心特点：

• 复制提交而非移动（源提交仍保留）
• 适用于跨分支复用特定提交
• 可以处理单个或多个连续/非连续提交
• 会创建新的提交（哈希值不同）

3.3 实战案例

案例1：纠正提交到错误分支

# 场景：不小心把feature代码提交到了main分支

# 1. 记录错误提交的哈希
git log –oneline -1
# abc1234 Add new feature (错误提交)

# 2. 切换到正确的分支
git checkout feature/new-feature

# 3. 使用cherry-pick迁移提交
git cherry-pick abc1234

# 4. 回到错误分支，撤销错误提交
git checkout main
git reset –hard HEAD~1

# 5. 验证提交已正确迁移
git log –oneline feature/new-feature

案例2：从dev分支移植特定修复到main

# 1. 查看dev分支的提交历史
git log dev –oneline -10

# 输出：
# abc1234 Fix critical security issue
# def5678 Add new feature
# ghi9012 Refactor code
# jkl3456 Fix performance bug

# 2. 切换到main分支
git checkout main

# 3. 只移植安全修复提交
git cherry-pick abc1234

# 4. 如果有冲突，解决后继续
# 冲突解决后：
git add .
git cherry-pick –continue

# 5. 验证修复已应用
git log –oneline -1

案例3：批量迁移多个提交

# 1. 查看需要迁移的提交范围
git log feature/branch –oneline

# 输出：
# abc1234 Commit 3
# def5678 Commit 2
# ghi9012 Commit 1

# 2. 切换到目标分支
git checkout main

# 3. 迁移多个连续提交（注意顺序：从旧到新）
git cherry-pick ghi9012..abc1234

# 或者迁移非连续提交
git cherry-pick ghi9012 def5678 abc1234

# 4. 处理可能的冲突
# 如果遇到冲突：
git status
# 解决冲突后：
git add .
git cherry-pick –continue

# 如果想跳过当前提交：
git cherry-pick –skip

# 如果想完全中止：
git cherry-pick –abort

3.4 高级技巧

技巧1：保留原提交信息

# 默认会保留原提交信息
git cherry-pick abc1234

# 如果需要编辑提交信息：
git cherry-pick -e abc1234

# 如果需要完全自定义提交信息：
git cherry-pick -n abc1234 # 只应用更改，不自动提交
git commit -m "Custom commit message"

技巧2：处理冲突的高级策略

# 策略1：使用ours/theirs解决冲突
git cherry-pick abc1234 -X ours # 保留当前分支版本
git cherry-pick abc1234 -X theirs # 保留被移植分支版本

# 策略2：手动解决复杂冲突
git cherry-pick abc1234
# 遇到冲突后，使用图形化工具
git mergetool
# 解决后继续
git add .
git cherry-pick –continue

技巧3：批量操作和自动化

# 批量迁移某个作者的所有提交
git log –author="John" –format="%H" | \\
while read commit; do
git cherry-pick $commit || git cherry-pick –abort
done

# 从文件读取提交列表批量迁移
cat commits.txt | while read commit; do
git cherry-pick $commit
done

3.5 注意事项

⚠️ 重要提醒：

四、git fetch –prune：清理远程失联

4.1 崩溃场景

场景1：远程分支被删除，本地仍显示

# 同事删除了远程分支
# 但本地执行 git branch -r 仍然能看到

git branch -r
# origin/feature/old-branch # 这个分支已经不存在了！

场景2：切换仓库后分支引用混乱

# 更换了远程仓库地址
# 但本地还保留着旧仓库的分支引用

git remote -v
# origin https://new-repo.git (fetch)
# origin https://new-repo.git (push)

git branch -r
# origin/old-feature # 这是旧仓库的分支！

场景3：CI/CD脚本因陈旧引用失败

# 自动化脚本尝试切换到已删除的分支
git checkout origin/deleted-branch
# error: pathspec 'origin/deleted-branch' did not match any file(s) known to git

4.2 fetch –prune原理

git fetch –prune（或简写 git fetch -p）用于清理本地存储的、远程已不存在的分支引用。它会：

工作原理：

远程仓库状态： [main, feature/a, feature/b]
本地引用状态： [main, feature/a, feature/b, feature/c(已删除)]

执行 git fetch –prune 后：
本地引用状态： [main, feature/a, feature/b] # feature/c被清理

4.3 实战案例

案例1：清理所有已删除的远程分支

# 方法1：使用 –prune 参数
git fetch –prune

# 方法2：使用简写 -p
git fetch -p

# 方法3：指定远程仓库
git fetch –prune origin

# 验证清理结果
git branch -r

案例2：配置自动清理

# 方案1：全局配置，所有仓库自动清理
git config –global fetch.prune true

# 方案2：仅当前仓库自动清理
git config fetch.prune true

# 方案3：为特定远程仓库配置
git config remote.origin.prune true

# 验证配置
git config –get fetch.prune
# 输出：true

案例3：预览将被清理的分支

# 使用 –dry-run 预览将被删除的引用
git fetch –prune –dry-run

# 输出示例：
# From https://github.com/user/repo
# * [would prune] origin/feature/old-branch
# * [would prune] origin/bugfix/deprecated

案例4：清理特定远程仓库

# 查看所有远程仓库
git remote -v

# 输出：
# origin https://github.com/user/repo.git (fetch)
# upstream https://github.com/other/repo.git (fetch)

# 只清理upstream的陈旧引用
git fetch –prune upstream

# 验证
git branch -r | grep upstream

4.4 高级技巧

技巧1：结合其他命令使用

# 清理后立即查看干净的分支列表
git fetch -p && git branch -r

# 清理并删除本地对应的远程跟踪分支
git fetch -p
git remote prune origin

# 清理并更新所有子模块
git fetch -p && git submodule update –remote

技巧2：在脚本中安全使用

#!/bin/bash
# 安全的fetch脚本

echo "Fetching updates…"
if git fetch –prune 2>&1 | grep -q "error"; then
echo "Fetch failed, aborting"
exit 1
fi

echo "Cleanup complete!"
git branch -r

技巧3：处理特殊情况

# 如果远程仓库不可达，强制清理本地引用
git remote prune origin

# 清理所有远程仓库的陈旧引用
for remote in $(git remote); do
echo "Pruning $remote…"
git fetch –prune $remote
done

4.5 注意事项

⚠️ 重要提醒：

五、git revert：安全回滚远程提交

5.1 崩溃场景

场景1：已推送的错误提交

# 不小心把错误代码推到了远程main分支
git add .
git commit -m "Fix bug"
git push origin main

# 然后发现改错了！但已经推送到远程了！

场景2：团队协作中需要撤销提交

# 同事提交了有问题的代码
# 需要撤销但不能使用reset（会影响其他人）

场景3：生产环境紧急回滚

# 刚部署的版本有问题
# 需要立即回滚但保留历史记录

5.2 revert原理

git revert 是最安全的代码回退方式，它不会删除/修改历史提交记录，而是生成一个新的提交来"抵消"目标提交的所有修改。

与reset的区别：

git reset: [A] <- [B] <- [C] 删除C，回到B
(修改历史，危险！)

git revert: [A] <- [B] <- [C] <- [D=revert C]
(保留历史，安全！)

核心优势：

• 不修改提交历史
• 适合团队协作
• 可以安全地推送到远程
• 保留完整的审计轨迹

5.3 实战案例

案例1：撤销最近一次提交

# 1. 查看提交历史
git log –oneline -3

# 输出：
# abc1234 (HEAD -> main) Fix bug (错误提交)
# def5678 Add new feature
# ghi9012 Initial commit

# 2. 撤销最近一次提交
git revert HEAD

# 3. 编辑器会打开，填写撤销说明
# 默认信息：Revert "Fix bug"
# 可以修改为更详细的说明

# 4. 保存退出后，会创建新的撤销提交
git log –oneline -4

# 输出：
# jkl3456 Revert "Fix bug"
# abc1234 Fix bug
# def5678 Add new feature
# ghi9012 Initial commit

# 5. 推送到远程
git push origin main

案例2：撤销指定提交

# 1. 查看提交历史，找到要撤销的提交
git log –oneline

# 输出：
# abc1234 (HEAD -> main) Latest changes
# def5678 Add experimental feature (要撤销这个)
# ghi9012 Fix critical bug
# jkl3456 Initial commit

# 2. 撤销指定提交
git revert def5678

# 3. 如果有冲突，解决后继续
# 解决冲突：
git status
# 编辑冲突文件…
git add .
git revert –continue

# 4. 推送到远程
git push origin main

案例3：撤销多个连续提交

# 1. 查看提交历史
git log –oneline -5

# 输出：
# abc1234 Commit 4
# def5678 Commit 3
# ghi9012 Commit 2
# jkl3456 Commit 1
# mno7890 Previous commit

# 2. 撤销Commit 1到Commit 3（注意顺序：旧提交在前，新提交在后）
git revert jkl3456..def5678

# 3. 这会创建3个新的撤销提交
git log –oneline -8

# 输出：
# pqr1234 Revert "Commit 3"
# stu5678 Revert "Commit 2"
# vwx9012 Revert "Commit 1"
# abc1234 Commit 4
# def5678 Commit 3
# ghi9012 Commit 2
# jkl3456 Commit 1
# mno7890 Previous commit

案例4：撤销合并提交

# 1. 查看合并提交
git log –oneline –graph

# 输出：
# * abc1234 (HEAD -> main) Merge branch 'feature'
# |\\
# | * def5678 (feature) Add new feature
# | * ghi9012 Fix bug
# |/
# * jkl3456 Previous commit

# 2. 撤销合并提交（需要指定-m参数）
git revert -m 1 abc1234

# -m 1 表示保留主分支（第一个父提交）
# -m 2 表示保留feature分支（第二个父提交）

# 3. 推送到远程
git push origin main

5.4 高级技巧

技巧1：批量撤销并压缩为一个提交

# 撤销多个提交但只创建一个撤销提交
git revert –no-commit abc1234 def5678 ghi9012
git commit -m "Revert multiple commits: abc1234, def5678, ghi9012"

技巧2：撤销但不自动提交

# 只应用撤销的更改，不自动提交
git revert –no-commit abc1234

# 然后可以：
# 1. 查看更改：git diff
# 2. 修改部分更改
# 3. 手动提交：git commit -m "Custom revert message"

技巧3：处理复杂的冲突场景

# 如果撤销时遇到复杂冲突
git revert abc1234

# 遇到冲突后，可以选择：
# 1. 使用我们的版本（当前分支）
git checkout –ours file.txt
git add file.txt
git revert –continue

# 2. 使用他们的版本（被撤销的提交）
git checkout –theirs file.txt
git add file.txt
git revert –continue

# 3. 完全中止撤销
git revert –abort

5.5 注意事项

⚠️ 重要提醒：

六、额外福利：两个实用命令

6.1 git bisect：二分法定位Bug

适用场景：在大量提交中快速定位引入Bug的提交

# 1. 开始bisect
git bisect start

# 2. 标记当前版本为bad
git bisect bad

# 3. 标记已知好版本
git bisect good abc1234

# 4. Git会自动检出中间版本，测试后标记
# 如果有问题：
git bisect bad
# 如果没问题：
git bisect good

# 5. 重复步骤4，直到找到引入Bug的提交
# Git会输出：first bad commit: [hash] Commit message

# 6. 结束bisect
git bisect reset

6.2 git worktree：多工作目录并行开发

适用场景：同时在多个分支上工作，避免频繁stash/checkout

# 1. 创建新的工作目录
git worktree add ../feature-branch feature/new-feature

# 2. 在新目录中独立工作
cd ../feature-branch
# 正常开发，不会影响主目录

# 3. 列出所有工作树
git worktree list

# 4. 删除工作树（不会删除分支）
git worktree remove ../feature-branch

# 5. 清理已删除的工作树引用
git worktree prune

七、总结与最佳实践

7.1 5个命令速查表

7.2 应急响应流程图

遇到Git事故
↓
是否已推送远程？
↓
是 → 使用 git revert (安全)
↓
否 → 是否有未提交更改？
↓
是 → 使用 git stash 或直接恢复
↓
否 → 使用 git reflog 或 git reset
↓
文件未跟踪？ → 使用 git fsck

7.3 预防措施

日常开发最佳实践：

配置建议：

# 延长reflog保留时间
git config –global gc.reflogExpire "180 days"

# 启用自动清理
git config –global fetch.prune true

# 设置别名方便使用
git config –global alias.recover-reflog '!git reflog | head -20'
git config –global alias.find-dangling '!git fsck –lost-found | grep "dangling"'

7.4 学习路径

初级（0-1个月）：

• 掌握 git reflog 基础用法
• 学会使用 git fetch –prune
• 理解 git revert 与 reset 的区别

中级（1-3个月）：

• 熟练使用 git cherry-pick
• 掌握 git fsck 恢复文件
• 学会处理冲突和复杂场景

高级（3-6个月）：

• 自动化脚本编写
• 团队协作中的最佳实践
• 深入理解Git内部机制

八、结语

Git的强大之处不仅在于日常的版本控制，更在于它提供了丰富的"后悔药"和"急救工具"。掌握这5个冷门但救命的命令，让你在面对Git事故时能够从容应对，化险为夷。

记住：

• 遇事不慌，先看 git reflog
• 误删文件，试试 git fsck
• 提交错分支，用 git cherry-pick
• 远程失联，执行 git fetch –prune
• 已推送错误，选择 git revert

从今天开始，把这些命令加入你的Git工具箱，让Git真正成为你开发路上的得力助手！

附录：快速参考卡

# 1. 恢复误删分支
git reflog
git checkout -b recovered-branch <commit-hash>

# 2. 恢复未提交文件
git fsck –lost-found
git show <blob-hash> > recovered-file.txt

# 3. 迁移提交到正确分支
git checkout correct-branch
git cherry-pick <commit-hash>

# 4. 清理远程失联分支
git fetch –prune
# 或配置自动清理
git config –global fetch.prune true

# 5. 安全回滚已推送提交
git revert <commit-hash>
git push origin main

本文基于2026年4月最新Git实践编写，建议定期关注Git官方文档获取最新特性。