はじめに
個人開発だと、つい main や develop にそのまま push してしまいがちですが、より実務に近い形で開発したいと思い、個人リポジトリでも Pull Request ベースで開発することにしました。
今回やりたかったことは次の2つです。
PR のデフォルトのマージ先を develop にする
develop への直接変更や削除、force push を防ぐ
この記事では、GitHub の設定画面から develop をデフォルトブランチに変更し、Ruleset で develop を保護する手順をまとめます。
前提
この記事では、次の状態を前提にしています。
- GitHub リポジトリがある
-
developブランチが存在している - リポジトリの Settings を変更できる権限がある
まだ develop ブランチがない場合は、先に作成しておきます。
git switch -c develop
git push -u origin develop
デフォルトブランチをdevelopに変更する
まず、PR 作成時のデフォルトのマージ先を develop にします。
GitHub のリポジトリ画面で、次の順に開きます。
Settings -> General -> Default branch
そこで Default branch を develop に変更します。
これで、新しく Pull Request を作成したときの base branch が基本的に develop になります。
GitHub CLI を使う場合は、次のコマンドでも変更できます。
gh repo edit --default-branch develop
Rulesetでdevelopを保護する
次に、develop を直接壊さないように Ruleset を設定します。
GitHub のリポジトリ画面で、次の順に開きます。
Settings -> Rules -> Rulesets -> New branch ruleset
Ruleset の基本設定は次のようにしました。
Ruleset Name: protect-develop
Enforcement status: Active
Target branches: Default
今回は Default branch を develop にしているので、Target branches は Default を指定しました。
develop 固定だとわかりやすくしたい場合は、Include by pattern で develop を指定してもよいです。
設定したルール
今回有効にしたルールは次の3つです。
Restrict deletions
Require a pull request before merging
Block force pushes
Restrict deletions
対象ブランチを削除できないようにします。
develop は開発の中心になるブランチなので、誤って消さないようにしておきます。
Require a pull request before merging
develop に変更を入れるとき、Pull Request 経由にします。
個人開発でも PR を作ることで、差分を見直す習慣を作れます。
今回は Required approvals を 0 にしました。
つまり、レビュー承認は必須にしないけれど、PR 経由でマージする運用です。
Block force pushes
対象ブランチへの force push を禁止します。
履歴を壊す操作を防げるので、develop には入れておきたい設定です。
注意点
Ruleset の画面では、PR のデフォルトのマージ先は変更できません。
PR のデフォルトの base branch は、基本的にリポジトリの Default branch で決まります。
そのため、今回の設定は次のように役割が分かれます。
Default branch の変更
-> PR のデフォルトマージ先を develop にする
Ruleset の設定
-> develop を保護する
また、Ruleset には Restrict updates という項目もあります。
これはかなり強い制限なので、最初から有効にしなくてもよいと思います。
まずは次の3つだけでも十分です。
Restrict deletions
Require a pull request before merging
Block force pushes
まとめ
今回は、個人開発でも実務に近い PR ベースの運用に寄せるために、GitHub の設定を変更しました。
やったことは次の2つです。
Default branch を develop に変更した
Ruleset で develop を保護した
これで、新規 PR のマージ先は develop になり、develop への直接変更や force push も防ぎやすくなりました。
個人開発でも、こういう小さい運用ルールを入れておくと、変更を見直す流れが自然に作れてよさそうです。


