はじめに
前提条件
今回は以下のようなリポジトリに対して、設定を行いました。
- 個人開発で利用する（基本は自分ひとりで開発を進め、時々レビューしてもらう）
- Ruby on RailsのWebアプリ
- Publicリポジトリ（ポートフォリオとして公開したいため）
- GitHubの無料枠の範囲で使う
記載を割愛した項目は、デフォルトのまま変更しなかったもの、かつ変更しないことについて特に悩まなかったものです。
設定箇所
リポジトリの「Settings」画面内の項目を見ていきます。
General
Features
デフォルトのまま。
- Sponsorships
- スポンサーボタンを表示する設定。ひとまず不要そう。
- Discussions
- issueとは別で議論するためのスペースを設定できる。issueで十分そうなので設定せず。
Pull Requests
マージ方法の設定
squash and mergeのみを許可するように変更しました。
自分が現在rebase方式しか経験がなく、squash and mergeの方式も試したかったためです。
この設定をすると、PRをマージする時に「Squash and merge」しか選べないようになります。
ベースブランチ更新時にPRブランチの更新をサジェスト
Always suggest updating pull request branches を有効化しました。
PRを作成してからベースブランチに新たに変更が入った場合、画面上に「ブランチを更新する」ボタンが表示されるようになります。
基本的にベースブランチの最新を取り込んでCIのテストをパスしてからマージする形にしたいので、簡単にベースブランチの更新を取り込めるように設定しました。
PRマージ後にブランチを自動で削除
Automatically delete head branches を有効化しました。
マージ後に画面上のボタンを押してブランチを削除する必要がなくなります。大体の場合有効にしてよさそう。
Access
Collaborators
Interaction limits
議論が白熱している時などに、一時的に外部ユーザーとリポジトリとのやりとりを制限できる機能。
今回対象とした個人開発用リポジトリで議論が白熱することは当面なさそうなので、何も変更せず。
Code review limits
Limit to users explicitly granted read or higher access を有効化しました。
見知らぬユーザーがPRをApproveできないようにしたく、設定しておきました。
コメントは誰でもすることができる状態のままになります。
Code and automation
Branches
このリポジトリでは、GitHub flowをベースとしたブランチ運用を想定しています。
--- title: Git branch 運用イメージ --- gitGraph commit branch feature1 branch feature2 checkout feature1 commit commit checkout main merge feature1 checkout feature2 commit checkout main merge feature2 branch feature3 checkout feature3 commit checkout main merge feature3 commit tag: "v1.0.0"
上図のような形式で、
- mainブランチと、各featureブランチのみで運用
- featureブランチはmainへのマージ後に削除
- mainブランチにタグを打ったら、本番環境へデプロイ
という運用ができるように、mainブランチに対して以下の保護設定をしています。
Branch protection rule
Require a pull request before merging を有効化しました。
mainへのマージは、基本的にPR上でレビューしてからにしたいためです。
ただ今回は自分ひとりで開発・確認・マージするシーンが多くなるはずので、approveは必須にしませんでした。
Require status checks to pass before merging を有効化しました。
指定したステータスチェックが通らないとマージできないようにすることができます。
Actions - General
Allow peno022(自分), and select non-peno022, actions and reusable workflows を選択しました。
品質の分からないworkflowを使ってしまうのを防ぐため、自分で作ったものか公式で認証済みのworkflowのみを許可したかったからです。
Security
Code security and analysis
Dependabot
Dependabot alerts と Dependabot security updates を有効化しました。
脆弱性の問題がなければ必ずしも常に最新バージョンにする必要はなさそうに思い、Dependabot version updatesは無効化のままとしています。
Dependabotは、依存しているライブラリのセキュリティ脆弱性を通知してくれ、最新バージョンにアップグレードするためのPull Requestの自動作成まで行ってくれるものです。
Code scanning
CodeQL analysis をAdvancedで有効化しました。
Defaultを選択するとGitHub側で自動的に CodeQL analysis が実行されます。
一方で、Advancedにすると、自分でワークフローを組む必要があります。
ただ、GitHubがデフォルト設定のymlファイルを作成してくれるので、ワークフローの設定自体はすぐにできました。
今回はワークフローの実行タイミングを自分でコントロールできたほうが都合がよいと考え、Advanced設定を選択しています。
Secret scanning
Receive alerts on GitHub for detected secrets, keys, or other tokens.を有効化しました。
publicリポジトリに秘密情報がアップロードされてしまった場合に、GitHubから通知が来るようになります。
Secrets and variables
Actions secretsに下記を設定しました。両方ともvalueにはtrueを設定します。
この設定により、デバッグログが有効になります。
- ACTIONS_RUNNER_DEBUG
- ACTIONS_STEP_DEBUG
Integrations
特に変更せず、デフォルトのまま。
Email notificationsはデフォルトでActiveになっているため、メール通知は受け取れる状態になっています。
