Travailler avec des branches Git

Développer une fonctionnalité sur sa propre branche, la proposer par une Pull Request et la fusionner dans main.

Objectifs de la séance

• comprendre ce qu'est une branche et pourquoi la branche main doit toujours fonctionner ;
• créer une branche, y enregistrer des commits et l'envoyer sur GitHub ;
• ouvrir puis fusionner une Pull Request ;
• revenir sur main, récupérer les modifications et supprimer la branche devenue inutile ;
• créer le fichier src/constants/couleurs.ts (la palette de couleurs de l'application).

---

Petite vérification

Avant de commencer, vérifiez si vous savez...

1. lancer npm test dans le terminal et lire le nombre de tests réussis
2. ouvrir src/logic/melanger.ts et recopier la ligne qui crée une copie de la liste reçue
3. exécuter git log --oneline et lire le message du commit le plus récent

📌 Réponse attendue

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

---

Notions théoriques

Pourquoi des branches ?

Jusqu'ici, vous avez enregistré tous vos commits sur une seule ligne d'historique, la branche main. Dans une équipe (ou dès que le projet grossit), c'est dangereux : une fonctionnalité à moitié écrite peut casser l'application pour tout le monde.

Une branche est une ligne de développement parallèle : on y travaille à l'abri, sans toucher à main. Quand la fonctionnalité est terminée et vérifiée, on la fusionne (merge) dans main.

main      o---o---o-----------------o   (toujours une version qui fonctionne)
                   \               /
feature/palette     o---o---o-----o     (travail en cours, isolé)

La règle d'or : la branche main contient toujours une version qui fonctionne. On ne travaille jamais directement dessus (à partir de maintenant).

Les commandes à connaître

Commande	Rôle
git branch	lister les branches locales (la branche courante est précédée d'une étoile)
git switch -c feature/palette	créer la branche feature/palette et s'y placer
git switch main	se placer sur la branche main
git push -u origin feature/palette	envoyer la branche sur GitHub (le -u mémorise le lien pour les prochains git push)
git pull	récupérer les nouveautés de GitHub pour la branche courante
git branch -d feature/palette	supprimer une branche locale déjà fusionnée

Le nom d'une branche décrit son contenu. Par convention, une fonctionnalité se nomme feature/nom-court (sans espace ni accent). git status indique toujours la branche courante : « On branch feature/palette ».

La Pull Request

Une Pull Request (PR) est une demande de fusion faite sur GitHub : « voici mes modifications, voulez-vous les intégrer à main ? ». Elle permet de :

• relire les modifications ligne par ligne (onglet Files changed) ;
• discuter et demander des corrections avant la fusion ;
• lancer des vérifications automatiques (tests...) ;
• garder une trace de ce qui a été intégré, par qui et pourquoi.

Dans une entreprise, aucune modification n'entre dans main sans Pull Request relue par un collègue. C'est aussi une protection de sécurité : une relecture permet de repérer un mot de passe ou une clé oublié dans le code avant qu'il ne soit publié dans la branche principale.

Le cycle complet

1. se placer sur main et la mettre à jour (git switch main, git pull) ;
2. créer une branche (git switch -c feature/...) ;
3. coder, puis git add -A et git commit (autant de fois que nécessaire) ;
4. envoyer la branche (git push -u origin feature/...) ;
5. ouvrir la Pull Request sur GitHub, la relire, la fusionner ;
6. revenir sur main (git switch main), récupérer la fusion (git pull), supprimer la branche (git branch -d ...).

Les conflits

Si deux branches modifient la même ligne d'un fichier, Git ne sait pas laquelle garder : c'est un conflit. Git marque alors les deux versions dans le fichier et vous demande de choisir. Comme vous êtes seul sur votre projet, vous n'en rencontrerez pas ici, mais c'est l'une des raisons d'utiliser des branches courtes et de fusionner souvent.

---

TP pour réfléchir et résoudre des problèmes

Vous allez ajouter au projet la palette de couleurs de l'application, en suivant le cycle complet d'une fonctionnalité : branche, commit, Pull Request, fusion. Les commandes se tapent dans le terminal, dans le dossier quiz-cyber-expo.

Étape 1 — Mettre main à jour

Avant de créer une branche, assurez-vous de partir d'une branche main propre et à jour :

git status doit indiquer « On branch main » et « nothing to commit, working tree clean » (aucune modification en attente).

Bonne pratique - Partir d'un état propre et à jour

Créer une branche à partir d'une version de main périmée, c'est préparer des conflits pour plus tard. Vérifiez toujours git status et faites un git pull avant de créer une branche.

Étape 2 — Créer la branche feature/palette

Bonne pratique - Un nom de branche qui décrit le contenu

feature/palette dit exactement ce qu'on y fait. Évitez les noms comme test ou ma-branche : dans une équipe de dix personnes, personne ne saurait à quoi ils correspondent.

Étape 3 — Créer le fichier de la palette

Créez le dossier src/constants/ puis le fichier src/constants/couleurs.ts. Il regroupe toutes les couleurs de l'application à un seul endroit : pour changer une couleur partout, il suffit de la modifier ici.

Bonne pratique - Nommer les couleurs par leur rôle

COULEURS.erreur en dit plus que COULEURS.rouge : si la charte graphique change, on modifie la valeur sans toucher au nom, et le code qui l'utilise reste vrai.

Étape 4 — Enregistrer et envoyer la branche

Enregistrez votre travail dans un commit sur la branche, puis envoyez-la sur GitHub :

Le terminal affiche une adresse commençant par https://github.com/... pour créer la Pull Request : vous pouvez aussi passer par la page du dépôt.

Bonne pratique - Le commit part sur la branche, pas sur main

Vérifiez avec git status (ou git branch) que vous êtes bien sur feature/palette avant de commiter. Un commit fait par erreur sur main est difficile à défaire proprement.

Étape 5 — Ouvrir la Pull Request sur GitHub

1. Ouvrez la page de votre dépôt quiz-cyber-expo sur GitHub. Un bandeau jaune propose Compare & pull request pour la branche feature/palette : cliquez dessus.
2. Le titre est pré-rempli avec le message du commit. Ajoutez une courte description, par exemple « Ajoute la palette de couleurs utilisée par tous les écrans ».
3. Cliquez sur Create pull request.
4. Ouvrez l'onglet Files changed : relisez comme le ferait un collègue. Vous devez voir uniquement le nouveau fichier src/constants/couleurs.ts, en vert (lignes ajoutées).

Bonne pratique - Se relire avant de demander une relecture

L'onglet Files changed est le moment idéal pour vérifier qu'aucun fichier inattendu (un .env.local, des fichiers temporaires) n'a été ajouté, et que la modification correspond bien à la description.

Étape 6 — Fusionner, puis récupérer main

Sur la page de la Pull Request, cliquez sur Merge pull request (le bouton vert par défaut), puis Confirm merge. GitHub propose ensuite Delete branch : vous pouvez l'accepter, la branche distante n'est plus utile.

Dans le terminal, revenez sur main et récupérez la fusion :

git log --oneline affiche maintenant en haut un commit de fusion du type « Merge pull request #1 from votre-identifiant/feature/palette ». Le fichier couleurs.ts est désormais présent sur main.

Bonne pratique - Vérifier le résultat de la fusion

Après une fusion, regardez toujours git log --oneline : vous voyez que la modification est bien entrée dans main, et vous pouvez repartir en confiance pour la fonctionnalité suivante.

Étape 7 — Supprimer la branche devenue inutile

Seule la branche main doit rester dans la liste. Si Git refuse la suppression en disant que la branche n'est « pas totalement fusionnée », c'est qu'elle contient des commits absents de main : ne forcez pas, vérifiez d'abord que la Pull Request a bien été fusionnée.

Bonne pratique - Une branche, une fonctionnalité, puis on la supprime

Les branches sont jetables. Supprimer celles qui sont fusionnées garde la liste lisible, sans aucun risque : leur contenu est conservé dans l'historique de main.

📌 Une solution

Vous devez être connecté pour voir le contenu.

Email : Mot de passe :

---

Test de mémorisation/compréhension

Pourquoi ne travaille-t-on pas directement sur la branche main ?

Parce que Git interdit d'enregistrer un commit sur la branche main

Parce que la branche main est réservée au dossier node_modules

Parce que main est supprimée automatiquement après chaque fusion réussie

Pour que main contienne toujours une version qui fonctionne

Parce que GitHub limite la taille de la branche main à quelques fichiers

Quelle commande crée la branche feature/palette et s'y place ?

git switch -c feature/palette

git branch feature/palette && git delete main

git commit -b feature/palette

git push -c feature/palette

git switch feature/palette --new-from-github

Que représente une Pull Request ?

Une commande Git qui télécharge toutes les branches du dépôt distant d'un coup

Un fichier de configuration qui interdit de modifier la branche main

Une sauvegarde automatique du dossier du projet effectuée chaque nuit

Un message d'erreur affiché quand deux commits modifient le même fichier

Une demande de fusion d'une branche, relue puis acceptée

Que fait l'option -u dans git push -u origin feature/palette ?

Elle envoie uniquement les fichiers qui ont été modifiés aujourd'hui

Elle mémorise le lien avec la branche distante

Elle supprime la branche locale juste après l'envoi sur GitHub

Elle force l'écrasement de la branche distante si elle existe déjà

Elle ouvre automatiquement la Pull Request dans le navigateur de l'étudiant

Après la fusion de la Pull Request sur GitHub, quelle suite de commandes met votre ordinateur à jour ?

git push puis git switch feature/palette, sans passer par main

git commit -m "fusion" puis git push -u origin main

git switch main puis git pull

git branch -d main puis git switch -c feature/palette

git pull sur la branche feature/palette, puis git log sur la branche main

Quel est un avantage de sécurité de la relecture d'une Pull Request ?

Chiffrer automatiquement tous les fichiers de la branche fusionnée

Empêcher tout autre développeur de lire le code de la branche concernée

Supprimer de l'historique les mots de passe déjà publiés auparavant

Remplacer le fichier .gitignore par une version plus récente et plus sûre

Repérer un secret oublié avant son entrée dans main

---

Exercices complémentaires

Exercice A : une branche jetable

Créez une branche feature/essai, ajoutez une ligne de commentaire à README.md, commitez, puis revenez sur main avec git switch main. Votre ligne a-t-elle disparu ? Revenez sur la branche pour la retrouver. Essayez ensuite de supprimer la branche avec git branch -d feature/essai : que répond Git, et pourquoi ? (Supprimez-la définitivement avec git branch -D feature/essai, la majuscule force la suppression.)

Exercice B : relire une Pull Request

Sur GitHub, ouvrez la Pull Request fusionnée de la séance (onglet Pull requests, filtre Closed). Retrouvez l'onglet Commits et l'onglet Files changed, puis expliquez en une phrase ce qu'apporte chacun.

---

Ce qu'il faut retenir

Notion	Résumé
Branche	Ligne de développement parallèle : on travaille à l'abri sans toucher à main.
main	Branche principale : elle contient toujours une version qui fonctionne.
git switch -c feature/...	Crée une branche et s'y place.
git push -u origin feature/...	Envoie la branche sur GitHub et mémorise le lien.
Pull Request	Demande de fusion sur GitHub : relecture, discussion, fusion tracée.
Fin de cycle	git switch main, git pull, git branch -d feature/....

---

Aperçu de la prochaine séance

La palette est prête, mais l'écran d'accueil affiche encore du texte brut. Dans la prochaine séance, vous créerez une nouvelle branche, feature/composants, et vous afficherez enfin une vraie question du quiz avec ses quatre réponses, en utilisant JSX, les composants View et Text et les couleurs de la palette.