$ man context-wiki/git-for-gtm

Git を荷造りと発送だと考えてほしい。git add は箱に物を入れること。どのファイルをこの発送に含めるかを選ぶ。git commit は箱を封して、中身を書いたラベルを貼ること。git push は封した箱を倉庫(GitHub)に送ること。プッシュするまで、誰もあなたの作業を見ることはできないし、コードのバックアップもない。ローカルマシンに封された箱が置いてあるだけだ。 壊れたホームページをリバートする必要に迫られるまで、僕は Git を理解していなかった。何かを変更してページをリフレッシュしたら、レイアウトが丸ごと消えた。そこでコミットを取り消して、動いていた状態に戻せることに気づいた。あの瞬間すべてが腑に落ちた。Git は変更を追跡しているだけじゃない。タイムトラベルさせてくれるのだ。

パターン

ステージングを使えば、各コミットに何を入れるかをコントロールできる。ペルソナドキュメントを更新して、それがキャンペーンの切り口やペインポイントの変更を引き起こしたら、それらを全部同じ箱に入れたい。そうすれば、仮説が間違っていた場合にまとめてロールバックできる。 ダメな方法：すべてを一度にコミットして「更新」のようなメッセージをつけること。何が変わったのか、なぜ変わったのか分離できない。 いい方法：関連する変更をまとめてステージングし、説明的なメッセージをつけること。「Acme のペルソナ階層を更新し、Tier 2 のキャンペーン切り口を調整」と書けば、何が起きて、なぜ起きたかが正確に分かる。何かが壊れたとき、どの箱を開ければいいか分かる。

コード

git add .(変更されたすべてのファイルを次のコミットのためにステージング) git commit -m "メッセージ"(箱を封してラベルを貼る) git push origin main(GitHub に送る) これだけだ。3 つのコマンドで日常の Git 使用の 90% をカバーできる。/deploy スキルはこの 3 つを自動的に実行し、さらにビルド検証とデプロイ確認も行う。Git コマンドを暗記する必要はない。コンセプトを理解して、実行はスキルに任せればいい。

プロのコツ

すべてのコミットはセーブポイントだ。何かを壊したら、戻れる。git log で履歴を確認できる。git revert は履歴を消さずに特定のコミットを取り消す。git checkout でファイルの古いバージョンを見られる。だからコミットメッセージが重要なのだ。git log をスクロールしてどこで壊れたか探しているとき、「修正」では何も分からない。「ヒーローセクションのアニメーションを追加」なら、どのコミットが変更を導入したか正確に分かる。いいメッセージは Git のためではない。夜 11 時にバグを探している未来の自分のためだ。