GitHubのプルリクをmergeする時に選べる3つのマージ方法

2019, Oct 10

アジェンダ

• Create a merge commit
• Rebase and merge
• Squash and merge
• どうしても Rebase したい
• 追記
• 注釈

参考

普段ソロ開発ばかりしているし、チーム開発は忙しくなりがちなんで GitLog なんて見ないですが、これも試して書き足します。

Create a merge commit

絵でいうと右に曲がってるコミットログがこれです。 今回、merge してる感を出したかったのでユースケースが微妙ですが、ここで言いたいのは複数人開発をする時にやりやすくなりますよ、ということです。 今は master から伸びた線が 1 つですが、たとえば develop リポジトリを作って、それを起点に開発すれば大量の develop 派生の線が出てきます。

Rebase and merge

やることは merge と似たようなものですが、こちらは順番を意識します。 レビューをする時に一本の線だけで見れるので、レビュアーがすごく楽になります。 あっちこっちに行って、最終的にどうなったんだっけ？というのを気にしなくて良くなります。

Squash and merge

試したことがない¹ですが、参考ページを見るといいとこ取り？みたいな印象です。 Squash コマンド自体も個人開発だとあまり使う機会がないのですが、そういうのもあるよ、ということで。

どうしても Rebase したい

チームで Merge ではなく Rebase を採用している場合があります。 一人でやってる場合は Merge だろうが Rebase だろうが大したことはない（切り戻す事がない、あったとしても自分で全コードが把握できるため）ですが、チームでプロダクト開発をするとそうはいきません。

1. 手元のファイルを保持する
2. Master を git clone し直す
3. 自分が書き換えた部分をやり直す、ファイルを上書きする²

という手順で、再度 Master なり develop なりに push すれば良いですが、見直す意味でも別ブランチを作って PR/MR するのが見直しにもなって良いのではないかと思います。³

追記

push して rebase したら pull しないと履歴がおかしくなります。

注釈