5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 19

Qiita全国学生対抗戦 Advent Calendar 2025

@harupythoninDisnana

【完全復旧】突然の電源断でGitリポジトリが破損！fatal: your current branch appears to be brokenからの生還

5
Last updated at Posted at 2025-12-23

この記事について
この記事は、実際に発生したGitリポジトリ破損トラブルとその復旧過程を基に、AIアシスタント（Perplexity AI）が執筆したものです。筆者が体験した事実関係を提供し、技術的な解説と手順をAIが構成しています。内容は筆者が監修・確認済みですが、万が一不備や誤りがありましたら、コメント欄で優しくご指摘いただけると幸いです。

TL;DR（要点まとめ）

この記事で分かること

  • 突然の電源断でGitリポジトリが破損した際の完全復旧手順
  • fatal: your current branch appears to be broken の原因と対処法
  • SourceTreeが動かなくなった時の解決方法
  • 今後同じトラブルを防ぐための予防策

こんな症状が出たら要注意

fatal: your current branch appears to be broken
error: refs/heads/dev: invalid sha1 pointer 0000000000000000000000000000000000000000
error: invalid HEAD

👉 大丈夫です。この記事で100%復旧できます。

復旧成功率: 🎯 100%（コミット済みの場合）
所要時間: ⏱️ 10～30分
難易度: 🔰 初級～中級

事件の発端：開発中にPCが突然停止

何が起きたのか

NanaSQLiteというPython製SQLiteラッパーライブラリを開発中、突然PCが停止しました。

正確には「シャットダウン」ではなく、画面が真っ暗になりプツンと電源が落ちた状態です。

環境スペック

項目 詳細
OS Windows 11
CPU Ryzen 9 5900X（2025年初頭に換装）
メモリ 48GB（8GB×2 + 16GB×2、2025年増設）
冷却 簡易水冷（2025年導入）
ケース 新調（2025年）
電源 玄人志向 550W Bronze（2019年製）
Git GUI SourceTree

停止時の挙動

プツン（画面真っ暗） → 2～5秒の沈黙 → 勝手に再起動

これはブルースクリーン（BSOD）ではなく、ハードウェアの保護回路が作動した可能性が高い挙動です。

OSが正常にシャットダウン処理を行う時間はありませんでした。

同じ症状の方へ

  • PCが「バチン」と落ちて数秒後に再起動する
  • 画面は真っ暗になり、シャットダウン処理が走らない
  • ログにKernel-Power 41（Critical）が記録される
  • 特に今年パーツを増強した後から不安定

👉 電源ユニットの容量不足・劣化を疑った方が良いかもしれません。

📊 電源容量が怪しいと思った理由（クリックで展開）

2025年の構成変更による消費電力増加

変更内容 時期 影響
CPU換装 2025年初頭 Core i5 10400 → Ryzen 9 5900X（消費電力大幅増）
メモリ増設 2025年 16GB → 48GB（4枚差し）
簡易水冷導入 2025年 ポンプ・ファン追加
ケース交換 2025年 ファン増設

懸念点

  • Ryzen 9 5900XはTDP 105Wですが、ブースト時は142W前後まで上昇
  • 4枚差しメモリはメモリコントローラへの負荷が高い
  • 簡易水冷のポンプ・ファンで常時10～20W追加
  • 電源ユニットは2019年製で約6年経過
    • 内部コンデンサの劣化により実効容量が低下している可能性
    • 550Wでは余裕率が低い（推奨は750W以上）
  • 瞬間的なスパイク電流（突入電流）に対応できない可能性

ただし、断定はできません。メモリの相性問題やマザーボードの不具合、他のハードウェア問題も考えられます。

破損状況の確認

症状チェックリスト

再起動後、以下のような症状が発生していました。

  • git reflog → fatal: your current branch appears to be broken
  • devブランチが消失（mainしか表示されない）
  • SourceTreeでフェッチ等の操作が不可能
  • git fsckでエラー連発
D:\NanaSQLite>git reflog
fatal: your current branch appears to be broken

D:\NanaSQLite>git branch
* main
# devが消えている！

破損診断：git fsck 

D:\NanaSQLite>git fsck --lost-found
Checking object directories: 100% (256/256), done.
Checking objects: 100% (174/174), done.

