Zenn
🙄

悲しみのコード消滅...Git復活劇とデータ喪失を防ぐ9つの習慣

に公開
Git
開発プロセス
tech

悲しみのコード消滅...Git復活劇とデータ喪失を防ぐ9つの習慣

この記事で分かること

「なぜ...消えた...? 昨日まで確かにあったはずなのに...」

あなたもきっと一度は経験したことがあるでしょう。必死に書いたコードが突然消えてしまう絶望感。私は先月、2週間かけて実装した機能が「git reset --hard」の誤操作で跡形もなく消失しました。その日は眠れませんでした。

しかし、この悲劇から多くを学び、今では「コード消滅」の恐怖から解放されています。この記事では、辛い経験から学んだGitでのデータ喪失を防ぐための9つの習慣と、もし消えてしまった場合の復活テクニックを共有します。

1. まず確認！消えたと思ったコードが本当になくなったのか見極める方法

「コードが消えた！」と思っても、実はGitのどこかに残っていることがよくあります。以下の手順で確認しましょう。

①最近のコミット履歴を確認

# 最近のコミット履歴（削除したものも含む）を表示
git reflog

実行結果：

e2f8c34 HEAD@{0}: reset: moving to HEAD~1
a7d9c56 HEAD@{1}: commit: 機能Aの実装完了
b3e8d1c HEAD@{2}: commit: 機能Aの実装（途中）

②特定のコミットの内容を確認

# コミットの詳細を確認
git show a7d9c56

このように、git reflogコマンドを使えば、「git reset --hard」で戻してしまった場合でも履歴が残っています。これが私がコードを復活させることができた第一歩でした。

2. 悲劇を未然に防ぐ！コミットの頻度とタイミング

ポイント：小さな単位で頻繁にコミットする

多くの初心者が陥る失敗は「完成してからコミットしよう」という考え方です。これが最大のリスクとなります。

# 良い例：小さな単位でコミット
git add login-form.js
git commit -m "ログインフォームのバリデーション機能を追加"

# 数時間後...
git add login-form.js
git commit -m "ログインフォームのエラーメッセージ表示を改善"

私の経験では、以下のタイミングでコミットするのが効果的です：

  1. 機能単位で動作確認ができたとき
  2. バグを修正したとき
  3. 1時間以上作業を続けたとき（途中でも）
  4. 休憩や退勤前

「まだ完成していない」と思っても、これらのタイミングでコミットする習慣をつけることで、大きなデータ喪失リスクを減らせます。

3. ステージングの正しい理解と活用法

Gitを使う上で意外と理解されていないのが「ステージング」の概念です。

ステージングエリアを有効活用する

# 変更を確認してから追加する
git status
git diff file.js

# 変更を部分的に追加する（対話モード）
git add -p file.js

実行結果：

diff --git a/file.js b/file.js
index 1234567..abcdefg 100644
--- a/file.js
+++ b/file.js
@@ -10,6 +10,10 @@ function login() {
  // ログイン処理
+
+ // 新機能の追加
+ function newFeature() {
+   // まだ開発中...
+ }
Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]?

このように、git add -pを使うと変更を部分的にステージングできます。開発中の機能と完成した機能を分けてコミットすることで、後から問題が発生した場合にも対処しやすくなります。

4. コミットメッセージの黄金ルール

コミットメッセージはただの記録ではなく「救命ボート」です。私が2週間分のコードを復活できたのは、具体的なコミットメッセージがあったからでした。

効果的なコミットメッセージの書き方

# 悪い例
git commit -m "修正"

# 良い例
git commit -m "ユーザー登録時のバリデーションエラーを修正"

理想的なコミットメッセージの構造：

[タイプ] タイトル（50文字まで）

- 詳細な説明（必要な場合）
- 変更の理由
- 関連するIssue番号

例：

git commit -m "[FIX] ユーザー登録時のメールアドレス重複チェックを修正

- データベースの大文字小文字区別の問題を解決
- パフォーマンス改善のためインデックスを追加
- Closes #123"

この習慣を身につけるだけで、問題発生時の原因特定とコード復元が格段に容易になります。

5. ブランチ戦略で安全性を確保する

私がコードを失った大きな原因は、全ての作業をmainブランチで行っていたことでした。

安全なブランチ戦略

# 新機能開発用のブランチを作成
git checkout -b feature/user-registration

# 作業完了後、メインブランチへマージ
git checkout main
git merge feature/user-registration

以下のブランチ命名規則を採用することで、何のための変更かがすぐに分かります：

  • feature/xxx - 新機能開発
  • fix/xxx - バグ修正
  • refactor/xxx - リファクタリング
  • docs/xxx - ドキュメント更新

これにより、mainブランチは常に安定した状態を保ち、問題が発生しても影響範囲を限定できます。

6. 危険なコマンドを使う前に - 安全策を講じる

私が犯した致命的なミスは、git reset --hardの意味を完全に理解せずに使ったことでした。

危険なコマンドと安全策

# 危険: ワーキングディレクトリの変更もすべて消える
git reset --hard HEAD~1

# 安全: コミットは戻すが、変更はステージングエリアに残す
git reset --soft HEAD~1

