GitHubのmainブランチを守る：最低限のブランチ保護設定と3wayマージ運用

2025-12-07

納戸工房では、Minecraft の Paper プラグイン「twbridge」を
GitHub の nando256/twbridge リポジトリで管理しています。

今までは、

  • main ブランチにそのままコミット
  • 修正もバグも、全部 main に直プッシュ

という、ある意味 “男らしい” ？運用をしていました。

ところが、コード量や機能が増えてくると、

  • 「あれ、このコミット何のために入れたんだっけ？」
  • 「ちょっとまずい変更を main に入れちゃったな……」
  • 「過去の状態に戻したいけど、履歴がごちゃごちゃで見るのがつらい」

という場面がじわじわ増えてきます。

1人開発だからといって main を甘やかしていいわけではないな、と思い始めたわけです。

今回の目的はシンプルです。

main ブランチへの強制プッシュを防ぐために、GitHub のブランチ保護を入れてみる。
どうせやるなら、一般的な3wayマージで取り込む運用を試してみたい。

目次

目指した運用：main 直プッシュ禁止＋ゆるい 3way マージ

ポイントは「がっつりルールで縛る」のではなく、

  • main に 直接 push はできない
  • 作業は ブランチを切って push
  • GitHub 上で Pull Request を作ってマージ
  • マージは GitHub の標準的な 3way マージ（Merge pull request ボタン）

という、かなりゆるいけど 最低限のラインだけは守る 形にすることです。

レビュー必須とか、CI 必須とか、CODEOWNERS とか、
そういう “本気運用セット” までは今回はやりません。

今のままだと何が困るか

1人で main に直プッシュしていると、次のような問題が出てきます。

  • コミット単位が雑になりがち
    • 「とりあえず保存」みたいなコミットが積み上がる
  • バグを埋め込んでも気づきにくい
    • main に載せてから「あ、まずい」と気づく
  • 過去バージョンに戻したいときに履歴が読みづらい
    • どこが機能追加で、どこがバグ修正かがぱっと見で分からない

そして何より、

  • 「いつでも main を壊せる」という心理的プレッシャー

があります。
実験的なコードを main に入れるのがちょっと怖くなってきたので、
「main に入るのはそれなりに確認したものだけ」 という線引きをしたくなりました。

GitHub で main を「最低限だけ」保護する

やった設定は本当に最低限です。
手順

  1. https://github.com/nando256/twbridge を開く
  2. 上部のタブから Settings を開く
  3. 左メニューの Code and automation → Branches をクリック
  4. 「Branch プルリクエストotection rules」セクションで
    Add branch ruleset をクリック
  5. 次のように設定：
    1. Ruleset Nane
      3way merge(自由に決めてください)
    2. Enforcement status
      Active(rulesetを有効にします)
    3. Target branchges
      Add target > Include default branch
    4. Require a pull request before merging
      チェックを入れる
    5. 他はそのまま

これだけ です。
レビュー必須もステータスチェック必須も CI も、今回はいっさい触っていません。

3way マージについて

GitHub のデフォルトの「Merge pull request」ボタンは 3wayマージ（マージコミット付き） なので、

  • リポジトリの Settings → General → Pull Requests
    • Allow merge commits が ON になっていれば、3wayマージが使えます

Squash と Rebase の設定はお好みでそのままでも大丈夫です。
（特にいじらなくても、今まで通り「Merge pull request」で 3way マージされます）

運用イメージ

1. main からブランチを切る

git checkout main
git pull origin main
git checkout -b feature/xxx

2. 変更 → コミット → GitHub に push

git add .
git commit -m "Something"
git push origin feature/xxx

3. GitHub 上で プルリクエスト 作成

4. 自分で内容確認 → 「Merge pull request」（3way マージ）

これだけです。
CI もレビュー強制も無しで、「main に直 push できない & プルリクエスト 経由で 3way マージ」という最小構成になります。

やめたくなったら

  • 「やっぱり main に直 push したくなった」
  • 「一部だけ緩めたい」

みたいなことがあったら、Rules > Rulesets の画面でDisableにすればすぐ戻せます。

まとめ

やったことはすごくシンプルです。

  • デフォルトブランチ（main）に対してブランチ保護を設定
    • target branches：default branch
    • bypass：なし
    • Require a pull request before merging：オン

これだけで、

  • main に 直接 push できない
  • 必ずブランチを切ってプルリクエスト → 3way マージ という流れになる
  • main の削除や force push も防げる

という「最低限だけど効くガード」が付きました。

1人開発でも、main を雑に触ると後から自分が困ります。
「気をつける」ではなく、「物理的に main に直 push できない」ようにしておくと、
履歴もきれいに保ちやすく、気楽にブランチで実験もしやすくなります。

まずはこのライトな設定で運用してみて、
必要になったタイミングで「レビュー必須」や「CI 必須」などを足していくつもりです。

サーバ＆テクノロジ3wayマージ,GitHub,mainブランチ,Minecraftプラグイン,Paperサーバー,twbridge,バージョン管理,ブランチ保護,プルリクエスト,個人開発

Posted by 納戸 工房