【Git】「プルリクエスト」時にmasterブランチと差分があった場合

Gitでローカルのブランチの変更内容をプルリクエストをしようとした際にmasterブランチの方が先に進んでしまっている場合が多々あります。その場合は基本的に変更差分を吸収した上でプルリクエストができるのが望ましいです。

基本は下記のどちらかの方法をとります。

• ローカルブランチをmasterブランチにrebase(リベース)した状態でプルリクエストする。
• masterブランチをローカルブランチにマージした状態でレビューしてもらう。

リベースを用いた方法

下記のコマンドを実行してリベースします。

すると古いmasterブランチじゃなく最新のmasterブランチのケツから今回ローカルブランチで修正を加えた内容が反映された状態を作ってくれます。

メリット

コミット履歴が一本道でわかりやすい。

複数人での開発の場合は履歴を確実に残したいと思うのでマージよりも優れていると言えます。

デメリット

• すでに同じ名前のブランチがリモートにある場合は「push -f」を使う必要がある。
• コンフリクトが発生した場合は解消内容がそれぞれのコミットに混ざってしまう。

masterブランチにマージする方法

手順

• ローカルリポジトリのmasterブランチを最新化する。
• ローカルのmasterブランチとローカルの修正中のブランチをマージする。
• プルリクエストする。

メリット

• コンフリクトの解消を行った場合は解消内容が一つのマージコミットの中にまとまりレビューしやすい。

デメリット

コミット履歴が一本道にならない。

featureとは無関係のマージコミットが取り込まれることになるので後でコミット履歴を見たときに「何のコミットだ？」と疑問が生まれてしまうことになります。

特に、masterブランチへのマージが活発な案件とかであればよりそれが顕著になってしまうことでしょう。

まとめ

rebaseは少し操作を間違うとトラブルの元になってしまいますので、ある程度Gitの知識が必要になります。

ただ、基本的にはマージを使うよりは使えるのであればrebaseの方がより望ましいと言えるでしょう。

ただ、まだGitの経験の浅いメンバーが多い場合はrebaseではなくてマージを使うというような形が望ましいと思います。（その場合gitのコミット履歴がしっかりと残らないので密にslackなどでコミュニケーションを取ることが要求されます。）