fix-git

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Recovery and Fix Skill

Git恢复与问题修复技能

This skill provides systematic approaches for diagnosing and recovering from common Git problems, particularly lost commits and detached HEAD situations.

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

When to Use This Skill

适用场景

Recovering commits that appear to be "lost" or missing
Fixing detached HEAD states where work was committed but not on a branch
Recovering from accidental
```
git reset
```
or
```
git checkout
```
operations
Restoring work after switching branches without committing
Investigating what happened to missing changes in a repository

恢复看似“丢失”或消失的提交
修复在分离HEAD状态下提交但未关联到分支的问题
从意外执行
```
git reset
```
或
```
git checkout
```
操作中恢复
在未提交就切换分支后恢复工作内容
排查仓库中变更消失的原因

Diagnostic Approach

诊断方法

Initial Assessment

初步评估

To diagnose a Git recovery situation, run these commands in parallel to understand the repository state:

```
git status
```
- Check current working directory state and branch
```
git reflog
```
- View history of HEAD movements (critical for finding lost commits)
```
git branch -a
```
- List all branches including remotes
```
git log --oneline -10
```
- View recent commit history on current branch

要诊断Git恢复场景，可并行执行以下命令来了解仓库状态：

```
git status
```
- 检查当前工作目录状态和分支
```
git reflog
```
- 查看HEAD的移动历史（这是查找丢失提交的关键工具）
```
git branch -a
```
- 列出所有分支，包括远程分支
```
git log --oneline -10
```
- 查看当前分支的最近10条提交历史

Understanding Reflog Output

理解Reflog输出

The reflog is the most important tool for recovery. It shows every position HEAD has been in, including:

Commits made in detached HEAD state
Positions before resets
Branch switches and checkouts

Reflog entries follow the format:

<commit-hash> HEAD@{n}: <action>: <message>

Look for entries that indicate:

```
commit:
```
- A commit was made (potential recovery target)
```
checkout:
```
- A branch switch occurred (may indicate where commits were left behind)
```
reset:
```
- A reset was performed (commits after this point may need recovery)

Reflog是恢复操作中最重要的工具，它记录了HEAD所有曾经指向的位置，包括：

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

Reflog条目格式为：

<commit-hash> HEAD@{n}: <action>: <message>

需要重点关注以下类型的条目：

```
commit:
```
- 表示创建了提交（潜在的恢复目标）
```
checkout:
```
- 表示执行了分支切换（可能是提交被遗留的原因）
```
reset:
```
- 表示执行了重置操作（该操作之后的提交可能需要恢复）

Recovery Strategies

恢复策略

Strategy 1: Merge Lost Commit

策略1：合并丢失的提交

When a commit exists in reflog but not on any branch:

bash

undefined

当提交存在于Reflog但未关联到任何分支时：

bash

undefined

First, ensure on the target branch

首先切换到目标分支

git checkout <target-branch>

Merge the lost commit

合并丢失的提交

git merge <commit-hash>


This preserves commit history and relationships.

git merge <commit-hash>


此方法可保留提交历史及关联关系。

Strategy 2: Cherry-pick Lost Commit

策略2：拣选丢失的提交

Alternative when merge is not desired or when only specific commits are needed:

bash

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

Use cherry-pick when:

Only specific commits from a series are needed
The commit history should appear linear
Merge would bring in unwanted changes

当不希望使用合并，或仅需要恢复特定提交时，可使用此替代方案：

bash

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

适合使用拣选的场景：

仅需要恢复一系列提交中的特定几个
希望提交历史保持线性
合并会引入不需要的变更

Strategy 3: Create Recovery Branch

策略3：创建恢复分支

Before performing recovery operations, create a safety branch:

bash

undefined

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

bash

undefined

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>


This provides a rollback point if recovery goes wrong.

git checkout <target-branch> git merge recovery-<descriptive-name>


如果恢复操作出现问题，此分支可作为回滚点。

Strategy 4: Reset to Lost Commit

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

When the current branch should be moved to a lost commit (use with caution):

bash

undefined

当需要将当前分支完全移动到丢失的提交位置时（需谨慎操作）：

bash

undefined

Soft reset preserves changes in staging

--soft重置会保留变更在暂存区

git reset --soft <commit-hash>

Mixed reset (default) preserves changes in working directory

默认的mixed重置会保留变更在工作目录

git reset <commit-hash>

Hard reset discards all changes (dangerous)

--hard重置会丢弃所有变更（危险操作）

git reset --hard <commit-hash>

undefined

git reset --hard <commit-hash>

undefined

Conflict Resolution During Recovery

恢复过程中的冲突解决

Handling Merge Conflicts

处理合并冲突

When merging a recovered commit causes conflicts:

Identify conflicting files:
```
git status
```
shows files with conflicts
Read the conflicting file to understand both versions
Look for context clues: Commit messages often indicate intent (e.g., "Move to Stanford" suggests which version is correct)
Edit to resolve: Remove conflict markers and keep correct content
Verify resolution: Re-read the file to confirm all conflict markers are removed
Complete the merge:
bash
```
git add <resolved-files>
git commit
```

合并恢复的提交时出现冲突的解决步骤：

