Gitプルリクエストでコンフリクトが発生した場合の対応

はじめに

プルリクエストでコンフリクトが発生した場合にどうするかというのが初心者が混乱する最初のポイントになるかと思います。どれが良いのかわからないが、困らないようにやってみる。

準備

masterからfeatureを分岐してそれぞれいくつかコミット。
githubのpull-requestで、masterにfeatureを取り込む際にコンフリクトが発生した場合。

【option1】featureにmasterをmergeする

1. masterを最新にする
2. featureにmasterをmerge
3. コンフリクトを解決
4. featureをリモートにpush
5. github上でpull-requestをマージ

git checkout feature
git merge master
(resolove conflicts)
git push origin feature

Benefits

• コンフリクトの解決が1回で済む
• 履歴を書き換えない
• 強制pushせずに済む

Drawbacks

• 一回の統合操作で、ローカルでのマージログ、githubでのマージログの2つが残り、あまり意味のないコミットが発生する

【option2】featureにorigin/masterをmergeする

1. featureをcheckout
2. pullでfeatureにorigin/masterをmerge
3. コンフリクトを解決（SourceTreeだとメッセージ出ないので注意）
4. featureをリモートにpush
5. github上でpull-requestをマージ

git checkout feature
git pull origin master
(resolove conflicts)
git push origin feature

Benefits

• option1と全く同じ結果、仕組みになるが、最新取得＋マージが一発で早い

【option3】masterをfeatureにrebaseする

1. masterを最新にする
2. featureをcheckout
3. masterをfeatureにrebase
4. コンフリクトを解決
5. featureをリモートに強制push
6. github上でpull-requestをマージ

git checkout feature
git rebase master
(resolove conflicts)
git push -f origin feature

Benefits

• ブランチの履歴が別になってわかりやすい

Drawbacks

• コンフリクトの解決が複数回発生して面倒
• リモートを強制的に書き換えてしまう

【option4】origin/masterをfeatureにrebaseする

1. featureをcheckout
2. origin/masterをfeatureにrebase
3. コンフリクトを解決（SourceTreeだとメッセージ出ないので注意）
4. featureをリモートに強制push
5. github上でpull-requestをマージ

git checkout feature
git pull --rebase origin master
(resolove conflicts)
git push -f origin feature

Benefits

• option3と全く同じ結果、仕組みになるが、最新取得＋リベースが一発で早い

まとめ

githubでマージコミットが残ることを考えると、ローカルでマージコミットを残さないリベースをしたほうが無駄がない感じがする。ただマージ作業が複数回発生してしまうのは危険な香りがする。
この対応で混乱すると、Gitよくわかんね、という評価になってしまうので、事前に考え方を整理しておきたい。