
こんにちは、4月にPLAYに入社した原田です。
入社してすぐに、前職で活用していたGitHubの設定を思い出し、現在の案件リポジトリにもいくつか適用してみました。 その結果、開発チームの生産効率が向上しました!
この記事では、私が実際に設定して効果を感じた、GitHubのおすすめ設定をご紹介します。 チーム開発の参考になれば幸いです。
- ① Allow squash merging
- ② Always suggest updating pull request branches
- ③ Automatically delete head branches
- ④ Require pull request reviews before merging
- ⑤ GitHub Secret Protection
- おわりに
① Allow squash merging
PRをマージする前に、コミットをスカッシュして1つにまとめてくれる機能です。
「 Allow squash merging」 を導入したところ、コミット数が少なくなるため、コンフリクトが大幅に削減されました。
また、PRのタイトルにチケット番号を含めてマージすると、コミットログを見ただけでどの作業が入っているのかがすぐに把握できます。
ただし、注意点もあります。
すでにスカッシュでまとめられたブランチを、さらにスカッシュマージしてしまうと、コミット履歴が1つに集約されてしまい、エディターなどから履歴を追いづらくなります。
特に、スプリント開発用の一時ブランチから、develop や main などの長期運用ブランチにマージする場合は、履歴の可読性やトレース性を損なわないように注意が必要です。

② Always suggest updating pull request branches
この設定を有効にすると、baseブランチに更新がある場合に「Update branch」ボタンが表示され、簡単に差分を取り込むことができます。
特にCIツールと組み合わせて運用しているプロジェクトでは、常に最新の状態を含めたPRでテストが走るようになるため、ブランチ間の不整合による不具合を未然に防ぐことが可能です。
PRを出す前にリベース・マージ操作を都度行う手間も減ります。
注意点としては、ボタンを押すだけでリベース・マージが行われるため、その都度CIツールのクレジットが消費されることです。 PRをDraftで運用し、CIツールを走らないようすることで回避可能です。


③ Automatically delete head branches
リポジトリに不要なブランチが大量に残っていませんか?
この設定は、PRをマージした後に、そのブランチを自動で削除してくれる機能です。
ブランチが増えていく中で、手動で削除する手間が省け、リポジトリのブランチ一覧がスッキリ整理されます。 もし後からそのブランチが必要になった場合でも、「Restore branch」機能で簡単に復元可能なので安心ですね。

④ Require pull request reviews before merging
レビュー文化を根付かせたいチームにはこの設定が非常に有効です。
この設定をオンにすると、誰かがレビューをしてApproveしない限り、マージができなくなります。 コード品質を担保するだけでなく、属人化の防止や知識共有にもつながるため、チームでの開発においてはぜひ取り入れたい機能です。


⑤ GitHub Secret Protection
生産効率からは外れてしまいますが、セキュリティ対策として GitHub Secret Protectionも非常に重要です。
特に外部APIキーや認証情報などをGitHub Actionsで利用する場合、
リポジトリに環境変数(Secrets)を設定することになりますが、誤ってログに出力したり、PRから漏洩してしまうリスクがあります。
GitHubでは、以下のようなSecret Protectionの機能が提供されています。
パターンマッチによる漏洩検知:
アクセストークンやシークレットキーなど、特定のパターンに一致する文字列がpushされた場合、自動で警告を出してくれます。
Actionsでのマスキング機能:
ログ出力時にSecretsの値が *** にマスクされ、誤って表示されることを防げます。
環境単位でのシークレット管理:
productionやstagingなど、環境ごとに異なるSecretsを設定でき、意図しない混同を防げます。
実際にアクセストークンを含めたコミットをPushすると以下のようなエラーが発生します*1。
% git push -u origin main Enumerating objects: 38, done. Counting objects: 100% (38/38), done. Delta compression using up to 8 threads Compressing objects: 100% (32/32), done. Writing objects: 100% (38/38), 3.17 MiB | 2.26 MiB/s, done. Total 38 (delta 0), reused 0 (delta 0), pack-reused 0 remote: error: GH013: Repository rule violations found for refs/heads/main. remote: remote: - GITHUB PUSH PROTECTION remote: ————————————————————————————————————————— remote: Resolve the following violations before pushing again...

GitHub Secret Protectionをうまく活用することで、チーム全体のセキュリティ意識が向上し、安心してCI/CDを運用できるようになります。
おわりに
いずれも小さな設定ですが、積み重ねることで開発効率や品質、コミュニケーションコストが大きく改善されました。 GitHubのSettingsやBranch protection rulesは、まだまだ活用できるポイントがたくさんあるので、ぜひチームに合った設定を検討してみてください。
*1:このエラーはダミーのSlack API Tokenで出たものです(xoxb-0000000000-0000000000000-xxxxxxxxxxxxxxxxxx)