git cherry-pickを使う

背景

先日、運用更新が行われているサイトのスポット作業中、ブランチで一括置換したファイルが更新案件と大量に被ってしまった。
ステージングサーバーは一つなので、全ての作業を取り込んだ状態でクライアントに確認してもらいたい。
ちょうど良い機会だったのでcherry-pickを挙動調査がてら使ってみた。

cherry-pickの機能

特定のコミットだけを他のブランチから反映することができるコマンド。

cherry-pickのコマンド

$ git checkout xxxx //取り込みたいコミットがあるブランチ
$ git log

//各コミットのIDが出てくる

$ git checkout yyyy //取り込み元のブランチに戻る
$ git cherry-pick [commit ID]

挙動の確認

むしろ常にこの状態が続くのであれば、マージ用のブランチを立てて管理しても良い。
実際クライアント確認時はマージ用のブランチに全てマージしてアップロードした。
しかし各ブランチの公開タイミングが読めない + 先立って該当の置換作業が公開されても支障ない内容。
ということから他のブランチへ自分の作業だけチェリーピックしておくことにした。
バキバキに更新した他の作業内容が含まれては困るし、心配性なので挙動のテストを行った。

・ファイルA、ファイルB ２つのファイルを用意する。
・1ファイルずつ手を加えたとき、後半のコミットを取り込んだ場合に「ファイルA」の状態が変化しなければOK
※下のブランチに、ピンクで囲んだコミットの内容をcherry-pickする。

これは感覚の問題だが「特定のコミットだけを反映する」と自分で書いておきながら「そのコミット時点での状態」が取り込まれないか確認しておかないと気持ち悪くて...。
結果はもちろん問題なし。上記イラストの通り、該当コミットの作業内容だけ反映された。
コミットとは「差分」のことであり、各コミットIDに記録されているのはコミット時点での「状態」ではなく、各コミットの「差分」でしかない。
というのを改めて理解できた。
cherry-pick自体は便利な機能だがこれが乱発するのはそもそも案件のハンドリングの問題でもあるので、いざというときだけにしておきたい。