GitLab/GitHub 二刀流エンジニアを目指す - GitHub の設定、GitLab だとどうする?ブランチ保護・CI/CD・シークレット管理まわりの対応表

Last updated at 2026-08-08Posted at 2026-08-06

GitHub の設定、GitLab だとどうする?ブランチ保護・CI/CD・シークレット管理まわりの対応表

はじめに

GitHub から GitLab に移行したり、両方を並行して運用していると、「この GitHub の設定、GitLab では何に対応するんだっけ?」と迷う場面が結構あります。

厄介なのは、GitHub 側は個別のトグル一つで表現される設定が多いのに対し、GitLab では Protected branches、Merge request approvals、CI/CD variables、Protected environments など、複数機能の組み合わせで同じ統制を作ることが多い点です。

この記事では、GitHub でよく使う設定を GitLab の考え方に置き換えて整理します。1:1 対応ではなく「近い統制をどう組み立てるか」という視点でまとめています。

対応表

リリース・ブランチ関連

GitHub の設定	GitLab で近いことをするには	設定手順	注意点
Enable release immutability	1:1 の同名トグルはない。Protected tags でリリース基点タグの作成権限を絞るのが近い統制	リリース用タグの命名を `v*` のように寄せ、Protected tags を設定	下記の warn 参照
Automatically delete head branches	MR マージ後の source branch 自動削除	Settings > Merge requests で既定動作を有効化(MR ごとの個別選択も可)	GitLab では MR 作成時・マージ時の設定として使うイメージです
Require a pull request before merging	Protected branches で直接 push を抑止し、MR 経由に寄せる	Settings > Repository > Branch rules で `Allowed to push and merge` を `No one` に、必要に応じて `Allowed to merge` も限定して設定	GitHub の「PR 必須」に完全一致する単一トグルではなく、Protected branches と MR 運用の組み合わせ。`Allowed to push and merge` を明示的に絞らないと、直接 push 抑止としては不十分

Enable release immutability の注意点
GitHub の immutable releases は release asset の変更・削除不可、関連 Git tag の移動・削除不可、release attestation の自動生成まで含みます。GitLab の Protected tags は近い統制ですが、同等の不変性そのものではありません。また GitLab の immutable tags は Container Registry 向けの別機能なので、Git リポジトリの release とは無関係です。

承認・パイプライン関連

GitHub の設定	GitLab で近いことをするには	設定手順	注意点
Required approvals	Merge request approvals + approval rules	Branch rules の詳細から承認者・必要承認数をブランチごとに設定	保護対象ブランチに承認ルールを持たせる考え方。より強い統制が必要なら、author 自己承認禁止や commit 追加時の再承認要求も検討対象
Require status checks to pass	Pipelines must succeed	Settings > Merge requests で有効化。`.gitlab-ci.yml` 側で MR pipeline も有効化しておく	下記の warn 参照

Require status checks to pass の注意点
Pipelines must succeed は、パイプラインが存在しない MR もブロックします。branch pipeline と merge request pipeline の両方が存在する場合、判定対象は merge request pipeline 側 です。MR pipeline を機能させるには、.gitlab-ci.yml に以下のような rules(または workflow)が必要です。

rules:
  - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

include 先だけに書かれたルールでは不十分なので注意してください。

サプライチェーン・変数関連

GitHub の設定	GitLab で近いことをするには	設定手順	注意点
Require actions to be pinned to a full-length commit SHA	CI/CD component や include 参照を commit SHA / 固定 version tag で pin する	UI トグルではなく `.gitlab-ci.yml` の書き方。外部の CI 設定や component を参照する際は `branch` や `latest` のような可変参照を避け、固定参照にする。必要に応じて `include:integrity` も使う	GitHub Actions の third-party action pinning と同じ文脈。GitLab でも外部参照は moving target を避けるのが基本
Variables	CI/CD variables	Settings > CI/CD > Variables で project / group / instance 単位に追加。Protect variable、Masked、Environment scope、File type を必要に応じて設定	環境ごとに値を切り替えたい場合は Environment scope を使う
Secrets	日常運用では Masked / Protected CI/CD variables。厳格に管理したい場合は secrets manager や外部 secret provider 連携	簡便運用なら variables に Masked + Protected を付与。厳密な分離が必要なら external secret provider を設計	GitHub Secrets と「機密値を外から注入する」目的は近いが、GitLab では variables と secrets 管理を分けて考える方が正確

