恢复删掉的分支

若本地和远程仓库均已删除 hotfix/cdef-6059 分支，但未进行 Git 垃圾回收（默认保留 90 天操作日志），可通过以下步骤恢复代码：

方法一：通过 Git Reflog 恢复（推荐）

1. 查看操作日志
   运行以下命令，查找与被删分支相关的操作记录（如创建、合并、删除等）：

   git reflog | grep -i 'hotfix/cdef-6059'
   

   或直接显示所有操作历史（按时间倒序）：

   git reflog
   

   输出示例：

   abc1234 HEAD@{1}: checkout: moving from main to hotfix/cdef-6059
   def5678 HEAD@{2}: commit: 修复了 cdef-6059 的问题
   ghi9012 HEAD@{3}: branch: Delete hotfix/cdef-6059  # 删除记录
   

2. 定位删除前的提交 ID
   找到删除操作前的提交哈希（如 def5678），此为分支最后一次有效提交。

3. 重建分支
   使用以下命令创建新分支并指向该提交：

   git branch hotfix/cdef-6059-recovery def5678
   git checkout hotfix/cdef-6059-recovery
   

4. 验证恢复
   检查文件是否完整：

   git log --oneline -3  # 查看最近提交
   ls  # 确认文件列表
   

方法二：通过 Git Fsck 恢复（当 Reflog 失效时）

若 Reflog 已过期或被清理，可扫描悬空对象（未被引用的提交）：

1. 查找悬空提交

   git fsck --full --no-reflogs --unreachable --lost-found | grep commit
   

   输出会显示悬空提交的哈希，如 commit abc1234。

2. 查看提交内容
   进入 .git/lost-found/commit 目录，检查可疑提交的详细信息：

   cd .git/lost-found/commit
   cat abc1234  # 查看提交内容
   

3. 重建分支
   找到正确提交后，创建新分支：

   git branch hotfix/cdef-6059-recovery abc1234
   git checkout hotfix/cdef-6059-recovery
   

方法三：通过远程仓库或团队协作恢复

1. 检查其他成员的本地仓库
   若团队其他成员未删除该分支，可请求其推送分支到远程：

   git push origin hotfix/cdef-6059
   

2. 利用 Pull Request 记录
   若分支曾发起过合并请求（PR），可通过 PR 的 Merge Commit 重建分支：

   • 在 GitHub/GitLab 等平台找到 PR 的 Merge Commit 哈希。
   • 本地创建分支指向该提交：

     git branch hotfix/cdef-6059-recovery a1b2c3d
     git checkout hotfix/cdef-6059-recovery
     

无法恢复的极端情况

若满足以下条件，代码可能永久丢失：

1. 主动执行了垃圾回收

   git gc --prune=now  # 立即清理未引用对象
   

2. Reflog 记录已过期
   Git 默认保留 90 天 Reflog，超期后自动清理。
3. 所有本地副本均被删除
   团队所有成员的本地仓库均无该分支。

防御性建议

1. 设置分支保护
   在 GitHub/GitLab 等平台启用 Protected Branches，禁止直接删除。
2. 定期备份
   使用脚本自动备份分支：

   # 每日备份所有分支到压缩包
   0 2 * * * git for-each-ref --format='%(refname:short)' refs/heads | xargs -I{} git bundle create ~/git-backups/$(date +\%Y\%m\%d)-{}.bundle {}
   

3. 配置删除确认
   创建 pre-delete 钩子脚本，删除前二次确认：

   #!/bin/sh
   echo "⚠️ 即将删除分支 $1，最后提交：$(git log -1 --format=%s $1)"
   read -p "确认删除？(y/n) " -n 1 -r
   echo
   if [[ ! $REPLY =~ ^[Yy]$ ]]; then
     echo "删除已取消"
     exit 1
   fi
   

   保存为 .git/hooks/pre-delete 并赋予执行权限：

   chmod +x .git/hooks/pre-delete
   

总结

• 优先尝试 Reflog：98% 的误删可通过此方法恢复（30 天内）。
• Reflog 失效时用 Fsck：扫描悬空提交，但需手动分析内容。
• 远程协作恢复：若分支曾推送过，可通过 PR 或同事仓库找回。
• 极端情况：主动 GC 或超期 Reflog 会导致不可恢复，需依赖专业数据恢复服务。

操作前建议：先执行 git clone --mirror 创建仓库镜像备份，避免操作失误导致进一步数据丢失。

2.之查找那个分支上的代码，无需找回分支

如果你想查找 hotfix/cdef-6059 分支上改动过的代码（即使该分支已被删除），但该分支曾被合并到 master，可以通过以下方法提取变更内容：

