fix-git

Git の復旧と修正スキル

このスキルでは、一般的な Git の問題、特に失われたコミットや detached HEAD 状態を診断して復旧するための体系的な方法を説明します。

このスキルを使う場面

• 「失われた」または見つからないように見えるコミットを復旧する
• 作業をコミットしたもののブランチに属していない detached 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 がこれまでに指していたすべての位置が表示されます。これには次のものが含まれます。

• detached 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>

次のような場合はチェリーピックを使います。

• 一連のコミットのうち特定のものだけが必要な場合
• コミット履歴を直線的に見せたい場合
• マージによって不要な変更が取り込まれる場合

方法 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>

3 つのマーカー行をすべて削除し、必要な内容を残します。

検証手順

復旧操作の後は、成功したことを確認します。

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：失われたコミットは 1 つだけだと思い込む

問題：複数のコミットが孤立している可能性があるにもかかわらず、直近の失われたコミットだけを復元してしまいます。

防止策：完全な reflog を調べて、復元が必要な可能性のあるすべてのコミットを特定します。

git reflog | head -20

判断の枠組み

失われた作業を復元するときは、次の要素に基づいて方法を選びます。

状況	推奨する方法
コミットが 1 つで、履歴全体を残したい	git merge
コミットが 1 つで、直線的な履歴にしたい	git cherry-pick
関連するコミットが複数ある	最新のコミットを git merge する（祖先コミットも含まれます）
関連しないコミットが複数ある	それぞれを git cherry-pick する
復元方法が不確かな場合	まずブランチを作成してからマージする
ブランチを完全に移動する必要がある	git reset（慎重に実行）

復元後のベストプラクティス

復元が成功した後は、次のことを行います。

1. 何が起きたかを記録する：原因を理解することで、再発を防げます
2. 同様の問題がないか確認する：ほかの作業も孤立している可能性があります
3. ワークフローの改善を検討する：デタッチされた HEAD は、ブランチを作成せずに git checkout <commit> を実行した場合によく発生します