1) Notions de base (rappel rapide)

• Dépôt (repository) : espace qui contient le code et son historique Git.
• Fork : copie distante d’un dépôt GitHub dans l’espace d’un utilisateur/organisation. Le fork vit sur GitHub.
• Clone : copie locale d’un dépôt (le fork du groupe) sur la machine d’un étudiant.
• Branche : ligne de développement isolée (ex. feature-auth, bugfix-login).
• Pull Request (PR) : demande de fusion d’une branche vers une autre (revue de code, commentaires, vérifications).

Prof (dépôt original sur GitHub)
   │
   └───► Fork (1 par groupe, sur GitHub)
             │
             ├── Ajouter les collaborateurs (les autres membres du groupe)
             ├── Clone local (chaque étudiant)
             ├── Branches par tâche / par personne
             └── Pull Requests internes (revue et fusion dans le fork du groupe)

2) Organisation par groupe : un seul fork, des collaborateurs, des branches

Rôles

• Étudiant A (propriétaire du fork) : réalise le fork depuis le dépôt du professeur, paramètre le dépôt, ajoute les collaborateurs.
• Étudiants B et C (collaborateurs) : travaillent sur des branches dans le même fork, via leur clone local.

Pourquoi un seul fork par groupe ?

• Un seul espace de travail partagé (issues, PR internes, historique commun).
• Évite les divergences entre plusieurs forks parallèles d’un même groupe.
• Simplifie la coordination (revues et fusions dans un seul dépôt).

3) Workflow côté Git & GitHub (référence technique)

Étape 1 — Créer le fork (sur GitHub)

1. Aller sur le dépôt du professeur (commun à tous).
2. Un seul étudiant clique sur Fork et crée le fork dans son compte GitHub (ou l’organisation du groupe).

Étape 2 — Ajouter les collaborateurs (sur GitHub)

1. Dans le fork du groupe : Settings → Collaborators and teams → Add people.
2. Ajouter les comptes GitHub des autres membres. Ils doivent accepter l’invitation.

Étape 3 — Cloner le fork (en local, par chaque membre)

# Sur chaque machine
git clone https://github.com/<compte-ou-org-du-groupe>/<nom-du-projet>.git
cd <nom-du-projet>
git remote -v   # vérifie les remotes

Étape 4 — Créer une branche par fonctionnalité / par personne

# Créer et basculer sur une nouvelle branche
git checkout -b feature-formulaire-inscription

# Travailler, puis valider
git add .
git commit -m "Formulaire d'inscription : validation client + serveur"

# Publier la branche vers le fork du groupe
git push origin feature-formulaire-inscription

Étape 5 — Ouvrir une Pull Request interne (sur GitHub)

1. Aller sur GitHub → fork du groupe.
2. Créer une PR de feature-... vers main (du fork).
3. Demander une revue à un camarade : commentaires, corrections, commits additionnels si besoin.
4. Quand c’est validé : merge vers main du fork.

(Option) Synchroniser régulièrement sa branche avec la branche principale du fork

# Se replacer sur main (du fork local)
git checkout main
git pull origin main   # récupérer les derniers merges de PR

# Rebaser sa branche de travail sur la main à jour
git checkout feature-formulaire-inscription
git rebase main        # ou 'git merge main' si vous préférez fusionner
# Résoudre les conflits, puis :
git push --force-with-lease   # uniquement si rebase

(Option avancée) Lier le dépôt du professeur comme « upstream »

Utile si vous devez régulièrement mettre à jour le fork avec le dépôt original.

# Une seule fois :
git remote add upstream https://github.com/<prof>/<projet>.git

# Récupérer les dernières mises à jour du prof (sans fusionner)
git fetch upstream

# Mettre à jour la main du fork avec la main du prof
git checkout main
git merge upstream/main    # ou rebase si politique du dépôt
git push origin main

Remarque : ce cours reste focalisé sur le travail interne au fork du groupe. La PR vers le dépôt du professeur peut être introduite plus tard (même logique que les PR internes, mais de fork → original).

4) Workflow dans Visual Studio Code (pratique outillée)

Pré-requis

• VS Code installé, extension « GitHub » connectée (ou authentification Git déjà faite).
• Git configuré (nom, email).

Cloner le fork du groupe

1. VS Code → View → Command Palette (Ctrl/Cmd + Shift + P).
2. Git: Clone → coller l’URL du fork du groupe → choisir le dossier local → Open.

Créer et basculer sur une branche (interface VS Code)

1. Barre d’état (en bas) : cliquer sur le nom de branche (ex. main).
2. Create new branch… → nommer la branche (ex. feature-formulaire-inscription).
3. VS Code bascule sur la nouvelle branche.

Commit & Push (interface VS Code)

1. Onglet Source Control (icône Git).
2. Sélectionner les fichiers → + (stage) si nécessaire.
3. Entrer un message de commit → bouton Commit.
4. Cliquer sur Sync ou Push pour envoyer la branche sur GitHub.

Ouvrir une Pull Request interne

• Depuis GitHub (recommandé pour débuter) : bouton Compare & pull request dès que la branche est poussée.
• Compléter le titre et la description, assigner un reviewer (un camarade), puis créer la PR.
• Au besoin, installer l’extension « GitHub Pull Requests » pour interagir directement depuis VS Code (optionnel).

Récupérer les mises à jour

• Depuis VS Code : Pull depuis main du fork pour rester à jour avant de créer/mettre à jour vos branches.
• En cas de conflits, VS Code propose une interface de résolution (choisir « current / incoming / both »).

5) Stratégie de branches recommandée (groupe de 2–3)

• main : branche stable du fork (protégée si possible).
• 1 branche par fonctionnalité ou correctif :
  • feature-… pour les ajouts (ex. feature-export-csv).
  • bugfix-… pour les corrections (ex. bugfix-null-pointer).
  • docs-… pour la documentation.
• Chaque membre travaille sur sa propre branche, ouvre une PR interne, obtient une revue, puis fusionne.

6) Bonnes pratiques minimales

• Faire des petits commits bien nommés (impératif court, scope clair).
• Toujours pull avant de créer une nouvelle branche et avant de pousser.
• Une PR = une fonctionnalité (facilite la relecture et le merge).
• Résoudre les conflits sur des branches, pas directement sur main.
• Documenter dans le README.md les commandes, scripts, et prérequis.

7) Erreurs courantes et remèdes

• Plusieurs forks par groupe → divergences. Solution : un seul fork, ajouter des collaborateurs.
• Travailler sur main → instable. Solution : toujours créer une branche dédiée.
• Gros commits fourre-tout → relecture difficile. Solution : commits et PR atomiques.
• Oublier de pull → conflits tardifs. Solution : pull/rébase régulièrement la branche de travail.

8) Checklist opérationnelle (résumé)

1. (Groupe) 1 étudiant fork le dépôt du prof sur GitHub.
2. (Groupe) Ajouter tous les membres comme collaborateurs.
3. (Chaque étudiant) Cloner le fork du groupe sur sa machine.
4. (Avant chaque tâche) Créer une branche feature-… ou bugfix-….
5. Commits réguliers → push sur la branche distante.
6. Ouvrir une PR interne → demander une revue → corriger si besoin.
7. Fusionner dans main du fork une fois validé.

9) Glossaire

• origin : remote par défaut qui pointe vers le fork du groupe.
• upstream : remote optionnelle pointant vers le dépôt original du professeur.
• rebase : réécrit l’historique pour « rejouer » vos commits au-dessus d’une base plus récente.
• merge : fusionne deux lignes d’historique en conservant les branches.