---

**方法 1：通过合并提交（Merge Comm

it）查找差异**
如果 hotfix/cdef-6059 是通过 Merge Commit（非 Fast-Forward）合并到 master 的，可以找到合并提交并查看其引入的变更。

步骤

1. 找到合并提交的哈希
   在 master 分支上查找包含 hotfix/cdef-6059 的合并提交：

   git log --merges --grep="cdef-6059" --oneline master
   

   或直接查看所有合并提交：

   git log --merges --oneline master
   

   输出示例：

   a1b2c3d Merge branch 'hotfix/cdef-6059' into master
   

2. 查看合并提交的变更
   使用 git show 查看该合并提交引入的所有变更：

   git show a1b2c3d
   

   或仅查看文件列表：

   git show --name-only a1b2c3d
   

3. 提取变更内容
   如果需要导出变更的代码（如补丁文件）：

   git format-patch -1 a1b2c3d --stdout > cdef-6059_changes.patch
   

---

方法 2：通过分支基点查找差异

如果 hotfix/cdef-6059 是通过 Rebase 或 Fast-Forward 合并的（无独立合并提交），可以通过以下方式找到变更：

步骤

1. 找到分支的起点和终点

   • 起点：hotfix/cdef-6059 分支从 master 分出的提交点。
   • 终点：合并到 master 后的最新提交。

   使用 git reflog 或 git log 查找分支的创建和删除记录（需在删除前操作）：

   git reflog | grep "hotfix/cdef-6059"
   

   或通过 git log 查找分支存在时的提交范围：

   git log master..hotfix/cdef-6059  # 假设分支未完全删除时
   

2. 手动比对变更
   如果无法直接获取分支范围，可以通过以下方式近似查找：

   • 找到 hotfix/cdef-6059 分支最后一次提交的哈希（通过 reflog 或团队协作记录）。
   • 比对该提交与 master 的差异：

     git diff <last-commit-of-branch>^..<last-commit-of-branch>
     

---

方法 3：通过 git cherry-pick 或补丁恢复

如果变更较少，可以尝试从合并后的 master 中反向筛选：

1. 列出合并后的所有提交
   找到合并后 master 的新增提交：

   git log master --grep="cdef-6059" --oneline
   

2. 提取特定提交的代码
   如果知道关键提交，直接查看变更：

   git show <commit-hash>
   

---

方法 4：通过 git fsck 恢复分支后比对

如果分支被删除但提交未被 GC 回收（默认 90 天）：

1. 恢复分支（参考之前的方法）：

   git fsck --lost-found | grep commit
   git show <lost-commit-hash>
   git branch recovery-branch <lost-commit-hash>
   

2. 比对恢复的分支与 master：

   git diff master..recovery-branch
   

---

关键注意事项

1. 合并方式的影响

   • Merge Commit：变更会集中在一个提交中，容易追踪。
   • Rebase/Fast-Forward：变更会分散在多个提交中，需通过提交时间或内容筛选。

2. 团队协作记录
   如果无法通过 Git 命令定位，检查团队的 PR/MR 记录（如 GitHub/GitLab），通常能直接看到变更文件。

3. 备份优先
   操作前建议先备份当前仓库：

   git clone --local /path/to/repo /path/to/backup
   

---

总结

• 有合并提交：直接通过 git show <merge-commit> 查看变更。
• 无合并提交：通过 git diff 或 git log 筛选分支存在期间的提交。
• 分支已删除：尝试用 git fsck 恢复后比对，或从 PR 记录中提取。

如果仍无法定位，提供以下信息可进一步分析：

1. git log --graph --oneline master 的输出（隐藏敏感信息）。
2. 分支合并的大致时间范围。
3. 是否通过 PR 合并（平台链接）。

查看合并前后的commitid

这个错误表明 Git 无法识别 a1b2c3d 和 e4f5g6h 这两个提交哈希（可能是我之前的示例占位符）。我们需要先获取 合并提交 bf0b84e87 的真实父提交哈希，才能正确比对差异。以下是修正后的步骤：

---

步骤 1：获取合并提交的父提交哈希

运行以下命令解析 bf0b84e87 的父提交：

git cat-file -p bf0b84e87 | grep parent

输出示例：

parent a1b2c3d123456789abcdef123456789abcdef0
parent e4f5g6h987654321fedcba987654321fedcba0

• 第一个 parent（a1b2c3d...）：合并前 master 的提交。
• 第二个 parent（e4f5g6h...）：hotfix/cdef-6059 分支的最后一次提交。

记下这两个哈希（实际值会很长，复制完整的前 7-10 个字符即可）。

---

步骤 2：比对差异

