解説
この修正はmainへ入った？git branch --containsでコミットから確認しよう
修正用ブランチの名前は覚えているけれど、そのコミットがmainへ入ったか分からない。コミットを手掛かりに、含んでいるブランチを確認する方法を試してみよう。
修正用ブランチの名前は覚えているけれど、そのコミットがmainへ入ったか分からない。コミットを手掛かりに、含んでいるブランチを確認する方法を試してみよう。
この記事は、空の練習リポジトリで二つのブランチを作る。リモートへpushせず、本番の履歴や共同作業中のブランチは変更しないよ。
--containsが調べること
git branch --containsにコミットを指定すると、そのコミットを祖先として含むブランチを絞って表示できる。通常の指定ではローカルのブランチを見る。
git branch --contains <確認するコミット>
単にブランチ名が存在するか、同じ文章が今のファイルにあるかを調べる操作とは違う。何を確認したい修正なのか、まず対象のコミットを特定しよう。
修正だけを別の枝へ作る
mkdir contains-practice
cd contains-practice
git init -q -b main
git config user.name Practice
git config user.email practice@example.com
printf 'base\n' > note.txt
git add note.txt
git commit -qm base
git switch -c fix
printf 'fixed\n' >> note.txt
git add note.txt
git commit -qm fix
practice_fix=$(git rev-parse HEAD)
git switch main
git branch --contains "$practice_fix"
この時点では、修正コミットを持つfixだけが表示される。練習用の利用者設定は、このリポジトリだけのもの。既存の作業フォルダーと同じ名前なら、別の新しい名前で始めよう。
mainへ進めたあとに比べる
この練習はmainに別の変更を作っていないので、次のfast-forwardを試せる。
git merge --ff-only fix
git branch --contains "$practice_fix"
今度はmainとfixの両方が対象になる。先頭の*は、現在いるブランチを示す。編集部では、二つの状態の一覧と、コミットの位置を実際に作って確認した。
普段のリポジトリで、確認したいからといってそのままmergeする必要はないよ。ここでのmergeは、比較する状態を自分で作るための練習だと分けよう。
同じ内容でも、同じコミットとは限らない
cherry-pickやsquash、rebaseなどで修正を取り込むと、元のコミットと別のIDになる場合がある。--containsに出ないことだけで、同じ修正内容が絶対に入っていないとは判断しない。
元のコミットが含まれていても、そのあとで変更が戻されたり、別の修正へ置き換わったりする場合もある。含む履歴の確認と、現在の動作の確認は別だよ。
リモートの状態も、手元の情報の鮮度を見る
-rはリモート追跡ブランチ、-aはローカルとリモート追跡の両方を表示する指定。リモート追跡ブランチは、今この瞬間のサーバーへ毎回問い合わせた結果ではない。
必要なら許可された方法でfetchして、いつの情報を見ているかを確かめる。本番へのデプロイまで確認したい場合は、実際に動くリリースのコミットとも照合しよう。
みんなのコメント 0
感想や、試してみたことを聞かせてね。コメント・返信は承認後に公開されます。
最初のコメントをどうぞ。