特に注意すべき危険なコマンド：

  1. git reset --hard - 変更を完全に削除
  2. git clean -fd - 未追跡ファイルを削除
  3. git push -f - リモートリポジトリを強制的に上書き

これらのコマンドを使う前には、必ず以下の安全策を：

# 現在の状態を別ブランチとして保存
git branch backup-before-reset

# または変更をスタッシュに保存
git stash save "reset前のバックアップ"

この単純な習慣が、将来のあなたを救うことになるでしょう。

7. リモートリポジトリを「保険」として活用する

ローカルでの作業が消えても、リモートリポジトリにプッシュしていれば「保険」になります。

リモートリポジトリ活用のポイント

# 1日の作業開始時にリモートの変更を取り込む
git pull origin main

# こまめにプッシュする（特に終業前）
git push origin feature/user-registration

私は以下のタイミングでプッシュする習慣をつけています：

  1. 重要な機能実装後
  2. ミーティング前
  3. 長い休憩前
  4. 退勤前（必須）

特に複数人での開発では、プッシュしておくことでコンフリクトの早期発見にも繋がります。

8. Git設定のカスタマイズで安全性を高める

Gitの設定をカスタマイズすることで、誤操作のリスクを軽減できます。

安全性を高めるGit設定

# プッシュ時の設定（現在のブランチと同名のリモートブランチのみプッシュ可能）
git config --global push.default current

# 削除した参照をreflogに30日間保持
git config --global gc.reflogExpire 30.days

# 危険なコマンドに確認プロンプトを表示
git config --global alias.delete-branch '!f() { git branch -D "$@" || echo "削除をキャンセルしました"; }; f'

.gitconfigファイルの例：

[user]
    name = Your Name
    email = your.email@example.com
[core]
    editor = code --wait
[alias]
    st = status
    co = checkout
    cm = commit -m
    undo = reset HEAD~1 --soft
    # 安全なリセット（変更を保持）
    safe-reset = "!f() { git branch backup-$(date +%Y%m%d%H%M%S); git reset --soft $1; }; f"

これらの設定で、日常的なGit操作がより安全で効率的になります。

9. 最終手段：GitでもGitHubでも見つからないコードの復旧方法

最悪の事態を想定して、最終手段の復旧方法も知っておきましょう。

エディタやIDEの自動バックアップを確認

多くのエディタやIDEは自動バックアップ機能を持っています。

VSCodeの場合：

  1. .vscode/backups フォルダを確認
  2. ローカルヒストリー拡張機能を導入

IntelliJ IDEAの場合：

  1. File > Local History > Show History で過去のバージョンを確認

Gitの内部データベースから復旧

どうしても見つからない場合は、Gitの内部データベースから復元できることもあります：

# Gitオブジェクトを探す
find .git/objects -type f | while read hash; do
  git cat-file -p $(echo $hash | sed 's/.*\///' | sed 's/\(..\).*/\1/')
done | grep -A 20 "探したい内容の特徴的な文字列"

この方法は複雑ですが、本当に重要なコードが消えてしまった場合の最終手段として覚えておいて損はありません。

実際の復活劇：私はこうしてコードを取り戻した

私が2週間分の作業を取り戻した実際の手順を紹介します：

  1. まず落ち着いて git reflog を実行
  2. 消えたコミットのハッシュを特定（a7d9c56）
  3. git checkout a7d9c56 で一時的にそのコミットの状態に移動
  4. 新しいブランチを作成 git checkout -b recovery-branch
  5. 必要なコードをファイルごとに確認し、現在のブランチに取り込み

このプロセスには2時間ほどかかりましたが、2週間分の作業を失うよりはずっと良い結果でした。

悲劇を教訓に：私が今実践している日常のGit習慣

この経験から、私は以下の習慣を徹底するようになりました：

  1. 作業開始時に必ず新しいブランチを作成
  2. 30分〜1時間ごとに小さなコミット
  3. コミットメッセージは必ず「何をどう変更したか」を明記
  4. 退勤前に必ずリモートリポジトリにプッシュ
  5. リスクの高いコマンドを使う前にバックアップブランチを作成

この5つの習慣だけで、データ喪失のリスクを95%以上減らすことができます。

TL;DR - 今すぐ実践できる9つの習慣まとめ

  1. 小さな単位で頻繁にコミット：機能単位・1時間単位でコミット
  2. ステージングを理解：git add -pで部分的に変更を追加
  3. 詳細なコミットメッセージ：何を、なぜ変更したかを記録
  4. ブランチを活用：作業ごとに専用ブランチを作成
  5. 危険コマンドの前に安全策：git branch backup-xxxでバックアップ
  6. リモートリポジトリを活用：こまめにプッシュして保険に
  7. Git設定をカスタマイズ：エイリアスと安全設定で事故防止
  8. エディタのバックアップ：VSCodeなどのバックアップ機能を確認
  9. 復旧方法を知る：git reflogと内部データベースの活用法

「コード消滅の悲劇」は誰にでも起こりえます。しかし、適切な習慣と知識があれば、そのリスクを大幅に減らし、万が一の時にも対処できるようになります。

あなたも今日から、これらの習慣を取り入れてみませんか？コメント欄で皆さんのGit活用法やトラブル体験も共有いただければ嬉しいです。

Discussion