Aller au contenu principal

Travailler avec des branches

Schéma

  • Comprendre à quoi servent les branches, et pourquoi ne pas tout faire directement sur main.
  • Créer, changer de branche, et fusionner (merge) une branche dans une autre.
  • Résoudre un premier conflit de fusion, seul(e), avant de le faire à deux.

Petite vérification​

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

  1. générer une paire de clés SSH
  2. relier un dépôt local à un dépôt distant nommé origin
  3. récupérer, en local, une modification faite directement sur GitHub
📌 Réponse attendue

Notions théoriques​

Jusqu'ici, tous nos commits s'enchaînent sur une seule ligne, la branche main. Cela fonctionne pour un tout petit projet, mais devient risqué dès que l'on veut essayer quelque chose sans casser ce qui fonctionne déjà.

Une branche est une ligne d'évolution indépendante de l'historique : on peut y expérimenter, commettre des erreurs, et revenir en arrière, sans jamais toucher à main tant que le travail n'est pas prêt.

Créer et changer de branche​

git branch                    # liste les branches existantes
git switch -c page-contact    # crée la branche "page-contact" et bascule dessus
git switch main               # revient sur la branche main
info

git switch -c est la commande moderne pour créer une branche. Vous rencontrerez aussi souvent l'ancienne syntaxe équivalente : git checkout -b page-contact.

Fusionner une branche (merge)​

Une fois le travail terminé sur page-contact, on le rapatrie dans main :

git switch main
git merge page-contact

Deux cas possibles :

  • Fast-forward : main n'a reçu aucun nouveau commit depuis la création de page-contact. Git déplace simplement le pointeur de main, sans créer de nouveau commit.
  • Merge commit : main a évolué en parallèle. Git crée un commit spécial, qui a deux parents, pour réunir les deux historiques.

Un conflit, c'est quoi ?​

Un conflit survient quand Git ne peut pas décider tout seul comment fusionner deux versions différentes de la même ligne d'un fichier. Git marque alors le fichier avec des balises :

<<<<<<< HEAD
Le club est ouvert du lundi au vendredi.
=======
Le club est ouvert 7 jours sur 7.
>>>>>>> page-contact

Il faut alors éditer le fichier à la main, choisir (ou combiner) la bonne version, supprimer les balises <<<<<<<, =======, >>>>>>>, puis committer :

git add fichier-en-conflit.txt
git commit -m "Résout le conflit sur les horaires"
attention

Un conflit n'est pas une erreur : c'est Git qui vous demande votre avis parce qu'il ne peut pas deviner laquelle des deux versions est la bonne. Prenez le temps de lire les deux côtés avant de choisir.

Exemple pratique​

Reprenons mon-portfolio. Créons une branche pour ajouter une section "contact" :

git switch -c page-contact
echo "<h2>Contact</h2><p>email@exemple.fr</p>" >> index.html
git add index.html
git commit -m "Ajoute une section contact"

Pendant ce temps, imaginons qu'un correctif urgent soit fait directement sur main :

git switch main
echo "<footer>© 2026</footer>" >> index.html
git add index.html
git commit -m "Ajoute un pied de page"

Fusionnons maintenant page-contact dans main :

git merge page-contact

Comme les deux branches ont modifié index.html à des endroits différents, Git fusionne automatiquement, sans conflit, et crée un merge commit. Visualisons le résultat :

git log --oneline --graph --all

Test de mémorisation/compréhension​


À quoi sert principalement une branche Git ?


Quelle commande crée une nouvelle branche et bascule dessus immédiatement ?


Qu'est-ce qu'une fusion "fast-forward" ?


Pourquoi Git crée-t-il un "merge commit" dans certains cas ?


Quand un conflit de fusion se produit-il ?


Que représentent les balises <<<<<<<, ======= et >>>>>>> dans un fichier ?


Une fois un conflit résolu manuellement dans un fichier, quelle est la suite des opérations ?


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

Vous allez créer une branche sur mon-cv, y faire une modification, la fusionner, puis provoquer et résoudre volontairement un conflit.

Étape 1 — Créer une branche​

Étape 2 — Travailler sur la branche​

Ajoutez <h2>Compétences</h2><p>PHP, SQL, Git</p> à la fin de index.html, puis committez.

Étape 3 — Fusionner dans main​


Bonne pratique - Des noms de branche explicites

Nommez vos branches d'après ce qu'elles contiennent (section-competences, correction-lien-cv), jamais test, branche2 ou votre prénom : dans un historique avec plusieurs branches, ces noms deviennent illisibles.

Étape 4 — Provoquer et résoudre un conflit​

Créez une nouvelle branche experimentation, modifiez la toute première ligne de index.html (par exemple <h1>Mon CV</h1> devient <h1>CV de [votre prénom]</h1>), committez. Revenez sur main, modifiez cette même première ligne différemment (par exemple <h1>Curriculum Vitae</h1>), committez aussi sur main. Fusionnez enfin experimentation dans main.


Bonne pratique - Fusionner souvent, par petits morceaux

Plus une branche vit longtemps sans être fusionnée dans main, plus le risque de conflit augmente, et plus les conflits deviennent difficiles à résoudre. Fusionnez régulièrement, dès qu'une petite tâche est terminée.