识别冲突文件：
```
git status
```
会显示存在冲突的文件
查看冲突文件：了解冲突双方的内容
寻找上下文线索：提交信息通常能体现意图（例如“迁移到斯坦福”可提示哪个版本是正确的）
编辑解决冲突：移除冲突标记并保留正确内容
验证冲突解决结果：重新查看文件，确认所有冲突标记已移除
完成合并：
bash
```
git add <resolved-files>
git commit
```

Conflict Marker Format

冲突标记格式

<<<<<<< HEAD
Current branch content
=======
Incoming commit content
>>>>>>> <commit-hash>

Remove all three marker lines and keep the desired content.

<<<<<<< HEAD
当前分支内容
=======
待合并的提交内容
>>>>>>> <commit-hash>

移除所有三行标记，并保留需要的内容。

Verification Steps

验证步骤

After any recovery operation, verify success:

Check all modified files: When a recovered commit modified multiple files, examine each one
bash
```
git show <commit-hash> --stat  # See which files were modified
```
Verify file contents: Read files that were part of the recovery to confirm correct content
Check for remaining conflict markers: Search for
```
<<<<<<<
```
,
```
=======
```
, or
```
>>>>>>>
```
in modified files
Review commit history:
bash
```
git log --oneline -5
```
Run tests if available: Execute any test suite to verify functionality

完成任何恢复操作后，需验证是否成功：

检查所有修改的文件：如果恢复的提交修改了多个文件，需逐一检查
bash
```
git show <commit-hash> --stat  # 查看该提交修改的文件列表
```
验证文件内容：查看恢复涉及的文件，确认内容正确
检查残留的冲突标记：在修改过的文件中搜索
```
<<<<<<<
```
、
```
=======
```
或
```
>>>>>>>
```
查看提交历史：
bash
```
git log --oneline -5
```
运行测试（如有）：执行测试套件验证功能正常

Common Pitfalls

常见误区

Pitfall 1: Incomplete Conflict Resolution

误区1：冲突解决不彻底

Problem: Conflict markers left in files after supposedly resolving conflicts.

Prevention: Always re-read files after editing to confirm all markers are removed.

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

预防措施：编辑文件后务必重新查看，确认所有标记已移除。

Pitfall 2: Ignoring Auto-merged Files

误区2：忽略自动合并的文件

Problem: Focusing only on files with conflicts while ignoring auto-merged files that may have issues.

Prevention: Check

git show <commit-hash> --stat

to see all files modified by the recovered commit, and verify each one.

问题：仅关注存在冲突的文件，忽略了自动合并但可能存在问题的文件。

预防措施：通过

git show <commit-hash> --stat

查看恢复提交修改的所有文件，并逐一验证。

Pitfall 3: Not Creating a Safety Branch

误区3：未创建安全分支

Problem: Performing recovery operations without a rollback point.

Prevention: Before merging or resetting, note the current HEAD position or create a branch:

bash

git branch backup-before-recovery

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

预防措施：在执行合并或重置前，记录当前HEAD位置或创建备份分支：

bash

git branch backup-before-recovery

Pitfall 4: Garbage Collection Risk

误区4：垃圾回收风险

Problem: Commits in detached HEAD state can eventually be garbage collected if not referenced by a branch or tag.

Prevention: Create a branch at important commits promptly:

bash

git branch save-work <commit-hash>

问题：分离HEAD状态下的提交如果未被分支或标签引用，最终会被垃圾回收清理。

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

bash

git branch save-work <commit-hash>

Pitfall 5: Assuming Single Lost Commit

误区5：假设只有单个丢失的提交

Problem: Only recovering the most recent lost commit when multiple commits may be orphaned.

Prevention: Examine the full reflog to identify all commits that may need recovery:

bash

git reflog | head -20

问题：仅恢复了最近的丢失提交，但可能存在多个孤立的提交。

预防措施：查看完整的Reflog，识别所有需要恢复的提交：

bash

git reflog | head -20

Decision Framework

决策框架

When recovering lost work, choose the approach based on these factors:

Situation	Recommended Approach
Single commit, want full history	`git merge`
Single commit, want linear history	`git cherry-pick`
Multiple related commits	`git merge` the most recent (includes ancestors)
Multiple unrelated commits	`git cherry-pick` each one
Uncertain about recovery	Create branch first, then merge
Need to completely move branch	`git reset` (with caution)

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

场景	推荐方法
单个提交，希望保留完整历史	`git merge`
单个提交，希望历史保持线性	`git cherry-pick`
多个相关联的提交	`git merge` 最新的提交（会包含所有祖先提交）
多个无关联的提交	逐个执行 `git cherry-pick`
对恢复操作不确定	先创建分支，再执行合并
需要将分支完全移动到目标位置	`git reset` （谨慎操作）

Post-Recovery Best Practices

恢复后最佳实践

After successful recovery:

Document what happened: Understanding the cause prevents recurrence
Check for similar issues: Other work may also be orphaned
Consider workflow improvements: Detached HEAD often results from
```
git checkout <commit>
```
without creating a branch

成功恢复后：

记录问题原因：了解问题根源可避免再次发生
检查是否存在类似问题：可能还有其他孤立的工作内容
考虑优化工作流程：分离HEAD状态通常是因为执行
```
git checkout <commit>
```
时未创建分支导致的