error: refs/heads/dev: invalid sha1 pointer 0000000000000000000000000000000000000000
error: refs/remotes/origin/dev: invalid sha1 pointer 0000000000000000000000000000000000000000
error: invalid HEAD

dangling commit 74c0964c51583b5b52943e7164cd9d751f1d60f8
dangling commit e3c8e7279077d02020758aa12846e4705ad8b1d6
dangling commit e08a442871d789994159880ee0617e158f976343

診断結果

状態 項目 説明
❌ refs/heads/dev ブランチの参照が0で埋まっている
❌ refs/remotes/origin/dev リモート参照も破損
❌ HEAD 壊れたブランチを指している
✅ dangling commit コミット本体は無傷で残存！
✅ 作業ツリー ファイルは無事
✅ ステージング .git/indexも生きている

重要な事実
Gitは「コミットオブジェクト本体（.git/objects）」と「参照（.git/refs）」を別管理しています。

突然の電源断で壊れるのは主に参照ファイルです。

👉 コミット済みのデータは.git/objectsに残っているため、参照を貼り直せば復旧可能！

復旧手順（完全版）

Step 1: HEAD を安全な状態に戻す

壊れたdevを指しているHEADを、安全なmainに向けます。

# 現在のHEADの状態を確認
type .git\HEAD
# 出力例: ref: refs/heads/dev （これが壊れている）

# HEADをmainに向ける
echo ref: refs/heads/main > .git\HEAD

# 正常に動作するか確認
git status

成功の目安: git statusがエラーなく実行できる

D:\NanaSQLite>git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   CHANGELOG.md
        modified:   src/nanasqlite/__init__.py
        new file:   tests/test_async_pool.py

Step 2: 失われたコミットを探す

git fsckで孤立した（dangling）コミットを探します。

git fsck --lost-found

出力例：

dangling commit 74c0964c51583b5b52943e7164cd9d751f1d60f8
dangling commit e3c8e7279077d02020758aa12846e4705ad8b1d6
dangling commit e08a442871d789994159880ee0617e158f976343

コミット内容の確認

# 統計情報付きで表示
git show --stat 74c0964c51583b5b52943e7164cd9d751f1d60f8

確認ポイント:

  • 最近の作業内容と一致するか
  • test_async_pool.pyやtest_edge_cases_v120.pyなどの新規ファイルが含まれているか
  • コミット日時が妥当か

複数のdangling commitがある場合

3つのコミットがある場合、最も新しいものがdevの先端です。
git show --oneline --decorate <hash>で各コミットを確認し、最新のものを特定しましょう。

Step 3: 壊れた参照を物理削除

新しいブランチを作成する前に、壊れた参照ファイルを削除します。

# 壊れたdevブランチの参照を削除
del .git\refs\heads\dev

# リモート参照も削除（存在すれば）
del .git\refs\remotes\origin\dev

# 確認（devが表示されないことを確認）
dir .git\refs\heads

エラーが出てもOK:

D:\NanaSQLite\.git\refs\remotes\origin\dev が見つかりませんでした。

→ すでに削除されているか、最初から存在しなかった場合です。問題ありません。

Step 4: devブランチを復活させる

Step 2で特定したコミットハッシュでdevを再作成します。

# devブランチを再作成
git branch dev 74c0964c51583b5b52943e7164cd9d751f1d60f8

# 確認
git branch

出力例：

  dev
* main

作業中の変更がある場合の切り替え方法

mainに退避していた際、devでの作業内容がmain上に残っています。そのままcheckoutすると衝突します。

# パターンA: stashを使う方法（推奨）
git stash push -m "recover dev work after power failure"
git checkout dev
git stash pop

# パターンB: 即座にコミットする方法
git add .
git commit -m "recover dev work after power failure"
git checkout dev

git stashとは？

作業ツリーの変更を一時保管庫に退避させるコマンドです。

git stash push -m "..."  # 変更を一時保管
git checkout dev         # devに移動
git stash pop            # 変更をdevに復元

なぜ必要？
main上にあるdevの作業内容を持ったままdevに切り替えると、Gitが「上書きされる！」と判断して拒否します。一度退避させることで安全に移動できます。

Step 5: remote（origin）を再設定

.git/configが破損し、リモートリポジトリの設定が消失している場合があります。

# 現在のremote設定を確認
git remote -v

何も表示されない場合は消失しています。

