# GitHub organization и teams

_Совместная работа · GitLab Knowledge Base_

**TL;DR:** Organization - контейнер для нескольких пользователей и
репозиториев с общим биллингом, настройками безопасности и
teams. Team - именованная группа пользователей внутри
организации для batch-выдачи доступов. Пользователь может быть
членом многих org одновременно.


GitHub поддерживает два типа владельцев репо: **пользователь** и
**organization**.

Пользователь - персональный аккаунт. Его профиль публичный
(`github.com/username`), у него свои SSH-ключи, токены, биллинг.

Organization (org) - аналог компании на GitHub. У организации
свой биллинг, свои репозитории, свои настройки безопасности.
Несколько пользователей могут быть её членами. Один пользователь -
членом многих org одновременно (нормально для opensource-
контрибьюторов, работающих в нескольких компаниях/проектах).

## Roles внутри org

- **Owner** - полные права. Может удалить org, поменять
  биллинг, переименовать.
- **Member** - доступ к репо по правилам permission. По
  умолчанию member-роль не даёт write на все репо org -только на
  те, где явно дан грант.
- **Outside collaborator** - не член org, но имеет доступ к
  конкретному репо. Часто это подрядчики или внешние авторы.
- **Billing manager** - только биллинг, без репо-доступов.

## Teams

Team - именованная группа пользователей. Например, в org `acme`
есть teams `backend`, `frontend`, `devops`. Зачем team:

- Выдать доступ к набору репо одним кликом, а не каждому
  пользователю отдельно.
- Использовать в [codeowners](/courses/git/kb/codeowners.md): `@acme/backend` назначается
  автоматически на PR'ы по путям, привязанным к этой team.
- Mention в комментариях: `@acme/backend` пишет всем членам
  team.
- Slack/email-нотификации по team.

Teams могут быть вложенными: `backend/database` наследует
permissions и members от `backend`. Это удобно для больших
организаций.

## Permissions на репо

Доступ к репо организации может быть выдан тремя способами:

1. **Через team membership** - team имеет доступ, ты в team.
2. **Прямой grant** - пользователь добавлен в репо персонально.
3. **Outside collaborator** - не член org, но добавлен в репо.

Когда удаляешь кого-то, не забудь все три. Убрать только из team
часто недостаточно -прямой grant остаётся. Это типовая ошибка
при ротации сотрудников.

## Personal settings vs org settings

Чёткое разделение:

- **SSH-ключи, токены, email, 2FA** - на уровне пользователя, в
  `github.com/settings`.
- **Биллинг org, default permissions, SAML/SSO, audit log** - на
  уровне организации, в `github.com/organizations/acme/settings`.
- **Settings конкретного репо** - в `github.com/acme/web/settings`.

Кoгда не можешь найти настройку -подумай, к чему она относится по
scope, и иди на соответствующий уровень.

## SSO и enterprise

В больших организациях включают SAML SSO. Тогда:

- Каждый член org должен пройти SSO для GitHub-аккаунта.
- PAT'ы (personal access tokens) должны быть SSO-авторизованы.
- Push с тех машин, где SSO не пройден, отказывается.

Это сильная защита, но создаёт UX-неудобства. Если ты ушёл из
компании, SSO-attestation автоматически отзывается, твой ключ
перестаёт работать с приватными репо org.


## Команды

```bash
gh api user/orgs
```
Список org, в которых ты member

```bash
gh api orgs/acme/teams
```
Все teams в org acme (с правами read)


## См. также

- [Branch protection rules](/courses/git/kb/branch-protection.md)
- [CODEOWNERS](/courses/git/kb/codeowners.md)
- [GitHub notifications](/courses/git/kb/notifications.md)