使用正确的父提交哈希生成差异文件：

git diff <master-parent-hash>..<hotfix-parent-hash> > cdef-6059_exact_changes.diff

例如：

git diff a1b2c3d123..e4f5g6h987 > cdef-6059_exact_changes.diff

---

替代方案：直接提取合并提交的变更

如果仍无法获取父提交哈希，可以直接从合并提交中提取 hotfix/cdef-6059 的变更（但可能包含合并时的冲突解决代码）：

git show -m bf0b84e87 > cdef-6059_merged_changes.diff

-m 参数会显示合并提交中来自 hotfix/cdef-6059 的变更（忽略冲突解决部分）。

---

验证提交哈希的另一种方法

如果 git cat-file 不可用，可以通过 git log 查看合并提交的详细信息：

git log -1 bf0b84e87 --pretty=raw

在输出中查找 parent 行：

commit bf0b84e87...
tree 123abc456...
parent a1b2c3d123...
parent e4f5g6h987...

---

关键问题排查

1. 如果提交哈希仍报错

   • 确认当前在 master 分支：git checkout master。
   • 检查提交是否存在：git rev-parse bf0b84e87（应返回完整哈希）。
   • 如果仓库是浅克隆（--depth），需先获取完整历史：git fetch --unshallow。

2. 分支已删除时的恢复技巧
   如果 hotfix/cdef-6059 被删除且无法通过 reflog 找到，可以尝试从远程恢复：

   git fetch origin +refs/original/*:refs/original/* --depth=100
   

   然后检查 refs/original/ 下的引用。

---

最终建议

1. 优先使用 git show bf0b84e87
   直接查看合并提交的完整变更（最简单，但可能包含冲突解决代码）。

2. 精确比对差异
   通过 git diff <master-parent>..<hotfix-parent> 获取纯净的分支变更（需正确解析父提交）。

3. 导出为补丁

   git format-patch -1 bf0b84e87 --stdout > cdef-6059.patch
   

   然后用文本编辑器或 git apply 处理补丁文件。

如果仍有问题，请提供 git cat-file -p bf0b84e87 的实际输出（隐藏敏感信息），以便进一步定位父提交。

导出纯净修改

现在我们已经获取了合并提交 bf0b84e87 的两个父提交哈希：

1. 3a167b84425fb2f3355dab2f6b670dcda80e550b → 合并前 master 的提交
2. 861c04ddeb541ccbe107d3057558af7d2f4b995a → hotfix/cdef-6059 分支的最后一次提交

---

方法 1：直接提取 hotfix/cdef-6059 的变更（推荐）

运行以下命令，比对 master 合并前的提交和 hotfix/cdef-6059 的最后一次提交：

git diff 3a167b844..861c04dde > cdef-6059_changes.diff

这会生成一个 .diff 文件，包含 hotfix/cdef-6059 分支的所有代码变更（不包括合并时的冲突解决）。

---

方法 2：查看合并提交的变更（包含冲突解决）

如果合并时有人工修改（如冲突解决），可以查看合并提交的实际变更：

git show bf0b84e87 > cdef-6059_merged_changes.diff

但这种方式可能会包含一些合并时调整的代码，不完全是 hotfix/cdef-6059 的原始变更。

---

方法 3：导出补丁文件（适用于应用变更）

如果需要将变更应用到其他分支，可以生成补丁文件：

git format-patch -1 bf0b84e87 --stdout > cdef-6059.patch

然后用 git apply 应用补丁：

git apply cdef-6059.patch

---

验证变更

1. 查看变更的文件列表（不显示具体代码）：

   git diff --name-only 3a167b844..861c04dde
   

2. 查看某个文件的变更（例如 src/app.js）：

   git show 861c04dde -- src/app.js
   

---

常见问题

1. 如果 git diff 报错 “unknown revision”

   • 确保当前在 master 分支：git checkout master
   • 检查提交是否存在：git rev-parse 3a167b844（应返回完整哈希）
   • 如果仓库是浅克隆（--depth），需获取完整历史：

     git fetch --unshallow
     

2. 如果 hotfix/cdef-6059 分支仍存在
   可以直接比对分支：

   git diff 3a167b844..hotfix/cdef-6059 > cdef-6059_changes.diff
   

---

总结

✅ 推荐命令（提取纯净变更）：

git diff 3a167b844..861c04dde > cdef-6059_changes.diff

✅ 查看变更文件列表：

git diff --name-only 3a167b844..861c04dde

✅ 生成补丁文件：

git format-patch -1 bf0b84e87 --stdout > cdef-6059.patch

这样就能准确获取 hotfix/cdef-6059 分支的所有代码变更！ 🚀