こんにちは！チームの開発スピードを落とさずに、かつ「やらかし（本番障害）」を完全にゼロにするインフラとパイプラインの構築に日々情熱を燃やしている先輩エンジニアです。
新しいプロジェクトが始まり、GitLabを使い始めたとき、最初に直面するのが「誰でも本番ブランチにコードをプッシュできてしまう」という恐怖の初期設定ですよね。
「うっかり `git push origin main` を本番に向けて打ってしまい、テスト環境ですらないライブ環境を粉砕した…」
そんな冷や汗をかくような修羅場を、僕たちは何度も目撃してきました。
これを一発で解決するのが、GitLabの「Protected Branches（保護ブランチ）」という機能です。
今回は、GitLabを触り始めたばかりのあなたに向けて、この保護ブランチの役割から、事故を防ぐための神設定、そしてチーム全員が安心して開発できるようになるためのベストプラクティスまで、優しく丁寧に紐解いていきます。
これをマスターすれば、毎日のデプロイ作業が劇的に安心で楽しいものになりますよ！さあ、一緒に見ていきましょう。
—
1. そもそも「Protected Branches（保護ブランチ）」とは何か？
GitLabでは、デフォルトの状態だと、プロジェクトに参加している開発者権限（Developer）を持つメンバーであれば、どのブランチに対してもコードを直接プッシュ（`git push`）したり、強制プッシュ（`git push –force`）で履歴を書き換えることができてしまいます。
これは個人の小規模な開発なら自由度が高くて良いのですが、チーム開発、ましてや本番環境（`main` や `production` ブランチ）においては百害あって一利なしです。
保護ブランチ（Protected Branches）を設定すると、指定したブランチに対して以下のような「強力なリミッター（安全装置）」をかけることができます。
1. 直接プッシュの禁止: 誰もそのブランチへ直接 `git push` できなくなります（必ずMerge Requestを経由する必要が生まれます）。
2. 強制プッシュの禁止: `–force` オプションでリモートの履歴を破壊することが物理的に不可能になります。
3. 削除の禁止: 誤って本番ブランチそのものを削除してしまう悲劇を防ぎます。
4. マージ権限の制御: 「誰がそのブランチへマージしてよいか」を厳密にコントロールできます。
—
2. 【実践】最も重要な基礎セットアップ：本番ブランチを守る
それでは、実際にGitLabの画面を使って、本番ブランチ（ここでは `main` とします）を保護する設定を行っていきましょう。
手順1: 保護ブランチの設定画面を開く
1. GitLabのプロジェクト画面を開きます。
2. 左側サイドバーの [Settings]（設定） ＞ [Repository]（リポジトリ） をクリックします。
3. [Protected branches]（保護ブランチ） の項目を見つけて、[Expand]（展開）ボタンを押します。
手順2: ブランチと権限のルールを定義する
ここで、どのブランチをどのように守るかを指定します。初心者のうちは、以下の黄金設定を覚えておけば間違いありません。
- Branch: `main` （または保護したいブランチ名。ワイルドカードとして `release/` のように指定することも可能です）
- Allowed to push: [No one]（誰も許可しない）
- ここがポイント！ 「誰も直接プッシュできない」ようにするのが、事故を防ぐ第一歩です。コードを反映させるには、必ず「Merge Request（マージリクエスト）」の審査を経る強制力が生まれます。
- Allowed to merge: [Maintainers]（メンテナー以上） または [Developers and Maintainers]
- レビューを経て「よし、本番に入れたい！」となったコードを、実際にブランチへ統合（マージ）できる権限を持つ人を絞ります。チームの運用に合わせて、リードエンジニアやテックリードのみに制限する（Maintainers）のが安全です。
設定が終わったら、[Protect] ボタンをクリックします。これで完了です！
—
3. 精度高い「HelloWorld」的動作確認：本当に守られているか試してみよう！
設定が正しく機能しているか、実際に手を動かして確認してみましょう。これがいわゆる、私たちの世界における「安全確認の儀式（動作確認）」です。
ステップ1: 自分の手元から直接プッシュしてみる
ローカルの `main` ブランチに適当な変更を加え、そのままリモートの `main` へプッシュしてみます。
適当なファイルを作ってコミット
echo “hello world” >> test.txt
git add test.txt
git commit -m “chore: test protection”
本番ブランチ（main）へ直接プッシュを試みる
git push origin main
ステップ2: GitLabからの「拒絶」を確認する
ターミナルに以下のようなエラーメッセージが表示されれば、保護設定は大成功です！
remote:
remote: =================================================================
remote: GitLab: You are not allowed to push code to protected branches on this project.
remote: =================================================================
remote:
To gitlab.com:your-organization/your-project.git
! [remote: main] main -> main (pre-receive hook declined)
`pre-receive hook declined` という冷徹かつ優しいメッセージが、あなたの大切な本番環境を事故から守ってくれました。
正しいフロー（安全な道）はこうです：
1. 作業用のブランチを切る（`git checkout -b feature/hello-world`）
2. そこにプッシュする（`git push origin feature/hello-world`）
3. GitLab上で Merge Request (MR) を作成し、同僚にコードレビューをしてもらう
4. レビューをクリアしたら、GitLabの画面上からマージする
この王道の開発フローが、自然とチームに強制されます。
—
4. 現場で本当に役立つ！事故防止のためのベストプラクティス
最後に、数々の修羅場をくぐり抜けてきたシニアエンジニアから、GitLabの保護ブランチ運用における「現場の知見」をいくつか授けましょう。これを取り入れるだけで、チームの信頼性が段違いに向上します。
① 「Code Owner（コードオーナー）」機能の併用
「誰がマージしてもいい」状態にしておくと、結局いつの間にか適当なレビューでバグが本番に入り込みます。
プロジェクトのルートディレクトリに `CODEOWNERS` というファイルを作成し、「このファイルやディレクトリは、あの人（あるいはあのチーム）の承認がないとマージできない」というルールをコードベースで定義しましょう。
CODEOWNERS の例
インフラ設定やデータベース周りはシニアエンジニアの承認を必須にする
/terraform/ @senior-engineers
/db/migrations/ @db-admins
GitLabの保護ブランチ設定で 「Require approval from Code Owners」 にチェックを入れておくと、このファイルで指定された人の承認がなければマージボタンが押せなくなります。これが最強の事故防止策です。
② マージ前のパイプライン成功を義務付ける
コードをマージする前に、自動テスト（CI）や静的解析が必ずパスしていることを条件にしましょう。
保護ブランチの設定項目にある 「Require a successful pipeline before merging」 にチェックを入れます。これにより、「テストが赤信号のまま、勢いで本番にマージしてサイトを落とした」という人間のうっかりミスを、機械が完全に防いでくれます。
③ 複数人レビューの原則（Minimum approvals）
本番環境（`main`）へのマージには、最低でも「1人（できれば2人）」のレビュアーの承認（Approval）を必須にしましょう。自分一人で書いて自分でマージする「セルフマージ」は、どれだけ小さな修正であっても原則禁止にすることで、コードの品質とチーム内の知識共有が自然と担保されます。
—
おわりに
GitLabの「Protected Branches」は、単なる機能制限のツールではありません。
「開発者が安心して挑戦でき、チーム全体で高品質なプロダクトを素早くデリバリーするためのセーフティネット」 です。
最初は「制限が多くて面倒だな」と感じるかもしれませんが、この仕組みがあるおかげで、私たちは「金曜日の夕方に安心して本番デリバリーボタンを押し、そのまま清々しい気持ちで週末を迎える」ことができるのです。
ぜひ、あなたのプロジェクトでも今日から設定してみてください。
あなたの開発ライフが、より安全で、より快適なものになることを心から応援しています！