GitHubでのPRのマージについて、"Create a merge commit" ではなく "Squash and merge" にしてみたら色々といいことがあった話です。
今まで個人開発ではmainブランチへの直接コミット、共同開発でのPRでは Merge Commit で運用することが多かったのですが、Squash Merge を採用していた開発に参加してから、Squash Merge っていいなと思ったのでその点をまとめてみることにしました。
利点
1. コミット履歴がきれいに、シンプルになる
コミット数 ≒ マージされたPR数 になるため、当然ですが mainブランチがきれいになります。
またコミットメッセージにPR番号もつくため、その詳細も追いやすくなったと感じました。
2. PR の Title と Description のみを意識すれば良い
コミットメッセージの規約として Conventional Commits を参考にしていることが多いのですが、（特にコミュニティ開発だと）人によってバラバラなコミットメッセージになってしまいがちだと感じています。
しかし、Squash Merge であれば PRタイトル（+ PR番号）が最終的なコミットメッセージになるため、レビューと共に別の人がそのルールに沿って修正するだけで済みます。（もちろん各個人がしっかりとできればそれが一番ですが）
そして設定で "Default commit message" を "Pull request title and description" にしてしまえば、PRの description に依存するため、個々のコミットをシンプルにすることができます。
私はmainブランチに残る形での "wip" のようなコミットが好きではないのですが、コミットメッセージを考えるのはある程度の労力が要ると感じており、なるべくシンプルで（雑に）済むのであればそれが一番だと思っています。
一方でPRの最終的なコミットが wip, wip, wip, done のようになってしまうのは良くないですが、最悪そのようなコミットでもいいのではないかなと思うこともあります。（これはあくまでも個人開発やコミュニティ開発での話で、業務ではsquashを行うなど工夫する必要があると考えています。）
コミットメッセージは Git Hooks や .vscode のような開発環境の設定で縛ることもできますが、Git Hooks はまだしも開発環境を制限するような状態にはすべきではありません。
そうやって1つ1つのコミットメッセージを制限するよりは、PRだけを管理するほうがいいと考えています。
注意すべき点
1. PRの設定
"Squash and merge" の "Default commit message" の設定を "Pull request title and description" にします。
こうすることでコミットメッセージの1行目には PR Title が、以降は PR Description となってわかりやすいコミットになります。
2. PR粒度
1 PR = 1 commit のため、もちろんその粒度には気をつけなければなりません。
ですがこれは 1 PR = 1 issue のような運用にしてしまえば、各個人が特に気をつける必要もないと思います。
こうすれば issue をコミットに紐づける必要もなく、PR Description で紐づけるだけで済みます。
PR Title に issue 番号を書くべきではありません。なぜなら、最終的にコミットメッセージには PR番号や PR Description が記載されるため、それでたどることができるためです。
例えば chore: setup project (#1) のような PR #2 を立てた場合、コミットメッセージは chore: setup project (#1) (#2) となってしまいます。やめましょう。
3. コミット粒度（BETTER）
できればコミット粒度には注意すべきです。
コミットは1つになりますが履歴からPRを参照することになるため、その際に困らない程度にコミットは分けるといいと思います。
おわりに
これを個人開発でやったことで作業の単位が履歴でわかりやすくなり、共同開発でやったことでバラバラだったコミットがそうでなくなりました。
いろんな人がいる開発でこそ便利な運用だと思います。"Squash and merge" で快適なGitHubライフを送りましょう。