Gestion de Projet GitHub

Git n’est pas GitHub

Git versionne le code. GitHub organise le travail d’une équipe.

Git	GitHub
Fichiers	Issues
Historique	Projects
Branches	Reviews
Commits	Releases

Les deux sont complémentaires. Git est l’outil, GitHub est le chantier.

Partie 1 — Les Issues

Une Issue représente une tâche, un bug, une amélioration, une idée ou une demande. C’est l’unité fondamentale de travail dans GitHub.

Cycle de vie d’une Issue

Ouverte → En cours → En revue → Terminée

Pourquoi utiliser des Issues ?

Sans Issues, on oublie. Avec Issues, tout est documenté, tracé, et priorisé.

Bonnes pratiques

Une Issue doit contenir :

un titre clair et explicite ;
une description détaillée ;
un objectif mesurable ;
des critères de réussite.

Exemple

Titre : Créer la page de connexion

Description : Créer une page de connexion avec email et mot de passe.

Critères de réussite :

Champ email avec validation
Champ mot de passe avec masquage
Bouton de soumission
Design responsive

Créer une Issue avec GitHub CLI

gh issue create \
  --title "Créer la page de connexion" \
  --body "Description et critères de réussite..." \
  --label enhancement

Partie 2 — Les Labels

Les Labels permettent de catégoriser les Issues pour mieux les filtrer, les rechercher et les prioriser.

Labels courants

bug — Problème dans le code existant enhancement — Nouvelle fonctionnalité documentation — Travail sur la doc security — Problème de sécurité good first issue — Idéal pour les débutants question — Demande d’information frontend — Travail côté interface backend — Travail côté serveur

Pourquoi les Labels sont-ils utiles ?

Imaginez 200 Issues. Comment trouver uniquement les bugs ? Les Labels résolvent ce problème.

# Lister les Issues avec un label spécifique
gh issue list --label bug

# Créer un label
gh label create frontend --color 5319e7

Exemple

Issue : Créer la page de connexion

Labels : frontend, enhancement

Issue : Erreur 500 sur le formulaire

Labels : bug, backend

Partie 3 — Les Assignees

Une tâche doit avoir un responsable. L’Assignee est la personne chargée de résoudre l’Issue.

Pourquoi assigner ?

L’équipe sait immédiatement qui travaille sur quoi.
Évite les doublons d’effort.
Clarifie la responsabilité.

Exemple

Issue	Assignée à
Créer la page de connexion	Alice
Créer le Dashboard	Bob
Créer la gestion des profils	Charlie

# S'assigner une Issue
gh issue assign <issue-number> --add @me

# Assigner un collègue
gh issue assign <issue-number> --add <username>

Partie 4 — Les Milestones

Une Milestone représente un objectif de livraison : une version, un sprint, une release.

Exemples de Milestones

Version 1.0
Version 2.0
Sprint 01
Sprint 02
Beta Release

Comment ça marche ?

Une Milestone regroupe plusieurs Issues.

Milestone : Version 1.0
  ├── Connexion
  ├── Profil
  ├── Dashboard
  └── Notifications

Lorsque toutes les Issues sont fermées, la Version 1.0 est prête.

# Créer une Milestone
gh api repos/:owner/:repo/milestones \
  --field title="Version 1.0" \
  --field description="Première release de l'application"

Partie 5 — Les Discussions

Toutes les conversations ne sont pas des tâches. Les Discussions permettent d’échanger des idées, des questions et des propositions sans polluer les Issues.

Exemples

Quelle architecture choisir ?
Faut-il utiliser PostgreSQL ?
Comment améliorer l’onboarding ?

Issue vs Discussion

Issue	Discussion
Tâche concrète	Question ouverte
A une deadline	Exploration
Résultat mesurable	Recherche de consensus

Partie 6 — GitHub Projects

GitHub Projects fonctionne comme un tableau Kanban pour visualiser le flux de travail.

Structure typique

Backlog → To Do → In Progress → Review → Done

Pourquoi c’est puissant ?

L’équipe visualise en un coup d’œil :

le travail restant ;
les priorités ;
l’avancement de chaque tâche.

Exemple réel

To Do
------
Créer Dashboard
Créer Notifications

In Progress
-----------
Créer Authentification

Review
------
Page Profil

Done
----
README
Landing Page

Automatisation

Les Projects peuvent être automatisés :

Déplacer une Issue vers In Progress quand une branche est créée.
Déplacer vers Review quand une Pull Request est ouverte.
Déplacer vers Done quand la PR est mergée.

Partie 7 — Les Releases

Une Release représente une version publiée du projet avec ses notes de version.

Exemples

v1.0.0
v1.1.0
v2.0.0

Contenu d’une Release

Nouvelles fonctionnalités
Corrections de bugs
Améliorations
Breaking changes

Pourquoi faire des Releases ?

