Azure ReposとGitHubの違いをPRフロー設計で比較|DevOpsでブランチ保護を構成する

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Azure > Azure ReposとGitHubの違いをPRフロー設計で比較|DevOpsでブランチ保護を構成する
「Azure DevOpsでリポジトリをAzure ReposにするかGitHubにするか、チームで議論になっている」
「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傘下でも「どこにチームが集まるか」で選択が決まる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

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

mainブランチに「最低1名の承認必須」ポリシーを適用する

# リポジトリ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が豊富)
・Azure Reposはエンタープライズ環境・Azure AD統合・Pipelinesとの連携に強い
・GitHubはOSSコミュニティ・GitHub Actions Marketplace・CODEOWNERSの柔軟性に強い
・ブランチ保護はAzure CLIまたはGitHub CLI・GitHub APIでコード化(IaC化)しておくと環境再現が容易になる
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、Azure環境でのLinux運用を含む実践的なカリキュラムを提供しています。
>> Azure LinuxMaster の詳細を見る

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。