Compaction・Rebase・Cherry-pick:コンテキストとGitの整理用語

約12分developer-tools
#ウォーム・コールドメモリ#コンパクション#リベース#チェリーピック#スクワッシュ#AIコーディングツール#用語集
※ 編集原則:以下の業務状況や人物は、用語の理解を助けるための仮想シナリオです。実際の著者の経験や特定企業の出来事を再現したものではありません。
2週間かけて機能を開発し、コミットが30個以上積み上がった仮想プロジェクトで、PR前に整理を始める状況です。
エージェントに、過去の会話の中で序盤に決めた命名規則を再度尋ねたところ、正確に記憶はしているものの、回答が出るまでに妙に間があるように感じられました。

古い会話ほど回答が遅くなる理由、ウォーム・コールドメモリ

公式ドキュメントを調べてみると、理由が書かれていました。たった今交わした会話はすぐに取り出せる場所に置いておきますが、ずいぶん前に交わした会話はアクセスが少し遅い場所に移動させておき、必要な時に再度読み込む方式でした。
よく使うものは机の上に置き、たまに使うものは倉庫に入れておいて必要な時に取り出します。倉庫から取り出すそのわずかな時間が、先ほど感じた「間」でした。
最近の会話と古い会話が異なる速度で保存され、読み込まれる仕組み
最近의 会話と古い会話が異なる速度で保存され、読み込まれる仕組み
命名規則を再確認して整理を始めようとしたところ、同僚が先週残したコメントの中に、見慣れない単語が一つ目に留まりました。

会話が長くなると自動的に整理される理由、コンパクション

同僚がPRのコメントに「セッションのコンパクションのせいで、それをもう一度伝えないといけないかもしれない」と残しているのを見て、どういう意味か調べてみました。
text
1Compacting conversation... (summarizing older turns)
会話が積み重なって制限に近づくと、古い部分を丸ごと要約して圧縮し、最近の内容を中心にスペースを再確保するプロセスでした。旅行カバンに服を押し込むように、すべてを持っていくことはできないため、ボリュームを減らして最大限持っていくようなものです。
古い会話を丸ごと圧縮して要約に変換するプロセス
古い会話を丸ごと圧縮して要約に変換するプロセス
ブランチの整理に戻ると、メインブランチがいつの間にかかなり先に行っていることに気づきました。コマンドを実行すると、ツールが自ら状況を説明してくれました。

ブランチを最新状態の上に再構築したいとき、リベース

bash
1$ git rebase main
2Rebasing (3/12): replaying your commits on top of main
画面に表示された説明をそのまま読んでみると、理解できました。担当者のコミットをそのまま残したままメインブランチをマージする代わりに、担当者のコミットを一つひとつメインブランチの最新の地点の上に積み上げ直す方式でした。
すでに積み上げたブロックの塔を土台から作り直す代わりに、高くなった土台の上に同じブロックを順番に乗せ直すようなものです。履歴が格段にすっきりしました。
自分のコミットを残したまま、メインブランチの最新地点の上に積み上げ直す仕組み
自分のコミットを残したまま、メインブランチ의 最新地点の上に積み上げ直す仕組み
リベースを終えると、別のブランチで作成したバグ修正のコミットが1つ、こちらにも必要であることに気づきました。以前、似たような状況で残しておいたメモを探してみました。

コミットを1つだけ選んで移動させたいとき、チェリーピック

bash
1$ git cherry-pick a1b2c3d
メモに書いてあった通りにコミットハッシュを1つ指定したところ、そのブランチの他の変更は一切ついてこず、まさにそのコミットだけが現在のブランチにそのままコピーされました。
木になった果実を1つだけ選んで摘み取るように、特定のコミットだけを指定して別のブランチに持って来る方法でした。全体をマージする必要なく、必要な修正だけを正確に取得することができました。
他のブランチの他の変更は残し、特定のコミットだけを選んで移動させる仕組み
他のブランチの他の変更は残し、特定のコミットだけを選んで移動させる仕組み
木の枝から果実を1つだけ選んで摘み取る様子を手描きしながら、コミットログを確認している場面
コミットを移動させた後、30個以上もある細かなコミットを一つひとつレビュアーに見せるのは気が引けると感じました。同じような悩みを何度も繰り返した末に、いつもこの問題の整理に時間を費やしていることに気づきました。

細かな30個のコミットを1つにまとめたいとき、スクワッシュ

bash
1$ git rebase -i HEAD~30
2pick → squash (29개 커밋에 적용)
「タイポ修正」「再度タイポ修正」「本当に最後のタイポ修正」のように細かく積み重なったコミットを、意味のある1つの単位にまとめて圧縮する作業でした。30枚の紙に分散して書かれたメモを、きれいな1枚の報告書に整理するようなものです。レビュアーは30個の試行錯誤を見る代わりに、完成した1つの変更だけを確認すれば済みます。
細かく積み重なった複数のコミットを、意味のある1つの単位にまとめて圧縮する仕組み
細かく積み重なった複数のコミットを、意味のある1つの単位にまとめて圧縮する仕組み
カフェの窓際、整理されたコミット履歴とともに、PRボタンを押す直前のノートPCの画面
整理を終えて出したPRは、30個のコミットではなく5つのコミットになりました。レビュアーが見る画面を基準にコミットを再構成するのに半日かかりましたが、その半日はレビュー時間の短縮という形で見事に報われました。

よくある質問

コンパクションされると、以前の詳細は完全に消えてしまうのですか?

完全に消えるわけではなく、要約された形で残ります。ただし、要約の過程で細かな条件が省略されることがあるため、重要なルールは会話ではなくファイルに残しておくのが安全です。

リベースとマージは何が違うのですか?

マージは2つの履歴を統合した地点を新しく作成して記録をそのまま残し、リベースは履歴自体を再配置して、まるで最初からそのように作業したかのようにきれいに整理します。チームの規約(コンベンション)によって好みが分かれます。

スクワッシュすると、以前のコミット履歴は完全に消えてしまうのですか?

統合されたブランチ基準では1つに見えますが、元のブランチやローカルの履歴にはしばらく残っていることがあります。ただし、すでにリモートにプッシュされたコミットをスクワッシュする場合は、事前にチームメンバーと相談するのが安全です。

AIコーディングツール用語集シリーズの第10話です。次回予告 ・ 第11話 長期休暇を控えて引き継ぎ文書を書いていた最後の一日 ハンドオフ・スクラッチパッド・トークンバーニング・デタッチドヘッド・アップストリーム・.gitignore

参考・根拠

関連記事