はじめに
バックマージ。この言葉が適切かわからないのですが。
developブランチから、Aブランチを作成し開発中に、developブランチからAブランチへマージするようなことを、本記事ではバックマージとします。
Aブランチでの開発が終わったので、developブランチへGitHub上でPRを作成して、マージしようと思った際に、ふと、バックマージって必要だっけ？と思ったのです。
で、バックマージが必要なケースを改めて考えてみました。
必要と思うパターン
その１
他のブランチで作られたメソッドを、自ブランチでも利用したい場合。
例）
develop から Aブランチ、Bブランチ を作成
その後、BブランチでZメソッドが作られ、Bブランチがdevelopへマージされた。
で、AブランチでZメソッドを使いたい場合、developをAブランチにバックマージする。
※ BブランチでZメソッドを作ったコミットをAブランチに取り込む「Cherry-pick」もある。
その２
developへマージした時に、エラーが起きないかの事前確認。
通常、developに対して、PRを作った時点でコンフリクトの検出が可能。
なので、特にバックマージは必要ない気がする。
が、以下のようなケースの場合に、マージ後にエラーが起きうる可能性がある。
Aブランチを作った時点のdevelopブランチは、は以下の状態
「Aファイル」で「Aメソッドが定義」
「Bファイル」で「AファイルのAメソッドを利用」
Aブランチで、「Cファイル」を新たに作成し「AファイルのAメソッドを利用」以下の状態
「Aファイル」で「Aメソッドが定義」
「Bファイル」で「AファイルのAメソッドを利用」
「Cファイル」で「AファイルのAメソッドを利用」★ 新しいファイル
並行してdevelopブランチで、「Aファイル」の「AメソッドをZメソッドに変更」
「Aファイル」で「Zメソッドが定義」
「Bファイル」で「AファイルのZメソッドを利用」
結果
この状態で、AブランチからdevelopブランチにPRを作っても、コンフリクトは起きず。
マージして、Cファイルの処理を呼ぶと、エラーになる。（Javaとかはコンパイルエラーになるかと。）
補足
とはいえ、コンパイルエラーで検知できるものは、GitHubActionsで防ぐことも可能。
こんな感じのCIを作ると、仮マージした状態でコンパイルできるか？を確認してくれる。
※ 当初は、Aブランチの状態でコンパイルするのでは？と思ったら、マージ後の状態でコンパイルしてくれているっぽい。これは知らなかったのでGeminiに教えて貰い、試してエラーになり感動。
name: Java Direct Compile Check
on:
pull_request:
branches: [ "develop" ]
jobs:
check-style:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up JDK
uses: actions/setup-java@v4
with:
java-version: '25'
distribution: 'temurin'
- name: Compile with javac
run: |
# 全てのJavaファイルを一括でコンパイルしてみる
# もしAファイルのメソッド名が変わっていて、Cファイルが古い名前を呼んでいれば
# ここでエラーコード 1 が返り、GitHub Actions が停止（失敗）します。
find src -name "*.java" | xargs javac -d out
振り返り
GitHubActionsでコンパイルチェックしていれば、マージ後のエラーはあまり怖くない気がした。
とはいえ、コンパイルに引っ掛からない設定ファイル？とかだと、エラーにはなりそうだが、その場合はバックマージしてもローカル起動しないと気づかないから、何とも言えないかな。