budougumi先生からのおたよりシリーズ！（またやらかした）
今回のおたよりの宛先はこちら。
[元のブランチに追従するには]
前回の記事では、フォーク元のブランチに追従する際のコマンドとして下記を紹介した。
$ git remote add upstream （フォーク元ブランチのリポジトリURL） // 初回のみ実行 $ git fetch upstream $ git merge upstream/master
これについて、budougumi先生からおたよりが届いた。
mergeじゃなくてgit rebase upstream/masterのほうが少しコミットログがきれいですね
— Yoichiro Shimizu (@budougumi0617) February 13, 2019
つまり、下記のコマンドの方が良い、ということだ。
$ git remote add upstream （フォーク元ブランチのリポジトリURL） // 初回のみ実行 $ git fetch upstream $ git rebase upstream/master
[mergeとrebaseの違い]
結論としてはmergeコマンドの場合、Merge branch 'master' into (自ブランチ名)というコミットが作成されるため、プルリクエストを送る際に差分として検知されてしまう。
たとえば以下のコミットのように。
自分はコミットログについてはかなり無頓着な方で、ソースコードの差分に問題がなければコミットログが多少汚れていても良いかなというタイプだった。
多分これは自分が最初に触れたのがGithubではなくてBitbucketだったのが一因な気もする。Bitbucketの場合、マージコミットはマージコミットであると下の画像のように明示してくれる。なので、このプルリクエストの本質とは関係ないコミットだ、と考えて他の部分のレビューに専念することが出来ていた。
しかし、Githubの場合は、コメント以外には特にマージコミットを区別する表示はない。このようなUIなら、確かにコミットログがきれいな方が良い。
そういうわけで、rebaseコマンドを使ってこなかったのだが、改めて違いをきちんと認識したことで考えを改めた。
ソースコードをきれいに保つように、コミットログもきれいに保とう。
今まで自分のダメなプルリクエストをレビューして（見逃してくれた）皆様、ありがとうございます。
[まとめ]
Use git rebase, Luke.