# originを再登録（GitHubの例）
git remote add origin https://github.com/disnana/NanaSQLite.git

# SSH の場合
git remote add origin git@github.com:disnana/NanaSQLite.git

# 確認
git remote -v

出力例：

origin  https://github.com/disnana/NanaSQLite.git (fetch)
origin  https://github.com/disnana/NanaSQLite.git (push)

Step 6: リモート参照を再構築

# リモートから最新情報を取得
git fetch origin --prune

# devをupstreamに紐付け
git push -u origin dev

git fetch origin --pruneとは？

  • --prune: リモートで削除されたブランチの参照をローカルからも削除
  • 壊れたorigin/devの残骸を掃除し、正しい参照を再取得します

Step 7: SourceTree を復旧させる

CLI側が正常でも、SourceTreeはキャッシュや壊れた参照を保持している場合があります。

# refs を再パック（GUI対策）
git pack-refs --all --prune

SourceTree の再起動手順

  1. SourceTreeを完全終了（タスクトレイも確認）
  2. PC再起動（推奨）
  3. SourceTreeを起動してリポジトリを開く

それでも動かない場合

SourceTreeからリポジトリを一度削除し、再登録します。

  1. SourceTree左ペインで「NanaSQLite」を右クリック → 削除
    • ⚠️ フォルダは削除されません（安全）
  2. ファイル → 既存のローカルリポジトリを追加
  3. フォルダを指定: D:\data-backup\code\コード保存\NanaSQLite

復旧確認チェックリスト

以下のコマンドがすべてエラーなく実行できれば完全復旧です。

# ✅ ブランチ一覧
git branch -av

# ✅ ログ確認
git log --oneline --decorate -5

# ✅ リモート確認
git remote -v

# ✅ fsckでエラーがないか
git fsck

# ✅ 参照の整合性
git show-ref

正常な出力例

D:\NanaSQLite>git branch -av
* dev                  74c0964 Add async pool tests
  main                 a1b2c3d Update README
  remotes/origin/dev   74c0964 Add async pool tests
  remotes/origin/main  a1b2c3d Update README

D:\NanaSQLite>git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (174/174), done.
# エラーなし！

SourceTree での確認

  • ✅ Fetch ボタンが有効
  • ✅ Pull / Push が可能
  • ✅ ブランチ一覧にdevとmainが表示
  • ✅ コミット履歴が正常に表示

Git内部構造の理解（なぜ復旧できるのか）

Git の3層構造

Gitは以下の3層で構成されています。

層 場所 役割 破損時の影響
オブジェクト層 .git/objects コミット・ツリー・ブロブの実体 ここが無事なら復旧可能
参照層 .git/refs ブランチ名とコミットハッシュの対応 壊れても再作成可能
設定層 .git/config リモートURL等の設定 いつでも再設定可能

突然の電源断で壊れるのは？

主に参照層と設定層です。

.git/
├── objects/        ← 💪 堅牢（ほぼ無傷）
│   ├── 74/
│   │   └── c0964c...
│   ├── e3/
│   │   └── c8e727...
├── refs/           ← ⚠️ 脆弱（壊れやすい）
│   └── heads/
│       ├── main    ← OK
│       └── dev     ← 破損（0埋め）
└── config          ← ⚠️ 脆弱（remoteが消失）

なぜオブジェクト層は無事なのか？

  • コミットはgit commit時に即座にディスクへ書き込まれる
  • ファイル名がハッシュ値なので上書きされない
  • 複数ファイルに分散保存されるため部分破損に強い

なぜ参照層は壊れるのか？

  • .git/refs/heads/devは単一のテキストファイル
  • 内容は1行のハッシュ値のみ（例: 74c0964c...）
  • 書き込み中に電源が落ちると0埋めや空ファイルになる

今後の予防策

1. Git設定で fsync を有効化

書き込みを即座にディスクに反映させる設定です。

# オブジェクトの書き込みを強制的に同期
git config --global core.fsyncObjectFiles true

# 参照の書き込みも同期（Git 2.36以降）
git config --global core.fsyncmethod fsync

効果: refs破損率が大幅に減少します。

パフォーマンスへの影響

この設定により、コミット速度が約10～30%低下します。
しかし、データ保護を優先する場合は有効化を推奨します。

2. 定期的なバックアップ

