「PRのブランチ保護設定がAzure ReposとGitHubで何が違うか、実際に手を動かして確認したい」
この記事では、Azure ReposとGitHubの違いを7軸で整理し、PRフロー設計においてブランチポリシー/ブランチ保護ルールを実際に構成する手順を解説します。
動作確認環境は Azure CLI 2.61 / GitHub CLI 2.49(Ubuntu 24.04 LTS) です。
この記事のポイント
・Azure Reposはエンタープライズ統合、GitHubはエコシステム連携が強み
・ブランチポリシー(Azure)とブランチ保護ルール(GitHub)は設定項目が異なる
・Azure CLI / GitHub CLI でコマンド一発で保護ルールを適用できる
・同じMicrosoft傘下でも「どこにチームが集まるか」で選択が決まる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Azure ReposとGitHubはどう違うのか——選択で迷う本質的な理由
Azure ReposはMicrosoftのAzure DevOpsスイートに含まれるGitリポジトリサービスです。プロジェクト管理(Azure Boards)・CI/CD(Azure Pipelines)・テスト管理(Azure Test Plans)と同じワークスペースに置け、エンタープライズ向けの細かな権限設計や監査ログが充実しています。GitHubも同じくMicrosoft傘下(2018年買収)ですが、設計思想が大きく異なります。GitHubは「世界中の開発者が集まるプラットフォーム」としてのエコシステムを重視しており、GitHub Marketplace の豊富なActions・OSSコミュニティとの接続性がそのまま武器になります。
「どちらも使えるのになぜ迷う?」——それは、ブランチ保護・PR承認・CI連携の設定粒度と場所が違うからです。Azure Reposでは「ブランチポリシー(Branch Policy)」、GitHubでは「ブランチ保護ルール(Branch Protection Rule)」と呼び名も違います。
7軸で比較:Azure ReposとGitHubの主要な違い
| 比較軸 | Azure Repos | GitHub |
|---|---|---|
| ホスティング場所 | Azure DevOps(組織単位) | GitHub.com または GHES |
| 認証基盤 | Azure AD(Entra ID)連携が標準 | GitHub認証+OIDCでAzure AD連携も可 |
| ブランチ保護名称 | Branch Policy(ブランチポリシー) | Branch Protection Rule(保護ルール) |
| 必須レビュアー | 最低承認数・チームリセット・タイムアウト設定 | Required reviewers・CODEOWNERS |
| CI連携 | Azure Pipelinesとネイティブ統合 | GitHub Actionsが標準。Azure Pipelinesも可 |
| OSSエコシステム | 限定的(外部OSSとの連携は手動設定) | Marketplace経由でActions数万種 |
| 料金 | 最初の5ユーザー無料・以降ユーザー課金 | パブリックリポジトリ無料・プライベートはプランによる |
PRフロー設計の実践:ブランチポリシーとブランチ保護ルールを構成する
ここからは実際にコマンドを動かしながら設定手順を確認します。1. Azure ReposでブランチポリシーをAzure CLIで設定する
Azure CLIにazure-devops 拡張を追加することで、コマンドラインからブランチポリシーを管理できます。事前準備(Azure CLI + DevOps 拡張インストール)
# Azure CLIがない場合はまずインストール curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash # DevOps拡張を追加 az extension add --name azure-devops # ログイン(ブラウザが開く) az login # デフォルト組織・プロジェクトを設定(繰り返し入力を省く) az devops configure --defaults organization=https://dev.azure.com/YOURORG project=YOURPROJECT
# リポジトリIDを確認 az repos list --output table # 出力例: # Id Name DefaultBranch # ------------------------------------ --------- ------------- # a1b2c3d4-e5f6-7890-abcd-ef1234567890 myrepo main # mainブランチに「最低1名の承認」ポリシーを有効化 az repos policy approver-count create --repository-id a1b2c3d4-e5f6-7890-abcd-ef1234567890 --branch main --blocking true --enabled true --minimum-approver-count 1 --reset-on-source-push true --allow-downvotes false # 出力例(抜粋): # { # "id": 101, # "isEnabled": true, # "isBlocking": true, # "settings": { # "minimumApproverCount": 1, # "resetOnSourcePush": true # } # }
--blocking true を付けると、条件を満たさないPRはマージできないハードブロックになります。--blocking false は警告のみの「ソフト」ポリシーです。ビルド検証ポリシー(CIパスを必須化)を追加する
# Azure PipelinesのビルドIDを確認 az pipelines list --output table # 出力例: # Id Name Status # ---- ---------------- -------- # 42 ci-unit-test enabled # mainへのPRにCIビルド通過を必須化 az repos policy build create --repository-id a1b2c3d4-e5f6-7890-abcd-ef1234567890 --branch main --blocking true --enabled true --build-definition-id 42 --valid-duration 720 --queue-on-source-update true
--valid-duration 720 はビルド結果の有効期限(分)です。720分(12時間)以上前のビルド結果は再実行が必要になります。2. GitHubのブランチ保護ルールをGitHub CLIで設定する
GitHub CLIが入っていない場合はインストールします。# GitHub CLIインストール(Ubuntu/Debian) sudo apt install gh # 認証 gh auth login # mainブランチに保護ルールを適用(API経由) gh api --method PUT -H "Accept: application/vnd.github+json" /repos/OWNER/REPO/branches/main/protection --input - << 'EOF' { "required_status_checks": { "strict": true, "contexts": ["ci / unit-test"] }, "enforce_admins": true, "required_pull_request_reviews": { "required_approving_review_count": 1, "dismiss_stale_reviews": true }, "restrictions": null } EOF # 成功すると設定後のJSONが返る(抜粋): # { # "url": "https://api.github.com/repos/OWNER/REPO/branches/main/protection", # "required_status_checks": { # "strict": true, # "contexts": ["ci / unit-test"] # } # }
"strict": true を指定するとマージ前にmainの最新をブランチに取り込むことが必須になります(「ブランチを最新に保つ」相当)。3. PRテンプレートと必須レビュアーの組み合わせ
PRテンプレートは両サービスで対応していますが、配置場所が異なります。・Azure Repos:リポジトリルートに
pull_request_template.md を置く(または .azuredevops/ ディレクトリ内)・GitHub:
.github/pull_request_template.md または .github/PULL_REQUEST_TEMPLATE/ 配下に複数テンプレートを格納CODEOWNERSによる自動レビュアー割り当ては GitHubのみのネイティブ機能です。Azure Reposで同等の動作を実現するには、ブランチポリシーの「自動的にレビュアーを含める」でチームを指定します。
# GitHub: .github/CODEOWNERS の例 # src/以下の変更はbackendチームのレビューが必須 /src/ @myorg/backend-team # infra/以下はインフラチーム /infra/ @myorg/infra-team
Azure PipelinesとGitHub Actionsの連携パターン
現場でよくある構成が「リポジトリはGitHub、CIはAzure Pipelines」という組み合わせです。GitHubのWebhookをAzure Pipelinesが受け取れるため、リポジトリをGitHubに置きつつAzureの強力なエージェントプール(スポットVM・スケールセット)を活用できます。逆に「Azure Repos+GitHub Actions」の構成は、Azure DevOpsがGitHub Actionsのトリガーを受け付けないため現実的ではありません。GitリポジトリをGitHubにミラーリングする回避策もありますが、管理コストが増えるため非推奨です。
Azureを中心に技術スタックを組み立てている場合は、Azure LinuxMaster で体系的なハンズオン学習も参考にしてみてください。
トラブルシュート:よくあるエラーと対処法
1. az repos policy コマンドで「DevOps extension not installed」
az extension add --name azure-devops を実行していないか、バージョンが古い場合に発生します。# 現在のバージョンを確認 az version | grep azure-devops # 更新 az extension update --name azure-devops
2. ブランチ保護ルール適用後もマージできてしまう(GitHub)
"enforce_admins": false のままだと、管理者権限を持つユーザーはルールをバイパスできます。セキュリティポリシー上問題がある場合は true に変更してください。3. Azure Reposのポリシーが反映されない(PRを作り直しても)
ポリシーを追加・変更した場合、既存の開いているPRには自動で再評価が走りません。PRページで「ポリシーを再評価(Re-evaluate policy)」を手動でクリックするか、ソースブランチに空のコミットをプッシュして再トリガーしてください。4. GitHub ActionsのCI名とブランチ保護の「contexts」が一致しない
gh api で指定した "contexts" の文字列は、GitHub Actionsのジョブ名(jobs.<job_id>.name または jobs.<job_id> そのもの)と完全一致が必要です。# .github/workflows/ci.yml のジョブ定義例 jobs: unit-test: name: "ci / unit-test" runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: make test # ブランチ保護で指定する contexts の文字列: # "ci / unit-test" ← name: で指定した文字列
本記事のまとめ
| やりたいこと | Azure Repos | GitHub |
|---|---|---|
| ブランチ保護をCLIで設定 | az repos policy approver-count create |
gh api PUT /branches/main/protection |
| CIパスを必須化 | az repos policy build create |
protection の required_status_checks |
| 自動レビュアー割り当て | ブランチポリシーでチーム指定 | CODEOWNERS ファイル |
| PRテンプレート配置 | リポジトリルート or .azuredevops/ | .github/pull_request_template.md |
| CI基盤との相性 | Azure Pipelinesと深く統合 | GitHub Actionsが標準(Marketplaceが豊富) |
・GitHubはOSSコミュニティ・GitHub Actions Marketplace・CODEOWNERSの柔軟性に強い
・ブランチ保護はAzure CLIまたはGitHub CLI・GitHub APIでコード化(IaC化)しておくと環境再現が容易になる
>> Azure LinuxMaster の詳細を見る
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:Azure CLIとPowerShellの違いをVM構築で比較|az vmとNew-AzVMを使い分ける実践
- この記事の属するカテゴリ:Azureへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます