リポジトリの可視性、ルール、設定を管理する
リポジトリはアプリケーション ソース コードとその他のファイルをホストし、開発者がソフトウェアを作成するコアの構造です。リポジトリは、アプリケーション セキュリティ メトリック、CI/CD ワークフロー、その他の日常的なアクティビティにアクセスするのに使用されます。Enterprise レベルと Organization レベルでの制御とアクセス許可があり、リポジトリには、問題の追跡、変更の提案、コード レビューを管理する制御が用意されています。
Philips にとって、デフォルトのリポジトリの可視性を設定することは、コラボレーションとインナーソースを促進する戦略の中核でした。
このガイドの学習内容
GitHub のリポジトリで利用可能なユーザー モデルの可視性の種類
ルールセットを使用してプル リクエストをマージする条件を定義する方法
リポジトリ レベルの設定を使用して Organization レベルや Enterprise レベルの制限を超えたきめ細かな制御を行う方法
リポジトリの可視性
リポジトリには、パブリック、インターナル、プライベートの 3 種類の可視性があります。
パブリック リポジトリは世界中に公開されるもので、主にオープン ソース コンテンツに使用されます。
インターナル リポジトリは、Enterprise アカウントの全メンバーが読み取り可能です (外部コラボレーターは読み取り不可)。
プライベート リポジトリは、Enterprise や Organization の基本レベルの権限など、明確なアクセス権限を与えられた個人またはチームのみが閲覧できます。
管理者は、可視性に関係なく、Enterprise や Organization 内の全てのリポジトリを表示できます。また、リポジトリの可視性設定を変更することもできます。ただしリポジトリ管理者は、明示的なポリシーで許可されていない限り、リポジトリの可視性設定を変更できません。
注意: リポジトリの可視性を変更すると、フォークやその他の機能を使用している場合、下流への影響が発生することがあります。変更を行う前に、リポジトリの可視性の変更による影響を確認してください。
Enterprise Managed Users (EMU) を使用している Enterprise では、パブリック リポジトリを作成したり、既存のリポジトリの可視性をパブリックに変更したりできません。
主要な GitHub Organization では、再利用するコードを発見しやすくしてインナーソースを促進するために、リポジトリのデフォルトの可視性をインターナルに設定しました。 もちろん、リポジトリを全てのメンバーに公開することが好ましくないケースもあります。そのため、リポジトリをプライベートに設定することを許可していますが、その場合は最初に例外を申請する必要があります。
ルールセットとプル リクエストのマージ設定制御
ルールセットとは、特に、ポリシーを定義し、プル リクエストをマージするユーザー、タイミング、方法、条件を制御するルールのグループです。ルールセットは、リポジトリごと、リポジトリ セットごと、または Organization 全体で定義できます。一度に複数のルールセットを適用でき、この複数のルールセットはルールの階層化を使用して評価されます。マージ可能な条件が設定されている場合、ユーザーがリポジトリへの書き込みアクセス権限を持っているだけでは十分ではありません。プル リクエストをマージしてコード ベースの一部にするには、マージ設定制御の条件を全て満たす必要があります。
ルールセットがチェックできる条件の例は以下のとおりです。
リポジトリへの読み取りアクセス権を持つユーザーなら誰でも、そのリポジトリにどのルールセットがアクティブに適用されているかをいつでも確認できます。そのため、追加のアクセス権が与えられていなくても、リポジトリの制約ステータスをチェックし、変更が要求された場合にどのような制約が適用されるかを知ることができます。
ルールは作成時に「評価」ステータスに設定でき、ルールを使い始める前に適用方法を確認できます。ルールの分析情報ページでは、評価モードのルールがどのユーザー アクションに影響するかを確認できます。
GitHub を使ったことがある人なら、ブランチ保護ルールについても馴染みがあるかもしれません。ブランチ保護ルールは、マージ設定制御を行うための伝統的な手法です。既存のブランチ保護ルールをルールセットと組み合わせることもできますが、ルールセットのほうがより柔軟で機能的であり、今後の GitHub のマージ設定制御の方法として推奨されます。
当社では GitHub Actions を使用して、全てのリポジトリにオーナーや権限レベルなどの特性を指定する YAML ファイルがあるかどうかを確認するボットを作成しました。 このファイルがない場合は、ボットが自動的に問題を作成してチームに作成を依頼します。そのおかげで、デフォルトでチームがブロックされるのではなく、インナーソースを利用できるようになりました。
リポジトリ設定
Actions ポリシー、セキュリティ機能の有効化とポリシー、フォーク設定など、Enterprise レベルや Organization レベルで見たのと同じ設定のいくつかが、個々のリポジトリ レベルでも利用できます。また、リポジトリごとに問題、GitHub Discussions、レガシー (「クラシック」) プロジェクトなどの機能を有効にしたり無効にしたりすることもできます。この方法は、機能のロールアウト時やコンテンツのアーカイブ時など、特定のリポジトリの使用を制限したい場合に便利です。
リポジトリ レベルの設定では、Enterprise や Organization のポリシーや設定よりも制限を厳しく設定する必要があります。たとえば、Enterprise や Organization のポリシーでフォークを許可しないように設定されている場合、リポジトリごとのフォークを許可することはできません。ただし、Enterprise や Organization のポリシーが任意のアクションの使用を許可している場合は、リポジトリごとのポリシーを設定して、そのリポジトリで許可されるアクションが指定されたリストのみを使用するよう許可できます。
次の項目: チーム、ロール、ユーザーを使用して、リポジトリ アクセスを管理する
これで、Enterprise、Organization、リポジトリ レベルで基本的な設定の大半を設定できました。次はチームとユーザーのロールを使用して、アクセスを細分化し、きめ細かい企業構造を再作成します。