📚 Formation

← Git & GitHub : du premier commit au travail en équipe

Projet final : une vraie semaine d'équipe

≈ 45–60 minutes · Prérequis : Les conflits de merge, sans paniquer

Le gain du jour : dérouler, sans filet et sans regarder les leçons, tout le cycle d’un vrai projet d’équipe. Si tu termines ce projet, tu sais travailler avec Git et GitHub — pas « en théorie » : pour de vrai.

Le scénario

Vous construisez à deux (ou en solo en jouant les deux rôles) un mini-projet meteo-madagascar : un dépôt partagé, deux « développeurs », chacun sa branche, des PR croisées, une revue mutuelle — et un conflit garanti à la fin, prévu dans le script.

Seule règle absolue : interdiction de committer directement sur main. Tout passe par branche + PR, comme dans une vraie équipe.

Acte 1 — Fondation (Dev A)

  1. Dev A crée le dépôt et l’ossature, puis publie :

    mkdir meteo-madagascar && cd meteo-madagascar
git init
echo "# Météo Madagascar" > README.md
echo "villes = ['Antananarivo', 'Toamasina']" > villes.py
git add README.md villes.py
git commit -m "Initialise le projet météo"
gh repo create meteo-madagascar --private --source=. --push

  2. Dev A invite Dev B : page GitHub du dépôt → Settings → Collaborators → Add people. (En solo : saute cette étape, tu joueras les deux rôles.)

  3. Dev B rejoint le projet :

    git clone https://github.com/<dev-a>/meteo-madagascar.git
cd meteo-madagascar

Acte 2 — Travail en parallèle (les deux, en même temps)

  1. Chacun sa branche, chacun sa tâche :

    • Dev A : branche ajout-temperatures — créer temperatures.py avec un dictionnaire ville → température.
    • Dev B : branche ajout-villes — ajouter deux villes à villes.py.

    Pour chacun : git switch -c <branche>, au moins deux commits aux messages impératifs, git diff relu avant chaque commit.

  2. Chacun pousse et ouvre sa PR (git push -u origin <branche>, puis gh pr create).

  3. Revue croisée : chacun relit la PR de l’autre — au moins un commentaire de fond (pas « lgtm » !), l’auteur répond par un commit correctif, le relecteur approuve (Review changes → Approve).

  4. Merge des deux PR, puis chacun : git switch main && git pull.

Acte 3 — Le conflit (prévu au script)

  1. Les deux devs, en même temps et chacun sur une branche neuve, modifient la première ligne du README (Dev A : « # Météo Madagascar 🌦 » ; Dev B : « # Projet Météo — Madagascar »), commitent, poussent, ouvrent leur PR.

  2. La première PR merge sans souci. La seconde affiche « This branch has conflicts ». Son auteur applique la méthode de la leçon 7 :

    git switch ma-branche
git pull                 # au cas où
git merge main           # le conflit apparaît en local
# status → éditer le README (trouvez un titre qui honore les deux !) → add → commit
git push                 # la PR redevient verte

  3. Merge final, git switch main && git pull des deux côtés, et admirez :

    git log --oneline --graph

    Ce graphe — branches, fusions, conflit résolu — c’est l’histoire d’une équipe qui a travaillé proprement. Félicitations, le cours est terminé. 🎓

Auto-évaluation finale

1. Remets le rituel d'équipe dans l'ordre :

2. Ta PR affiche « This branch has conflicts ». Quelle est la marche standard ?

Et après ?

Tu as les fondations. La suite se construit en situation réelle :