Gitのマージは、別のブランチの履歴を現在のブランチへ取り込む操作です。最初に確認したいのは、取り込む相手よりも今どちらのブランチにいるかです。
ここではローカルで統合を確認する手順を説明します。コマンドは未実行の説明例です。本番への反映や共有先へのpushは、レビュー・検証後にチームの経路で行います。
統合元と統合先を言葉にする
たとえばtopic/reportの変更をmainへ取り込むなら、統合先はmainです。先に作業状態と現在のブランチを確認します。
git status
git branch --show-current作業中の変更がある場合は、保存方法を決めてからマージします。Git公式merge仕様は、未コミット変更があると中断時に元の状態を完全に再構成できない場合があると説明しています。
差分を見てから統合する
統合先を確認し、取り込む変更をレビューしたうえでマージします。次は、作業ツリーが整理され、対象ブランチが手元にある場合の例です。
git switch main
git log --oneline main..topic/report
git merge topic/report履歴の関係によって、参照を先へ進めるfast-forwardになる場合と、双方の履歴を結ぶマージコミットが作られる場合があります。チームが許可する統合方式と合わせてください。Git公式merge仕様
競合したら期待する結果を先に決める
競合が起きたときは、どちらの変更も理解せず片側を選ぶのではなく、統合後に必要な振る舞いを確認します。
仮に一方が入力欄の名前を変え、他方がその入力の検証を追加した場合、片側だけ残すと相手の目的を失う可能性があります。競合箇所だけでなく、呼出し側やテストも含めて確認するという判断が必要です。
git statusで競合対象を確認する。- 両方の変更目的を読み、統合後の内容へ編集する。
- 対象ファイルを指定して
git addする。 - 必要なテストと差分確認を行い、
git merge --continueへ進む。
この順番は説明例です。自動生成ファイルなどは、元になる入力から再生成すべきかも確認します。
中断するなら変更を増やす前に判断する
方針が決まらない場合は、競合中に無関係な編集を重ねず、git merge --abortで中断する選択があります。ただし、開始前から未コミット変更があると元通りに戻せない場合があるため、開始前の保存が重要です。中断オプション
マージ成功と動作確認を分ける
Gitが機械的に統合できても、業務上正しい組合せとは限りません。差分、対象テスト、必要な画面やAPIの挙動を確認してから共有します。
CI/CDの基本は、統合後の継続的な検証とつなげて考える際の参考になります。統合元・統合先・確認結果を残すところまでを一つの作業にしましょう。