Branches et fusions

1. Une branche est une référence mobile

Dans le laboratoire, main contient la base du portail. Une branche feature/contact peut accueillir l’ajout d’une page de contact pendant que main reste stable. Les deux références pointent d’abord vers le même commit ; elles divergent lorsqu’on enregistre des changements différents.

git switch change la branche courante et adapte les fichiers au commit visé. Les modifications non enregistrées peuvent parfois être conservées lors du changement de branche ; Git refuse les situations qui les écraseraient. Pour débuter, partez d’un état propre ou mettez explicitement le travail de côté.

2. Créer une fonctionnalité

git status
git switch -c feature/contact
Set-Content -Encoding utf8 contact.html "<h1>Contacter NKILItech</h1>"
git add contact.html
git commit -m "Ajouter la page de contact"
git branch --show-current
git log --oneline --graph --decorate --all

switch -c crée puis sélectionne la branche. La référence feature/contact avance au nouveau commit ; main reste sur son commit précédent. Le fichier contact.html disparaît du dossier de travail si vous revenez sur main, puisque cette version de main ne contient pas encore ce fichier. Le commit reste accessible par la branche de fonctionnalité.

Une convention comme feature/, fix/ et docs/ aide à reconnaître l’intention. Elle ne change pas la nature des branches. Les noms doivent être simples à lire et compatibles avec Git ; évitez les espaces.

3. Fusionner depuis la branche de destination

git switch main
git merge feature/contact
git log --oneline --graph --decorate --all

La fusion s’exécute depuis la branche qui doit recevoir le résultat. Ici, main reçoit le travail de feature/contact. Si main n’a pas avancé depuis la création de cette branche, Git peut réaliser une avance rapide, ou fast-forward : main avance simplement vers le commit déjà existant.

Si les deux branches ont avancé séparément, une fusion classique combine leurs histoires. Un nouveau commit de fusion peut posséder deux parents. La présence d’un commit de fusion ne signifie pas qu’il y a eu conflit ; de nombreux changements indépendants se réunissent automatiquement.

4. Choisir une stratégie lisible

git merge --no-ff demande un commit de fusion même lorsqu’une avance rapide serait possible. Ce choix peut rendre la frontière d’une fonctionnalité visible. Un historique linéaire, à l’inverse, peut faciliter certaines lectures. L’équipe doit décider du résultat qu’elle veut conserver.

La fusion squash rassemble les changements d’une branche en un nouveau commit sur la cible sans conserver la même relation d’ascendance qu’une fusion classique. Sur GitHub, les options de fusion autorisées dépendent du dépôt. Nous comparerons leur effet lors des pull requests.

Ne choisissez pas une stratégie uniquement parce que le graphe paraît plus joli. La possibilité de retrouver l’origine d’un changement, les usages de l’équipe et le rythme de livraison comptent aussi.

5. Supprimer une référence devenue inutile

git switch main
git branch -d feature/contact
git branch

Après la fusion classique réussie dans ce parcours, -d supprime la référence locale de la branche si les conditions de sécurité de Git sont satisfaites. Les commits intégrés restent accessibles depuis main. Cette commande ne supprime pas une branche hébergée sur GitHub.

Après une fusion squash, Git peut refuser -d parce que l’ascendance de la branche n’a pas été intégrée de la même façon. Vérifiez alors le contenu et l’historique au lieu de remplacer automatiquement -d par une suppression forcée.

6. Séparer le travail de la livraison

Chez NKILItech, une branche de fonctionnalité regroupe un objectif : améliorer le contact, corriger un calcul ou enrichir une documentation. Elle est plus facile à relire lorsqu’elle reste courte et centrée sur un sujet.

La branche principale doit correspondre à un état que l’équipe comprend et sait vérifier. Elle n’est pas nécessairement identique à la version actuellement déployée : une étiquette de version et une procédure de livraison peuvent préciser ce lien.

Avant une fusion, vérifiez les fichiers, le comportement attendu et la destination. Un merge dans la mauvaise branche peut être corrigé, mais la meilleure économie consiste à lire la branche courante avant de lancer la commande.

Exercices corrigés