# .gitフォルダ全体をバックアップ（スクリプト化推奨）
cp -r .git .git_backup_$(date +%Y%m%d)

# Windowsの場合
xcopy .git .git_backup_%date:~0,4%%date:~5,2%%date:~8,2% /E /I /H

3. ハードウェアの見直し

電源ユニット（PSU）の確認

今回最も疑わしかった要因です。

チェック項目 推奨値
使用年数 5年以内（Bronze）、7年以内（Gold以上）
容量 最大消費電力の1.5～2倍以上
認証 80PLUS Gold以上（Platinum推奨）
メーカー Corsair, SeaSonic, Antec等の信頼性の高いブランド

こんな症状があれば電源ユニットを疑う

  • PCが突然停止（画面真っ暗）し、数秒後に再起動
  • OSのシャットダウン処理が走らない
  • Kernel-Power 41（Critical）がイベントログに記録
  • 特にパーツ増強後から不安定
  • 高負荷時（ゲーム・ビルド等）に落ちやすい

私のケース

  • 2019年製の550W Bronze
  • 2025年にCPU・メモリ・冷却を大幅強化
  • 消費電力が大幅増加したにも関わらず電源は据え置き

👉 今後、750W以上のGold認証電源への交換を検討中

その他のハードウェア対策

# UPS（無停電電源装置）の導入
- 瞬停や電圧変動から保護
- APC製など、1万円台から購入可能

# ノートPCでの開発
- 内蔵バッテリーがUPS代わり

# SSDの使用
- HDDより耐久性が高い
- 書き込み中の電源断に強い

4. クラウドバックアップ

こまめにgit pushすることで、最悪の場合でもリモートから復旧可能です。

# 定期的にpush（習慣化推奨）
git push origin dev

# push を強制するエイリアス設定
git config --global alias.done '!git add -A && git commit -m "Auto commit" && git push'

# 使い方
git done

よくある質問（FAQ）

Q1. `dangling commit`が大量にある場合は？

A1. 最も新しいコミットを探してください。

# タイムスタンプ付きで表示
git log --all --oneline --graph --decorate $(git fsck --no-reflogs | grep 'dangling commit' | awk '{print $3}')

または、1つずつgit showで内容を確認し、最近の作業と一致するものを選びます。

Q2. `git fsck`で`dangling commit`が出ない場合は？

A2. 以下を試してください。

# オブジェクト直読み
find .git/objects -type f | head -20

# packed objectsも確認
git verify-pack -v .git/objects/pack/*.idx

それでも見つからない場合、コミット前に電源が落ちた可能性があります。

Q3. SourceTreeが「認証エラー」を出す場合は？

A3. リモートURLの形式を確認してください。

# HTTPSの場合（認証が必要）
git remote set-url origin https://github.com/username/repo.git

# SSHの場合（鍵認証）
git remote set-url origin git@github.com:username/repo.git

SourceTreeの設定で認証情報を再入力する必要がある場合もあります。

Q4. `.git/index`も壊れている場合は？

A4. インデックスを再構築します。

# インデックスを削除（安全）
rm .git/index

# 再構築
git reset

まとめ

突然の電源断によるGitリポジトリ破損は、一見絶望的に見えますが、正しい手順を踏めば100%復旧可能です。

復旧の鍵

ポイント 説明
✅ コミット済みデータは安全 .git/objectsに残っている
✅ git fsckで発見可能 孤立コミットを見つけられる
✅ 参照は再作成可能 git branchで復活
✅ SourceTreeの問題 壊れた参照の残骸が原因

今後の対策

  1. git config --global core.fsyncObjectFiles true で書き込みを同期
  2. ハードウェアの定期的な見直し（特に電源ユニット）
  3. こまめなgit push でクラウドバックアップ
  4. UPS導入 で突然の電源断を防止

開発者へのメッセージ

今回の復旧作業を通じて、Gitの内部構造への理解が深まりました。

「コミットは消えない」というGitの設計思想に改めて感謝すると同時に、ハードウェアの重要性を再認識しました。

同じトラブルに遭遇した方の助けになれば幸いです。

参考資料

関連プロジェクト

  • NanaSQLite - この記事で復旧したプロジェクト

Author: @disnana
AI Assistance: Perplexity AI
Updated: 2025-12-23

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
5
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?