Organization のオーナーとチームメンテナは、Team に対して、Organization のリポジトリへの管理、読み取り、書き込みアクセスを与えることができます。 Organization のメンバーは、Team 名をメンションすることで、Team 全体に通知を送ることができます。 Organization のメンバーは、Team からのレビューをリクエストすることによっても、Team 全体に通知を送ることができます。 Organization のメンバーは、プルリクエストがオープンされたリポジトリへの読み取りアクセスを持つ特定の Team からのレビューをリクエストできます。 コードの特定の種類や領域に対して Team をオーナーとして CODEOWNERS ファイルで指定できます。
詳しい情報については、以下を参照してください。
また、LDAP Sync を使って GitHub Enterprise Serverのインスタンスの Team メンバーと Team ロールを、既成の LDAP グループと同期させることができます。 そうすることで、GitHub Enterprise Serverのインスタンス内で手動で行う代わりに、LDAP サーバーのユーザのロールベースアクセス制御を確立できます。 詳しい情報についてはLDAP Syncの有効化を参照してください。
Team の可視性
Teamは可視にも秘密にもできます。
- 可視のTeamは、Orgazniationの全メンバーが見て、@メンションできます。
- 秘密のTeamは、Teamの人と、オーナー権限を持つ人だけに見えます。 秘密のTeamは、外部のパートナーやクライアントとの作業に使われるセンシティブな名前やメンバーを持つTeamを隠すのに適しています。 秘密のチームは親チームの下に入れ子にしたり、子チームを持ったりすることはできません。
Team のページ
各 Team は、Organization 内に独自のページを持ちます。 Team のページでは、Team メンバー、子チーム、Team のリポジトリを見ることができます。 Organization のオーナーとチームメンテナは、Team のページから Team の設定にアクセスし、Team の説明とプロフィール画像を更新できます。
Organization のメンバーは、Team 内のディスカッションを作成し、参加できます。 詳しい情報についてはTeam ディスカッションについてを参照してください。
入れ子チーム
GitHub Enterprise Serverの Organization では、複数レベルの入れ子チームでグループや会社の階層を反映させることができます。 親チームは複数の子チームを持つことができます。それぞれの子チームが持つことができる親チームは 1 つだけです。 シークレットチームを入れ子にすることはできません。
子チームは親のアクセス権限を引き継ぐので、大きなグループでの権限管理がシンプルになります。 子チームのメンバーは、親チームが@メンションされた場合にも通知を受けるので、複数グループの人々のコミュニケーションがシンプルになります。
たとえば Team の構造が「従業員 > エンジニアリング > アプリケーションエンジニアリング > アイデンティティ」となっているなら、エンジニアリングにリポジトリへの書き込みアクセスを許可すれば、アプリケーションエンジニアとアイデンティティもそのアクセス権を得ることになります。 アイデンティティ Team あるいは Organization の階層の最下位にある Team に @メンションした場合、それらのチームだけが通知を受けることになります。
親チームの権限とメンションを誰が共有するのかを簡単に知るには、親チームのページの [Members] タブで親チームの子チームのすべてのメンバーを見ることができます。 子チームのメンバーは、親チームの直接のメンバーではありません。
Team を作るときには親を選択できます。あるいは、作成済みの Team を Organization の階層の中で移動させることもできます。 詳しい情報についてはOrganization 階層内での Team の移動を参照してください。
LDAP同期は、最適化設定の一部として、入れ子チームの構造を転送しません。 親子Teamの関係を作りたい場合は、入れ子チームの構造を手動で再作成し、対応するLDAPグループに同期させなければなりません。 詳しい情報については「Teamの作成」を参照してください。
Organization 内で Team を入れ子にする準備
Organization がすでに既存の Team を持っている場合、その Team の上あるいは下に Team を入れ子にする前に、各 Team のリポジトリのアクセス権限を監査しておくべきです。 また、Organization に実装したい新しい構造についても考慮しておくべきです。
Team 階層の最上位では、親チームとその子チームのすべてのメンバーにとって安全なアクセス権限を、親チームのリポジトリに与えるべきです。 階層を下っていくにつれて、より注意が必要なリポジトリへの、より細かいアクセスを、子チームに許可していくことができます。
- 既存の Team からすべてのメンバーを削除する
- 各 Team のリポジトリのアクセス権限を監査して調整し、各 Team に親を与える
- 必要な新しい Team を作成し、それぞれの新 Team の親を選択し、それらにリポジトリのアクセス権を与える
- Team に直接人を追加する