GitHub Organizations & Collaboration d'Équipe

Niveau : Intermediate

Durée : 1h30

Prérequis

Maîtriser les bases de Git (commits, branches, fusions)
Savoir collaborer sur GitHub (Issues, Pull Requests, Code Reviews)

Objectifs d'apprentissage

Comprendre l'architecture d'une GitHub Organization et la différence avec Enterprise
Distinguer Owners vs Members et Outside Collaborators
Créer et structurer des Teams avec permissions en cascade
Maîtriser Read/Triage/Write/Maintain/Admin et les Custom Roles
Configurer Branch Protection vs Rulesets, environnements et audit log

Progression dans cet atelier0%

SlidesPDF PPTX

1. Pourquoi les Organizations ?

Sans org, 50 devs = 50 comptes, 20 dépôts, invitations manuelles → chaos.

Sans org	Avec org
Permissions par dépôt / par personne	Permissions par Team sur N dépôts
Code éparpillé	Centralisé sous `github.com/mon-org`
Pas de 2FA obligatoire	2FA/SAML forcé org-wide
Pas de facturation groupée	Une facture, SSO, audit

<pre dir="ltr" class="mermaid">flowchart TD Org[HashCode Community - Organization] Org --> Repos[Repositories] Org --> Members[Collaborateurs] Org --> Teams[Équipes] Repos --> W[workshops] Repos --> OS[operation-sentinel] Teams --> Eng[Engineering] Teams --> Sec[Security] Teams --> Doc[Documentation]</pre>

2. Membres et Rôles

Owners

Contrôle total : créer/supprimer dépôts, gérer Teams, billing, security.

Members

Collaborent sur les dépôts autorisés, membres de Teams.

Outside Collaborators

Accès dépôt par dépôt (sans passer par une Team) sans être membre de l’org — idéal pour un freelance ponctuel.

Rôle	Facturation	Accès
Owner	Payé	Tout
Member	Payé	Selon Teams
Outside	Gratuit (limite)	1 dépôt

Commandes à exécuter

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$_

3. Gestion des Teams

Une Team = groupe → permissions affectées une fois.

HashCode Community
├── Core Team (Owners)
├── Engineering
│   ├── Frontend
│   └── Backend
├── DevOps
├── Security
├── Documentation
└── Contributors

Cascade : Documentation → Write sur workshops, academy → chaque docs-team member hérite.

Visibilité des Teams :

Visible — listée, membres visibles
Secret — seulement visible par l’org

Création :

gh api orgs/HashCode-Community/teams -f name="Documentation" -f description="Docs" -f privacy="closed"
gh api -X PUT orgs/HashCode-Community/teams/documentation/memberships/aida -f role="member"

Commandes à exécuter

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$_

4. Niveaux de Permissions

Niveau	Droits	Pour qui
`Read`	Voir, cloner, Issues	Contributors externes
`Triage`	+ gérer Issues/labels, close	Mentors / PM
`Write`	+ push branches, PRs	Engineering
`Maintain`	+ settings du repo (sans delete)	Tech Leads
`Admin`	Tout + secrets, delete, rulesets	Core

Custom Roles (Enterprise) : créez Deploy qui peut seulement déployer, pas pousser.

Exemple CODEOWNERS avancé :

*               @HashCode-Community/core-team
*.js           @HashCode-Community/frontend
/deploy/       @HashCode-Community/devops

5. Workflow moderne en équipe

<pre dir="ltr" class="mermaid">flowchart LR Issue[1. Issue] --> Assign[2. Assignation] Assign --> Branch[3. Branche] Branch --> Commit[4. Commits & Push] Commit --> PR[5. Pull Request] PR --> Review[6. Review & Approval] Review --> Merge[7. Merge & Tag]</pre>

Règles :

1 Issue = 1 Assignee
1 PR = 1 auteur + 1–2 reviewers CODEOWNERS
main jamais push direct

6. Branch Protection & Rulesets

Legacy — Branch Protection Rules

Sur main :

Interdire push direct → tout via PR 2. Require approvals (1–2) 3. Require status checks (CI ci.yml verte) 4. Require branches up to date avant merge

gh api repos/HashCode-Community/workshops/branches/main/protection --jq '.required_pull_request_reviews.required_approving_review_count'
# 1

Nouveau — Rulesets (recommandé)

Rulesets = plus fin : s’applique à main, release/*, feature/* avec bypass list.

Feature	Protection Rules (legacy)	Rulesets
Cibles	Une branche	Patron `refs/heads/*`
Bypass	Admin seulement	Liste (bots, Leads)
Historique linéaire	Oui	+ `Require signed commits`

Création via UI : Settings → Rules → New Ruleset → Require linear history + Require approvals + Require status checks (ci) → Bypass : @core.

Commandes à exécuter

bash

# Cliquez sur les commandes à gauche pour les exécuter dans le simulateur

hashcode-academy:~$_

7. Entreprise, environnements & audit

Enterprise vs Organization

Organization = github.com/mon-org (dépôts + teams)
Enterprise = regroupe plusieurs orgs + facturation + SAML/SCIM à l’échelle

SAML SSO & SCIM

SAML → se connecter via Okta/AzureAD, 2FA forcé org-wide
SCIM → provisionner les Teams auto depuis l’IdP (ajout/retrait membre → team mise à jour)

Environnements & secrets

Settings → Environments → production :

Protection : require 1 reviewer + wait 30 min
Secrets : PROD_TOKEN accessible seulement depuis main sur production
Deployment branches : seule main peut déployer

jobs:
  deploy:
    environment: production
    runs-on: ubuntu-latest

Audit log

Toute action est journalisée : qui a ajouté un membre, qui a forcé un push.

gh api orgs/HashCode-Community/audit-log --paginate --jq '.[].action' | head
# team.add_member, repo.create, branch_protection_rule.created

Billing, Projects & Discussions

Facturation

Members facturés (seat) — Settings → Billing.
Outside Collaborators non facturés sur dépôts publics ; consomment un seat sur les dépôts privés.
Enterprise : facture regroupée pour N orgs.

Projects (beta) & Discussions

Projects org-wide : board Kanban multi-dépôts (ex: Roadmap M1→M4).
Discussions : forum org (Q&A, idées) sans polluer les Issues.

gh project create --owner HashCode-Community --title "Roadmap Harmonisation"
gh project item-add 1 --owner HashCode-Community --url https://github.com/HashCode-Community/workshops/issues/19