mcpField
F
fix-git

fix-git

github.com/letta-ai开发15237 次安装4 周前更新
代码仓库

关于 fix-git

fix-git 是用于诊断和恢复常见 Git 问题的技能，重点处理丢失的提交和 detached HEAD 中的工作。它说明恢复方案、安全步骤、冲突处理与结果验证。

主要功能

  1. 01检查仓库状态与 reflog
  2. 02通过 merge 或 cherry-pick 恢复提交
  3. 03恢复前创建安全分支
  4. 04处理并验证合并冲突

适用场景

  1. 01查找分支历史中缺失的提交
  2. 02恢复在 detached HEAD 中提交的工作
  3. 03找回意外 reset 后的工作

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/letta-ai/skills --skill fix-git

安装后在 Claude Code 中输入/fix-git确认已加载。

详细介绍

Git 恢复与修复技能

此技能提供系统化的方法，用于诊断和恢复常见的 Git 问题，尤其是提交丢失和分离的 HEAD 状态。

何时使用此技能

  • 恢复看似“丢失”或缺失的提交
  • 修复已提交工作但不在任何分支上的分离 HEAD 状态
  • 从意外的 git reset 或 git checkout 操作中恢复
  • 在未提交的情况下切换分支后恢复工作
  • 调查仓库中缺失的更改

诊断方法

初步评估

要诊断 Git 恢复问题，请并行运行以下命令以了解仓库状态：

  1. git status - 检查当前工作目录状态和分支
  2. git reflog - 查看 HEAD 移动历史（查找丢失的提交时至关重要）
  3. git branch -a - 列出所有分支，包括远程分支
  4. git log --oneline -10 - 查看当前分支上的近期提交历史
理解 Reflog 输出

reflog 是恢复时最重要的工具。它会显示 HEAD 曾指向的每个位置，包括：

  • 在分离的 HEAD 状态下创建的提交
  • 重置之前的位置
  • 分支切换和检出操作

Reflog 条目的格式为：<commit-hash> HEAD@{n}: <action>: <message>

留意以下条目：

  • commit: - 创建了一个提交（可能是待恢复的目标）
  • checkout: - 发生了分支切换（可能显示提交遗留的位置）
  • reset: - 执行了重置（此时间点之后的提交可能需要恢复）

恢复策略

策略 1：合并丢失的提交

当提交存在于 reflog 中，但不属于任何分支时：

# First, ensure on the target branch
git checkout <target-branch>

# Merge the lost commit
git merge <commit-hash>

这会保留提交历史及其关系。

策略 2：挑选丢失的提交

当不希望合并，或只需要特定提交时，可采用此替代方案：

git checkout <target-branch>
git cherry-pick <commit-hash>

以下情况适合使用 cherry-pick：

  • 只需要一系列提交中的特定提交
  • 希望提交历史呈线性
  • 合并会引入不需要的更改
策略 3：创建恢复分支

执行恢复操作前，先创建一个安全分支：

# Create a branch at the lost commit for safety
git branch recovery-<descriptive-name> <commit-hash>

# Then proceed with merge or cherry-pick
git checkout <target-branch>
git merge recovery-<descriptive-name>

如果恢复过程出错，这会提供一个回滚点。

策略 4：重置到丢失的提交

当需要将当前分支移动到丢失的提交时（请谨慎使用）：

# Soft reset preserves changes in staging
git reset --soft <commit-hash>

# Mixed reset (default) preserves changes in working directory
git reset <commit-hash>

# Hard reset discards all changes (dangerous)
git reset --hard <commit-hash>

恢复过程中的冲突解决

处理合并冲突

合并恢复的提交时发生冲突：

  1. 找出冲突文件：git status 会显示存在冲突的文件
  2. 阅读冲突文件，了解两个版本的内容
  3. 寻找上下文线索：提交消息通常会说明意图（例如，“Move to Stanford” 表示哪个版本正确）
  4. 编辑以解决冲突：移除冲突标记并保留正确内容
  5. 验证解决结果：重新阅读文件，确认已移除所有冲突标记
  6. 完成合并： 
    git add <resolved-files>
git commit
冲突标记格式
<<<<<<< HEAD
Current branch content
=======
Incoming commit content
>>>>>>> <commit-hash>

移除全部三行标记，并保留所需内容。

验证步骤

执行任何恢复操作后，请验证是否成功：

  1. 检查所有已修改的文件：恢复的提交修改了多个文件时，逐一检查

    git show <commit-hash> --stat  # See which files were modified

  2. 验证文件内容：阅读恢复涉及的文件，确认内容正确

  3. 检查是否还有冲突标记：在已修改的文件中搜索 <<<<<<<、======= 或 >>>>>>>

  4. 检查提交历史：

    git log --oneline -5

  5. 如果有测试，则运行测试：执行任何测试套件以验证功能

常见陷阱

陷阱 1：未彻底解决冲突

问题：声称已解决冲突，但文件中仍残留冲突标记。

预防方法：编辑后务必重新阅读文件，确认所有标记均已移除。

陷阱 2：忽略自动合并的文件

问题：只关注存在冲突的文件，而忽略可能有问题的自动合并文件。

预防：使用 git show <commit-hash> --stat 查看恢复的提交修改了哪些文件，并逐一检查。

陷阱 3：未创建安全分支

问题：执行恢复操作时没有回滚点。

预防：在合并或重置之前，记下当前 HEAD 位置或创建一个分支：

git branch backup-before-recovery
陷阱 4：垃圾回收风险

问题：处于分离 HEAD 状态的提交，如果没有被分支或标签引用，最终可能会被垃圾回收。

预防：及时为重要提交创建分支：

git branch save-work <commit-hash>
陷阱 5：以为只丢失了一个提交

问题：可能有多个提交成为孤立提交，却只恢复最近丢失的提交。

预防：检查完整的 reflog，找出所有可能需要恢复的提交：

git reflog | head -20

决策框架

恢复丢失的工作时，请根据以下因素选择合适的方法：

情况推荐方法
单个提交，希望保留完整历史记录git merge
单个提交，希望保留线性历史记录git cherry-pick
多个相关提交git merge 最新的提交（包含其祖先提交）
多个不相关的提交逐个对其执行 git cherry-pick
不确定如何恢复先创建分支，再合并
需要彻底移动分支git reset（谨慎使用）

恢复后的最佳实践

成功恢复后：

  1. 记录发生的情况：了解原因有助于防止问题再次发生
  2. 检查是否存在类似问题：其他工作也可能成为孤立工作
  3. 考虑改进工作流：分离 HEAD 通常是因为执行了 git checkout <commit>，却没有创建分支

评论

支持 Markdown