Git リポジトリのアクセス許可を設定する

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022

Git リポジトリにアクセスできるユーザーと、実行できるアクションを管理します。 すべてのリポジトリ レベルでアクセス許可を設定して、プロジェクト内のすべての Git リポジトリに適用するか、個々のリポジトリのアクセス許可を設定します。個々のリポジトリは、プロジェクトレベルの Git リポジトリエントリからアクセス許可を継承します。

Note

ブランチは、リポジトリレベルで行われた割り当てからアクセス許可のサブセットを継承します。ブランチのアクセス許可とポリシーについては、「ブランチアクセス許可の設定」およびブランチポリシーを使用したコード品質の向上に関する記事を参照してください。

リポジトリのアクセス許可、ブランチポリシー、コミット署名、および実際の実装シナリオに関する包括的なセキュリティガイドについては、リポジトリとプル要求のセキュリティ保護に関するセクションを参照してください。

より高いアクセス許可レベルを提供するユーザーに関するガイダンスについては、「アクセス許可を使用したアクセスの管理」を参照してください。

前提条件

カテゴリ	Requirements
プロジェクトアクセス権	Azure DevOps プロジェクトのメンバーシップ。
アクセス許可	プロジェクトレベルの Git リポジトリエントリのアクセス許可を管理してプロジェクト内のすべてのリポジトリを管理するか、または個々のリポジトリのアクセス許可を管理してそのリポジトリを管理します。 Project Administrators グループのメンバーには、既定でこのアクセス許可があります。詳細については、アクセス許可とグループのリファレンスに関するページを参照してください。
サービス	有効Azure Repos。

既定のリポジトリのアクセス許可を確認する

既定では、プロジェクトの共同作成者グループのメンバーには、リポジトリに投稿するためのアクセス許可があります。このアクセス許可レベルには、ブランチの作成、タグの作成、ノートの管理を行う機能が含まれます。各セキュリティグループとアクセス許可レベルの詳細については、アクセス許可とグループリファレンスに関する記事を参照してください。

権限

Readers

寄稿者

ビルド管理者

プロジェクト管理者

読み取り (リポジトリの内容の複製、フェッチ、検索) も可能で、さらに pull request の作成、コメント、投票、および貢献もできます。

✔️

投稿、 ブランチの作成、 タグの作成、 ノートの管理

✔️

リポジトリの作成、リポジトリの削除、リポジトリの名前変更

✔️

ポリシーの編集、アクセス許可の管理、他のユーザーのロックの削除

✔️

プルリクエスト完了時にポリシーをバイパス、プッシュ時にポリシーをバイパス、強制プッシュ（履歴の書き換え、ブランチとタグの削除）
(どのセキュリティグループにも設定されていません)

Azure DevOpsスプリント 224 以降、ブランチ作成者はポリシーの編集アクセス許可を自動的に取得しません。このアクセス許可は、リポジトリの アクセス許可管理 設定がオンになっている場合でも付与されません。継承、グループメンバーシップ、または直接割り当てを通じて、 編集ポリシー を明示的に付与します。

Azure DevOps Server 2022.1 以降では、ブランチ作成者はポリシーの編集アクセス許可を自動的に取得しません。このアクセス許可は、リポジトリの アクセス許可管理 設定がオンになっている場合でも付与されません。継承、グループメンバーシップ、または直接割り当てを通じて、 編集ポリシー を明示的に付与します。詳細については、Azure DevOps Server 2022 Update 1 のリリースノートを参照してください。

アクセス許可の状態を理解する

アクセス許可を変更する前に、アクセス許可の状態Azure DevOps評価する方法を確認します。

[設定しない ] では、アクセス許可は付与または拒否されません。別のグループを介して割り当てられたアクセス許可、または親スコープから継承されたアクセス許可は引き続き適用できます。
許可は、より具体的または適用可能な Deny によってオーバーライドされない限り、アクセス許可を付与します。
通常、[拒否 ] は、別のグループを介して継承または付与されたアクセス許可を含め、許可をオーバーライドします。グループのアクセス許可を拒否すると、拒否はそのグループのすべてのメンバーに影響します。

Deny を割り当てる前に、グループメンバーシップと継承されたアクセス許可を確認します。詳細については、「権限とグループについて」を参照してください。

リポジトリのセキュリティを開く

Project設定>Repositories から Git リポジトリのアクセス許可を設定します。

Web ポータルを開き、ユーザーまたはグループを追加するプロジェクトを選択します。別のプロジェクトを選択するには、「プロジェクト、リポジトリ、チームの切り替え」を参照してください。
プロジェクト設定>Repositories を選択します。
プロジェクト内のすべての Git リポジトリのアクセス許可を設定するには、すべてのリポジトリ>Security を選択します。
特定のリポジトリのアクセス許可を設定するには、リポジトリを選択し、[ セキュリティ] を選択します。

Project設定>Repositories から Git リポジトリのアクセス許可を設定します。

Web ポータルを開き、アクセス許可を管理するプロジェクトを選択します。別のプロジェクトを選択するには、「プロジェクト、リポジトリ、チームの切り替え」を参照してください。
プロジェクト設定>Repositories を選択します。
プロジェクト内のすべての Git リポジトリのアクセス許可を設定するには、 Git リポジトリを選択し、管理するアクセス許可を持つユーザーまたはセキュリティグループを選択します。

画像全体を表示するには、画像をクリックして拡大します。閉じるアイコンを選択して閉じます。

それ以外の場合は、特定のリポジトリを選択し、管理するアクセス許可を持つユーザーまたはセキュリティグループを選択します。
アクセス許可を変更し、[ 変更の保存] を選択します。
変更された各アクセス許可が新しい状態を保持していることを確認します。

