こんにちは、タイミーでバックエンドのテックリードをしている新谷 (@euglena1215) です。
先日公開した記事 「モノリスRailsにマージキューを導入してデプロイフローを安定させる」 では、多くの開発者が関わるモノリスリポジトリのデプロイフローを安定させるために、GitHubのマージキューを導入した事例を紹介しました。
今回からは、導入にあたって直面した課題や、我々の開発プロセスにうまく組み込むために工夫した点などを、TIPSとして何回かに分けて紹介していきます。
シリーズ最初のトピックは、マージキューを導入すると直面するマージメソッドの制約についてです。
開発者の自由がなくなる？マージフローの変化
マージキューを導入すると、開発者のマージ作業のフローが大きく変わります。最も大きな変化は、開発者が直接「Merge」ボタンを押すのではなく、「Merge when ready」ボタンでエンキュー（マージキューに追加）する点です。
エンキューされたPull Requestのマージ作業そのものは、開発者ではなくbotが内部的に自動的に行うようになります。
マージメソッドを指定できない仕様
2025年7月時点でのGitHubマージキューの仕様では、各開発者がエンキュー後のマージメソッドを選ぶことはできません。代わりに、リポジトリの設定として、どのマージメソッド（Merge commit, Squash and merge, Rebase and merge）を使うかを指定しておく必要があります。
結果として、これまで開発者が個人の好みでマージメソッドを選んでいた運用はできなくなり、全員が同じメソッドを使うことを強制されます。
我々が行った選択とそのプロセス
マージキューを導入するにあたり、我々は Merge commit と Squash and merge のどちらに統一するか、という選択を迫られました。
各選択肢の課題の比較
それぞれの設定をデフォルトにした場合に、開発者にどのような影響が出るかを比較検討しました。
Squash and mergeを選択した場合の課題: 意図的に複数のコミットに分けているプルリクエストが、マージ時に強制的に1つにまとめられてしまいます。さらに、GitHubのUI上で自動生成されるコミットメッセージは、個々のコミットメッセージを単純に連結したものになり、マージ時にメッセージをきれいに整形することができません。Merge commitを選択した場合の課題: これまでfeature branch上で作業途中のコミットを細かく積み、マージ時にUI上で1つにまとめていた開発者にとっては、整形前のコミットがそのままmasterブランチの履歴に残ってしまうことになります。
我々の決定：「Merge commit」の採用と運用によるカバー
両者を比較した結果、我々はリポジトリのデフォルト設定として Merge commit の採用を決定しました。
決め手は、Squash and merge を選択した際の「コミットメッセージが適切に整形できない」という制約の影響が大きいと判断したためです。
その上で、Merge commit を選択した場合の課題（整形前のコミットが残ってしまう）については、運用でカバーする方針としました。
具体的には、コミットを1つにまとめたい開発者に対し、「マージキューに入れる前に、feature branch 上で git rebase -i などを使って事前にコミットを整理してもらう」という協力をお願いすることにしました。
この運用により、意図したコミット履歴をそのまま残したいケースと、複数のコミットを1つにまとめてマージしたいケース、その両方に対応できると考えました。
この決定の背景と具体的な運用ルールをドキュメントにまとめ、開発者全員に協力を依頼することで、スムーズな移行を目指しました。
まとめ
GitHubのマージキューはデプロイフローを安定させる有用なツールですが、一方で、チームの開発スタイルに影響を与える制約も存在します。特に、マージメソッドが1種類に固定される点は、導入前にチーム内でコンセンサスを取っておくべき重要なポイントです。
この「マージメソッドが強制的に固定される」という仕様は、見落とされがちなポイントだと思いましたので、最初のTIPSとして紹介しました。
次回は、マージキューの特性を活かして、障害対応時のCI待ち時間を短縮した工夫についてご紹介します。
