自分の中で git merge と git rebase は明確に使い分けていたつもりだけど、「こういう場合はどちら（merge/rebase）がいいのかなあ...」
とえらい悩んだので、そのケースを書き記しておきます。（同じようなケースで悩んだ人に）
git mergeとgit rebaseの違いを振り返る
まず、おさらいとしてgit merge と git rebase の違いをさらっと振り返ります。
git merge: 元ブランチと枝ブランチを統合。マージ時、新しいコミットを作成する。
git rebase: 元ブランチから分岐した以降のブランチを取得できる。注意点として、コミットIDが刷新される。
gitは奥が深く、git rebase はコミット履歴移動、修正、削除などもできるみたいですが、自分はあんまりその目的では利用しません。
なので、そのあたり解説みたいなことはできないし、するつもりもないのであしからず。
マージの代表的な利用例としてはプルリクエストのApproveをもらった際にmasterにマージしますね（まあ、マージ先はステージング環境とかケースバイケースだけど）。その際は親ブランチにmergeコミットが残されます。
で、git rebaseは過去記事にも残してますが、主にプルリクエストを出す前に、masterの更新履歴を取り込み、土台を最新の状態にして主にコンフリクトを起こすことを避けるために利用しています。
-
-
[Git]プルリク前に作業ブランチを最新にする方法[git rebase]
続きを見る
んで、本題の何が自分を悩ませたのかというと、masterとは世界線を分けていて、開発専用親ブランチ(developとする)を最新に保つために、git rebaseにしようか、git mergeにするべきか、ということです。
masterのコミット更新履歴を定期的にdevelopに反映させておくことは、いざ、developブランチをmasterへマージする際にコンフリクトを避けたい、開発時のバグもより少なくできるという大きなメリットがあります。
これは、世界線を分ける目的は大きなコード変更であることが大体だと思います。そして、大きな変更であればあるほど、メリットを享受できると思っていて、安心感を得ることは開発を円滑に進めることにもつなげることができると考えています。
で、ここまで話しておきながら、自分が出した結論は、git mergeが適切なのかな、と思います。
なぜなら、それまでの開発コミットハッシュ値を（無駄に？）変更する必要もない、マージコミットがあることで、masterの状態を取り込んだという履歴を残すことができる
といった所でしょうか。
ま、git rebaseでもオプションを付与することでマージコミットを残すことができるようですが、
command
git rebase --rebase-merge -i <リベース先>
まあ、別に git merge で事足りるので、別にかな。
余談
ちなみに、世界線を分けたdevelop親ブランチからの枝ブランチをプルリク後にマージして、そのうえで、masterからの最新状態を反映するためにgit rebase するとなると、多分マージした、枝ブランチコミットIDも刷新される。
けれども、結局GitHub上のmasterに世界線の親developブランチをマージする時はプルリクを出す必要があるから、多分問題はないのだろうけども、まま、未実験なのであしからず。