Git チートシート

Git チートシートの本当の役割

Git には百を超えるコマンドがありますが、実務で毎日使うのは二十から三十程度で、残りは年に数回触れるかどうかです。チートシートは Git のモデルを理解する代わりにはなりません。その価値は、すでに理解しているコマンドを「ブラウザのタブと検索結果三件の先」ではなく「キー入力一回の距離」に置いておくことにあります。

このページの一覧は、実際の作業手順に沿って分類してあります。リポジトリの初期化、一日に何十回も回すコミットのループ、ブランチ操作、リモートとのやり取り、履歴の確認、そしてトラブルからの復旧です。フィルタ欄に入力すると、コマンド本文と説明の両方が検索対象になるため、「stash」「force」「取り消し」などを入力すれば該当行が即座に絞り込まれます。各行にはコピーボタンを用意しました。--force-with-lease を含むコマンドを手打ちすることこそ、タイプミスの温床だからです。

コマンドを支える考え方

三つの場所を頭に置けば、ほとんどの Git コマンドは筋が通ります。作業ツリーはエディタで見えているディスク上のファイル、インデックス（ステージングエリア）は次のコミットのために組み立てているスナップショット、リポジトリはすでに記録された不変のコミット列です。git add は作業ツリーからインデックスへ内容を移し、git commit はインデックスを新しいコミットに変え、git restore は逆向きに内容を戻します。

二つ目の概念がブランチで、見た目より単純です。ブランチは単に「あるコミットを指す移動可能なポインタ」であり、HEAD は現在いるブランチを指すポインタです。ブランチ作成のコストはほぼゼロで、40 文字のハッシュを含む小さなファイルを書くだけです。だからこそ git switch -c は、五分で終わる実験のために使っても惜しくありません。

マージとリベースはどちらも二つのブランチの成果を統合しますが、記録の仕方が異なります。マージは双方の履歴を残し、両者をつなぐコミットを追加します。正直な記録ですが、グラフは編み目状になります。リベースは自分のコミットを書き換え、相手ブランチの上に最初から書いたかのように見せます。履歴は一直線になりますが、コミットハッシュが変わります。他人がすでに取得したコミットをリベースしてはいけない理由は、まさにここにあります。

トラブルからの復旧

Git について最も役に立つ知識は、「一度コミットした成果はめったに失われない」という事実です。ある時点でコミットされてさえいれば、git reflog がハッシュを示し、git switch -c rescue <hash> で復元できます。この安全網は、失敗したリベース、コミット後の誤った reset --hard、勢い余って削除したブランチまでカバーします。

本当に危険なのは、未コミットの内容に触れる操作です。git reset --hard、変更済みファイルへの git checkout --、そして git clean -fd。これらの変更は一度も記録されていないため、reflog が指し示す先が存在しません。身につけるべき習慣は、使い捨てブランチで早めかつ頻繁にコミットすること、あるいは実験の前に git stash push しておくことです。後でまとめて潰すコミットのコストはゼロですが、未コミットのまま失った半日は戻ってきません。

共有ブランチでは、履歴の書き換えよりも git revert を優先してください。古いコミットを打ち消す新しいコミットを記録するため、他の人のクローンはそのまま有効です。--force-with-lease は自分の作業ブランチに限って使いましょう。素の --force より明確に安全で、前回の fetch 以降にリモートが動いていれば実行を拒否します。それはまさに、素の強制 push が同僚のコミットを黙って消し去る状況そのものです。