Protected variable は protected branches / protected tags の pipeline にだけ渡されます。Merge Request pipeline から protected resource にアクセスできるかどうかは条件付きです。Masked はログ露出抑止として有効ですが、それ自体が万能な秘密管理というわけではありません。

環境・デプロイ関連

GitHub の設定	GitLab で近いことをするには	設定手順	注意点
Environment	Environments + environment-scoped variables + Protected environments + Deployment approvals	`.gitlab-ci.yml` の deploy job に `environment:` を定義。環境ごとの値は Variables の Environment scope で切り分け。本番は Protected environments で Allowed to deploy や承認ルールを設定	GitHub Environment の「環境変数の切り替え」と「本番承認」は、GitLab では1機能ではなく複数機能の組み合わせ(下記 warn も参照)
Require deployments to succeed before merging	1:1 の単一トグルはない。Pipelines must succeed + deploy/verify job + Protected environments + Deployment approvals の組み合わせ	Pipelines must succeed の設定と、対象 environment への Protected environments / Deployment approvals の設定を組み合わせて構成	GitHub のように「特定 environment への deploy 成功」を merge 条件としてそのまま表す機能はなく、GitLab ではパイプライン設計と環境保護の組み合わせで実現する形
Production secrets protection	Protected variables + environment scope(+ protected runners)	本番用の CI/CD variables を Protected 設定にし、Environment scope で本番環境に限定	本番 secret は protected branch / protected tag 側にだけ出す設計が基本。GitLab でも production secrets は Protected variables と Protected environments の併用が推奨される

Deployment approvals の注意点
承認後にそのまま自動実行されるわけではなく、承認後も手動実行が必要です。GitHub の Environment protection rules と同じ感覚で「承認 = 自動デプロイ開始」と考えていると詰まるポイントです。

実務上のまとめ

GitHub の設定名を GitLab にそのまま 1:1 で対応づけようとすると無理が出ます。GitLab 側は次の5つの軸の組み合わせで考えると整理しやすいです。

ブランチ保護(Protected branches)
MR 承認(Merge request approvals)
パイプライン成功(Pipelines must succeed)
変数保護(Protected variables / Environment scope)
環境保護(Protected environments / Deployment approvals)

サプライチェーン対策の観点では、特に次の3点を押さえておくと説明しやすいです。

外部 CI 設定や component は SHA / 固定 version で pin する
本番資格情報は Protected variables + Environment scope で分ける
本番デプロイは Protected environments + Deployment approvals で統制する

注意事項まとめ

Enable release immutability は GitLab に同名対応するトグルがない。Protected tags は近い統制だが、release asset や関連 Git tag の完全な不変性までは保証しない
GitHub の immutable releases では release artifact への attestation が自動生成される
GitHub の immutable releases は、リポジトリを削除して同名で作り直しても、使用済みタグ名は再利用できない
GitHub の immutable releases は有効化後に新規作成された release にのみ適用され、既存 release は mutable のまま。無効化後も、既に immutable になった release はそのまま
GitLab の Pipelines must succeed はパイプラインが存在しない MR もマージ不可にする。branch pipeline と merge request pipeline が両方ある場合、判定対象は merge request pipeline 側
MR pipeline を前提にする場合、.gitlab-ci.yml に merge_request_event を対象にした rules/workflow が必須(include 先だけでは不足)
Protected variable は protected branches / protected tags の pipeline にだけ渡される。Merge Request pipeline で protected resource にアクセスできるのは条件付き
Deployment approvals は承認後も手動実行が必要(自動実行ではない)

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up