Les utilisateurs et l’équipe savent ce qui a changé, quand et pourquoi.

# Créer une Release avec GitHub CLI
gh release create v1.0.0 \
  --title "Version 1.0.0" \
  --notes "Première version stable" \
  --target main

Partie 8 — Le Wiki

Le Wiki est l’espace de documentation du dépôt.

Exemples de pages Wiki

Architecture du projet
Guide d’installation
Guide de contribution
Documentation API
Standards de code

Pourquoi documenter ?

Un projet non documenté est difficile à maintenir. Le Wiki est modifiable par toute l’équipe et versionné comme le code.

“Un projet sans documentation n’est pas terminé.”

Partie 9 — Branch Protection Rules

La branche main est la branche la plus critique. Il faut la protéger.

Règles recommandées

Interdire le push direct sur main
Obliger une Pull Request pour merger
Exiger au moins une review approuvée
Exiger que les checks CI passent
Exiger que la branche soit à jour

Pourquoi ?

Évite les erreurs humaines
Empêche les régressions
Bloque les déploiements cassés
Maintient la qualité du code

Configuration

# .github/settings.yml — via GitHub Settings UI
# Settings → Branches → Add rule

# Nom de branche : main
# ✅ Require a pull request before merging
#   ✅ Require approvals (1)
# ✅ Require status checks to pass before merging
# ✅ Do not allow bypassing the above settings

Atelier pratique — Operation Sentinel

Transformez le dépôt Operation Sentinel en véritable projet d’équipe professionnel.

Étape 1 : Créer les Labels

gh label create bug --color d73a4a
gh label create enhancement --color a2eeef
gh label create documentation --color 0075ca
gh label create security --color 5319e7
gh label create frontend --color 5319e7
gh label create backend --color 0e8a16

Étape 2 : Créer les Issues

Créez ces Issues avec descriptions et labels :

Issue	Labels
Créer la page de connexion	`frontend`, `enhancement`
Créer le Dashboard	`frontend`, `enhancement`
Créer la gestion des profils	`frontend`, `enhancement`
Corriger le système de notifications	`backend`, `bug`

Étape 3 : Créer une Milestone

Créez la Milestone Version 1.0 et ajoutez toutes les Issues.

Étape 4 : Créer un Project Board

Créez un Project avec les colonnes :

Backlog
To Do
In Progress
Review
Done

Déplacez les Issues dans les colonnes appropriées.

Étape 5 : Assigner les tâches

Alice    → Créer la page de connexion
Bob      → Créer le Dashboard
Charlie  → Créer la gestion des profils

Mini Challenge

Mettez en place pour Operation Sentinel :

✅ Labels personnalisés
✅ Issues avec descriptions
✅ Milestones de release
✅ Project Board Kanban
✅ Wiki avec guide de contribution
✅ Protection de la branche main

Questions de réflexion

Pourquoi GitHub ne se limite-t-il pas à l’hébergement de code ?
Pourquoi une équipe a-t-elle besoin d’Issues ?
Pourquoi protéger la branche main ?
Pourquoi utiliser des Labels plutôt qu’une liste à plat ?
Pourquoi documenter un projet dans le Wiki ?

À retenir

Git gère	GitHub gère
Le code	La collaboration

Les fonctionnalités clés de GitHub pour les équipes :

Issues — Le cœur du suivi de travail
Labels — La catégorisation
Assignees — La responsabilisation
Milestones — Le rythme de livraison
Projects — La visualisation du flux
Discussions — Les échanges ouverts
Releases — Le cycle de vie logiciel
Wiki — La documentation vivante
Branch Protection — La qualité garantie

Vous venez de découvrir comment les équipes d’ingénierie organisent leur travail à grande échelle.

Fiches de révision

Question

Quel est le cycle de vie d'une Issue GitHub ?

Cliquer pour révéler la réponse

Réponse

Ouverture → Assignation → Développement → Review → Fermeture

Cliquer pour voir la question

Question

Quelles sont les catégories de Labels courantes ?

Cliquer pour révéler la réponse

Réponse

bug, enhancement, documentation, question, good first issue, help wanted

Cliquer pour voir la question

Question

À quoi sert une Milestone ?

Cliquer pour révéler la réponse

Réponse

Regrouper plusieurs Issues vers un objectif de livraison avec une date butoir

Cliquer pour voir la question

Question

Que bloque une Branch Protection Rule ?

Cliquer pour révéler la réponse

Réponse

Les pushs directs sur main et exige des PR approuvées avant merge

Cliquer pour voir la question

Évaluation des connaissances

Quel est le rôle principal d'une Issue sur GitHub ?

À quoi servent les Labels dans un projet GitHub ?

Qu'est-ce qu'une Milestone sur GitHub ?

Quel est l'intérêt d'un GitHub Project Board ?

Pourquoi protéger la branche main avec des Branch Protection Rules ?