結論
個人のfeatureブランチからのマージは Squash and Merge する。
Squashマージって何ですか?
多くの記事で扱っているため、本記事では省略します。
- Git超絶まとめ
- GithubでのWeb上からのマージの仕方3種とその使いどころ
- git merge --squash でブランチでの変更を1コミットにまとめてマージ
- 慣れてきたらコミットをまとめてPull Requestしよう（git merge --squash）
なぜSquashをつかうべきなのか?
バージョン管理上見えなくてよい個人の作業記録をツリー上から無くせる
以下は Create a Merge commitしてfeatureブランチをマージした後のツリー。
作業の詳細なステップを含め、ツリーにすべての過程が残ってしまいます。
- 細かい作業コミットによってツリー全体が長くなってしまう
- １つ１つの作業に加えて
featureブランチの表現も残すため、縦にも横にも長くなる
- １つ１つの作業に加えて
- コメントの粒度がまちまちで見づらい
- 本来は作業コミットのコメント１つ１つに気を使ってほしいが そこまで縛るのは難しい
- 人によっては常に同じコミットコメントだったりしてカオス...
Approveされた作業単位でまとまって見やすい
以下は Squash and Mergeしてfeatureブランチをマージした後のツリー。
releaseブランチに5つのfeatureブランチを順次マージしたあとの図です。
知りたい情報だけが整列していてノイズが少なく、とっても見やすいですよね。
- Pull Requestの単位でコミットログが作られる
-
featureブランチ内で行った作業コミット・バックマージなどが消え、ツリーがシンプルに保たれている
もちろん Pull Requestのタイトルがわかりやすいことが前提ですが 
ただし、副作用を知っておく
頭ごなしに「Squashいいぞ」というわけでもないことを知っておこう。
Squashを乱用するとConflictして苦労する
コミット履歴（元のブランチとの関係）が残らないため、バックマージを必要とするブランチにSquash and Mergeを適用してしまうとソースコードの変更の前後関係が不明となりほぼ全行のコードでConflictをおこして大変な事になってしまう。
あくまで個人のfeatureブランチのみでSquash and Mergeを使用することをオススメする。
１Pull Request上で複数人がコミットをするようなケース (OSSなど)
ここまで聞くと「featureブランチならすべてSquashだろ！」と言い出しそうですが、手放しにそうとも言えないようだ。
ここで紹介する副作用はSquashマージすることによりコントリビュートが消えてしまう問題。
OSSでSquash and MergeをするときはPull Requestが個人の作業に閉じているかを確認した上で実施したほうが良さそうだ。
まとめ
- 個人の作業ブランチはSquash and Mergeして、プロジェクトのソースコードツリーをシンプルに保つ心がけをしよう
- Squashの副作用を把握して事故をなくそう