Gitの履歴をいつ、どのように書き直すべきか？

Question

Accepted Answer

Gitを使うと、**履歴を書き直す**ことができます。コミットを修正、リベース、スカッシュ、または削除してコミットをクリーンアップしたり問題を修正できます。これは強力ですが、慎重に行う必要があります。**共有**履歴を書き直すと深刻な問題が発生するため、その周辺のルールは重要です。 ## 履歴を書き直す方法 ```text git commit --amend → modify the most recent commit (message or content) git rebase -i → squash, reword, reorder, edit, drop commits (interactive) git rebase → replay commits onto another base (linear history) git reset → move the branch pointer (discard/uncommit) git filter-repo → rewrite MANY commits (remove a file/secret from all history) → All of these change commit HASHES (rewriting = creating new, different commits). ``` ## 黄金律 ```text ⚠️ NEVER rewrite history that has been PUSHED/SHARED (that others may have): → rewriting changes commit hashes → your history DIVERGES from collaborators' → they'll have the old commits; pulls create duplicates/conflicts; chaos ensues → forces everyone to painfully reconcile → a serious disruption ✓ Rewrite ONLY local, unpushed commits (cleanup before sharing). ✗ On shared branches → use REVERT (a new undoing commit) instead, which is safe. ``` ## 書き直しの正当な用途（ローカル） ```text ✓ Clean up messy WIP commits before opening a PR (squash, reword) → clean history ✓ Fix a mistake in the last commit (amend) before pushing ✓ Keep a feature branch linear/up-to-date with main (rebase) before sharing ✓ Remove a SECRET accidentally committed (filter-repo) — though if it was PUSHED, the secret must be ROTATED (it's already exposed; rewriting alone isn't enough) ``` ## 共有履歴を書き直す場合（稀） ```text → COORDINATE with the whole team (everyone stops, re-syncs) → Force-push carefully: git push --force-with-lease (safer than --force — checks first) → Everyone must reset/re-clone to the rewritten history → Do this only when truly necessary (e.g. purging a leaked secret) and with agreement. ``` ## なぜ重要なのか Gitの履歴をいつ、どのように書き直すべきかを理解することは、シニアレベルの重要な知識です。履歴の書き直しは**強力だが危険**であり、特に共有履歴に関するルールを理解することで、深刻な問題を防ぎながら正当なクリーンアップを可能にします。 **書き直しの方法**（最後のコミットに対するamend、スカッシュ/リワーディング/リオーダーのためのインタラクティブリベース、線形履歴のためのリベース、reset、大規模な変更のためのfilter-repo）と、これらすべてが**コミットハッシュを変更する**こと（新しいコミットを作成する）を理解することが基礎となります。最も重要なのは、**黄金律——共有/プッシュされた履歴を決して書き直さない**——を理解することです。書き直しはハッシュを変更し、あなたの履歴が協力者の履歴（まだ古いコミットを持っている）と相違することになり、重複、競合、そして苦労する調整につながるからです。共有履歴の書き直しは深刻な混乱であり、このルールはそれを防ぎます。共有ブランチではこのルールの代わりに**revert**（安全な新しい取り消しコミット）が正しいアプローチです。 **正当なローカル用途**（PRの前にWIPコミットをクリーンアップする、プッシュ前に間違いを修正する、共有前に線形を保つためにリベースする——すべてローカルでプッシュされていないコミット上）を理解することで、書き直しが適切で価値のある時期を明確にします。重要なセキュリティのニュアンス：**秘密がコミットされてプッシュされた**場合、履歴を書き直してそれを削除することは不十分です——秘密は既に公開されており、**ローテーション**（重要な現実のセキュリティポイント）が必要です。 **共有履歴の稀に必要な書き直しを処理する方法**（チーム調整、`--force`ではなく`--force-with-lease`、全員の再同期）を知ることは、成熟した判断を反映しています。履歴の書き直しは強力ですが、共有履歴での不正使用は深刻な問題を引き起こすため、また黄金律、正当な用途、安全なプラクティスを理解することがそれを責任持って使用する上で本質的であるため、Gitの履歴をいつ、どのように書き直すべきかを理解することはシニアレベルの重要な知識です。これは安全ルール（特に共有履歴を決して書き直さないこと）の理解が実際の協力のディザスターを防ぎ、チームでGitを使用するシニアロール向けに期待される判断を反映しているトピックです。