Le récit défilant : Git en équipe¶

Pourquoi des branches, à deux?¶

À deux dans le même dépôt, si vous travaillez tous les deux sur main, chaque push de l'un peut bloquer l'autre, et une erreur de l'un casse le projet des deux.

Avec une branche par personne :

• chacun avance à son rythme, sans déranger l'autre;
• main reste stable : c'est la version qu'on montre, qu'on teste et qu'on remet;
• l'historique montre qui a fait quoi, ce qui sert à votre évaluation individuelle.

Le flux de travail, en une image¶

main    ●────────────●───────────────●──────────●
         \          ↗ PR #1           ↗ PR #2   ↑ remise
zoe       ●───●───●              ●───●
           \                    ↗ mise à jour avec main
leo         ●───●───●───────────●───●───●

1. Au départ, l'équipe crée ensemble la structure commune sur main.
2. Chacun crée sa branche à partir de main (ici zoe et leo).
3. Chacun travaille et commit sur sa branche.
4. Une partie est prête? On ouvre une pull request (PR) : « je propose de fusionner ma branche dans main ».
5. Après chaque fusion, l'autre met sa branche à jour avec main, pour travailler sur la dernière version.

Étape 1 : la structure commune, sur main¶

Une seule fois, au début, ensemble sur un seul poste :

1. Créez les dossiers et fichiers de base : index.html, css/style.css, js/main.js, data/data.json, assets/images/.
2. Dans data/data.json, créez le squelette de tous vos chapitres, même vides : un objet par chapitre, avec son id, son numero et son responsable. Chacun remplira ensuite ses objets.
3. Commit sur main, puis push.
4. L'autre personne fait un pull (ou clone le dépôt).

Pourquoi le squelette? Si chacun ajoute ses chapitres à la fin du fichier en même temps, vous modifiez les mêmes lignes : c'est le conflit assuré. Avec le squelette, chacun remplit des lignes différentes.

Étape 2 : créer sa branche¶

Une branche à votre prénom, en minuscules, sans accents : zoe, leo, marie-eve.

Le réflexe : avant de coder, un coup d'œil à la branche active. Ce doit être la vôtre, jamais main.

Étape 3 : travailler et commit sur sa branche¶

Vous travaillez comme d'habitude : de petits commits fréquents, puis push. Vos commits vont sur votre branche, et main ne bouge pas.

C'est quoi, une pull request?¶

Une pull request (PR), c'est une demande faite sur GitHub : « J'ai fait des changements sur ma branche. Je propose de les intégrer dans main. » Le nom vient du point de vue de l'équipe : vous lui demandez de tirer (pull) vos changements dans la version commune.

Pensez au mode suggestion dans Word ou Google Docs : vous proposez des modifications, quelqu'un les relit, puis les accepte. Tant que personne n'accepte, le document de référence ne change pas. Ici, le document de référence, c'est main.

Ce qu'on trouve dans une PR¶

Une PR est une page de votre dépôt sur github.com, avec :

• la direction : quelle branche on fusionne, dans laquelle (main ← zoe);
• les commits de la branche qui seront ajoutés à main;
• les différences (onglet Files changed) : chaque ligne ajoutée en vert, chaque ligne retirée en rouge;
• une conversation : on peut commenter, poser une question, demander une correction, même sur une ligne précise;
• le bouton de fusion (Merge pull request). GitHub vous avertit si la fusion crée un conflit.

Ce qu'il faut retenir¶

• Une PR n'est pas une copie figée. Si on vous demande une correction, faites-la sur votre branche, commit, push : la PR se met à jour toute seule.
• Tant que la PR n'est pas fusionnée, main ne bouge pas. C'est ce qui protège la version de l'équipe.
• Une PR fusionnée reste dans l'historique (onglet Pull requests → Closed) : c'est la trace de qui a proposé quoi, et de qui l'a accepté.

Étape 4 : fusionner dans main avec une pull request¶

Une partie de votre travail fonctionne (ex. le chapitre 3 s'affiche et s'anime)? Proposez-la à l'équipe :

1. Faites un push de votre branche.
2. Sur github.com, ouvrez votre dépôt. Un bandeau jaune propose Compare & pull request. Sinon : onglet Pull requests → New pull request.
3. Vérifiez la direction : base: main ← compare: zoe.
4. Donnez un titre clair (ex. Ch. 3 : parallaxe de la forêt) et décrivez en une ou deux phrases ce que la PR ajoute. Create pull request.
5. Votre coéquipier ou coéquipière y jette un œil (onglet Files changed), puis Merge pull request → Confirm merge.

Étape 5 : mettre sa branche à jour avec main¶

Après la fusion d'une PR, main contient du nouveau travail. Avant de continuer, chacun récupère main dans sa branche :

Puis push. Faites-le souvent : au début de chaque séance de travail, et après chaque PR fusionnée.

Les conflits¶

Pourquoi un conflit?¶

Git fusionne seul tout ce qu'il peut. Il s'arrête seulement quand les deux branches ont modifié les mêmes lignes du même fichier : il ne peut pas deviner laquelle garder. C'est un conflit. Ce n'est pas une erreur : c'est Git qui vous demande de choisir.

À quoi ça ressemble¶

Dans le fichier, Git place des marqueurs autour des deux versions :

<<<<<<< HEAD
<h1>La forêt enchantée</h1>
=======
<h1>Dans la forêt</h1>
>>>>>>> origin/main

• Entre <<<<<<< HEAD et ======= : votre version (la branche active).
• Entre ======= et >>>>>>> : la version qui arrive (ici, celle de main).

Le régler dans VS Code¶

1. Le panneau Source Control liste les fichiers en conflit (marqués !). Ouvrez-en un.
2. Au-dessus de chaque conflit, VS Code propose :
   • Accept Current Change : garder votre version;
   • Accept Incoming Change : garder la version qui arrive;
   • Accept Both Changes : garder les deux, l'une sous l'autre;
   • ou modifiez le texte à la main pour écrire la bonne version.
3. Vérifiez qu'aucun marqueur (<<<<<<<, =======, >>>>>>>) ne reste dans le fichier.
4. Enregistrez, ajoutez le fichier (+), puis commit (le message est déjà proposé) et push.

Dans GitHub Desktop, la fenêtre de fusion liste les fichiers en conflit : ouvrez-les dans VS Code, réglez-les de la même façon, puis cliquez sur Continue merge.

Les éviter¶

• Un fichier par zone quand c'est possible : par exemple css/chapitre-3.css et js/chapitre-3.js pour la personne responsable du chapitre 3.
• Les fichiers communs (index.html, css/style.css, data/data.json) : on se prévient avant d'y toucher, et on fusionne vite.
• Mettez votre branche à jour souvent : un petit conflit aujourd'hui vaut mieux qu'un gros dans deux semaines.

La convention de commits de l'équipe¶

Les deux membres de l'équipe écrivent leurs messages de la même façon :

Zone : ce qui a changé, à l'impératif

Comme au portfolio : en français, à l'impératif, précis. Jamais update, fix ou wip. La zone au début permet de retrouver en un coup d'œil, dans l'historique, le travail de chacun.

Pour pratiquer¶

Avant de toucher à votre projet, provoquez un conflit volontairement, dans un petit dépôt d'exercice créé par Classroom 50, et réglez-le à deux.

Exercice : provoquer et régler un conflit