グループのアクセス許可を変更する

カスタムセキュリティグループのアクセス許可を設定するには、最初にグループを定義します。詳細については、「プロジェクトレベルの権限の変更」を参照してください。

アクセス許可を設定するグループを選択します。たとえば、[ 共同作成者] を選択します。
1 つ以上のアクセス許可を変更します。アクセス許可を付与するには、[ 許可] を選択します。明示的な割り当てを削除し、継承またはグループのアクセス許可を使用するには、[ 未設定] を選択します。該当する許可をオーバーライドする必要がある場合にのみ、[ 拒否 ] を選択 します。

アクセス許可の変更が自動的に保存されます。変更された各アクセス許可に目的の状態が表示されることを確認します。

ユーザーのアクセス許可を変更する

検索フィルターにユーザーの名前を入力し、特定のユーザーのアクセス許可を設定するように表示される ID から選択します。
選択したユーザーの 1 つ以上のアクセス許可を変更します。

Note

ユーザーをセキュリティグループまたはプロジェクトチームに追加することによって、ユーザーがプロジェクトに追加されていない場合は、アクセス許可ページまたは ID フィールドからユーザーを見つけることができない場合があります。また、ユーザーが Microsoft Entra ID または Active Directory に追加されると、プロジェクトに追加されてから ID フィールドから検索できるようになるまでの間に遅延が発生する可能性があります。遅延は 5 分から 7 日かかる場合があります。

アクセス許可の変更は、選択したユーザーに対して自動的に保存されます。変更された各アクセス許可に目的の状態が表示されることを確認します。

ユーザーまたはグループを追加し、そのユーザーまたはグループのアクセス許可を変更しない場合があります。アクセス許可ページが更新されると、ユーザーまたはグループは表示されなくなります。

リポジトリの継承を構成する

継承を変更する前に、現在の設定を記録し、リポジトリの明示的なアクセス許可と継承されたアクセス許可を確認します。継承を無効にすると、プロジェクトレベルの Git リポジトリエントリからのアクセス許可がリポジトリにフローされなくなります。続行する前に、残りの割り当てによって目的のアクセス権が提供されることを確認します。

特定のリポジトリの継承を有効または無効にするには、リポジトリを選択し、[継承] を [オン] または [オフ] に設定します。

特定のリポジトリの継承の有効化または無効化を示すスクリーンショット。

継承を変更した後、影響を受ける代表者のユーザーと共にリポジトリのアクセス許可の割り当てを確認します。結果が正しくない場合は、前の設定とアクセス許可の状態を復元します。継承の詳細については、「権限とグループについて」を参照してください。

ポリシーバイパスのアクセス許可を構成する

ブランチポリシーをバイパスする必要があるシナリオは多くあります。たとえば、ビルドの中断の原因となった変更を元に戻したり、深夜に修正プログラムを適用したりする場合があります。

以前は、 ポリシー適用の除外 アクセス許可は、チームがプル要求を完了したときにブランチポリシーをバイパスする機能を付与されたユーザーを管理するのに役立ちました。ただし、そのアクセス許可により、ユーザーはブランチに直接プッシュし、PR プロセスを完全にバイパスする権限も付与されました。

次の 2 つのアクセス許可は 、ポリシー適用の除外 を置き換え、より詳細な制御を提供します。

プル要求を完了するときにポリシーをバイパスする: このアクセス許可を持つユーザーは、プル要求のオーバーライドエクスペリエンスを使用できます。
プッシュ時にポリシーをバイパスする: このアクセス許可を持つユーザーは、構成されている必要なポリシーを持つブランチに直接プッシュできます。

ユーザーがプル要求を完了したときにのみポリシーをバイパスできるようにするには、プル要求の 完了時にバイパスポリシーを[許可] に設定します。ユーザーが別の割り当てを通じて許可を受け取らない場合は、[未設定] としてプッシュする場合は、[バイパスポリシー] のままにします。該当する許可をオーバーライドする必要がある場合にのみ、[ 拒否 ] に設定 します。

Note

以前にポリシー 適用除外 を [許可] に設定したユーザーは、両方の置換アクセス許可に対して許可を受け取りました。これらの割り当てを確認し、ユーザーが保護されたブランチに直接プッシュする必要がなく、他の割り当てでアクセス許可が付与されない場合は、[未設定] にプッシュするときにバイパスポリシーを設定します。

アクセス許可の変更のトラブルシューティング

アクセス許可の変更で期待される結果が得られない場合は、次のガイダンスを使用します。

問題	Resolution
アクセス許可を変更することはできません	プロジェクトレベルの Git リポジトリエントリまたは選択したリポジトリで管理アクセス許可があることを確認します。
ユーザーまたはグループが検索に表示されない	チームまたはセキュリティグループを使用してプロジェクトに ID を追加します。 ID の変更が検索に表示されるまでに時間がかかる場合があります。
許可でアクセスが許可されない	該当する Deny について、ユーザーのグループメンバーシップとより具体的なスコープを確認します。
アクセス許可が間違ったリポジトリに影響する	すべてのリポジトリまたは個々のリポジトリを変更したかどうかを確認します。
[未設定] を選択した後にアクセス許可が返される	アクセス許可が継承されているか、別のグループを通じて付与されているかを確認します。
継承を無効にすると、アクセスが削除されます	変更前に記録した以前の継承設定または明示的なアクセス許可の割り当てを復元します。

問題を解決したら、影響を受ける担当者に、目的のリポジトリアクションを確認させます。

ヒント

AI を使用して、Azure DevOps タスクに役立てることができます。作業を開始するには、 Azure DevOps MCP Server で AI サポートを有効にする方法に関するページを参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-14