Expériences sûres : travail avec les branches

1. Qu'est-ce qu'une branche et pourquoi en avoir ?

Travailler avec branches dans Git — c'est un des aspects clés de la gestion de versions, qui permet de mener parallèlement plusieurs lignes de développement dans un même repository. Le branching rend Git un outil puissant pour la collaboration, les expérimentations et la gestion des différentes versions d'un projet.

            gitGraph
            commit id: "Initial setup"
            commit id: "Add base features"
            branch feature/new-idea
            checkout feature/new-idea
            commit id: "Implement new logic"
            commit id: "Refactor the logic"
            checkout main
            commit id: "Urgent bugfix on main"
            merge feature/new-idea
            commit id: "Prepare for release"
        

Imaginez que vous voulez refondre sérieusement votre projet ou faire une expérience risquée. Comment feriez-vous sans Git ? Vous copieriez probablement tout le projet dans un nouveau dossier et travailleriez là-bas. Si le résultat vous plaît — vous le transférez dans le dossier principal. Sinon — vous supprimez la copie.

Les branches dans Git fonctionnent sur le même principe, mais de façon beaucoup plus élégante. Prenons l'exemple de l'écriture d'un livre :

1. Vous avez un manuscrit prêt (c'est votre branche principale main).
2. Vous voulez écrire une fin alternative (vous créez une nouvelle branche, par exemple feature/new-idea).
3. Vous écrivez la nouvelle fin sans toucher au texte principal du manuscrit (vous travaillez dans la nouvelle branche).
4. Si la nouvelle fin est meilleure, vous la remplacez (vous faites la fusion des branches — merge).
5. Le vieux brouillon avec la fin inutile peut être supprimé (vous supprimez la branche).

2. Création d'une nouvelle branche et travail dedans

Étape 1. Ouvrez le menu de gestion des branches.

Dans la barre supérieure de l'IDE se trouve un widget affichant le nom de la branche courante (par défaut — main). Cliquez dessus et choisissez + New Branch.

Étape 2. Nom de la nouvelle branche.

Bonne pratique — nommer les branches selon la tâche que vous résolvez. Par exemple, feature/add-usage-examples.

Après la création, l'IDE basculera automatiquement dessus. Vous verrez le nouveau nom dans le même widget.

Étape 3. Faites et commitez vos changements.

Vous êtes maintenant dans votre "bac à sable". Ajoutons une nouvelle section d'exemples d'utilisation dans notre fichier README.md. Faites les modifications et effectuez un commit, comme vous l'avez appris dans la leçon précédente.

3. Basculer entre les branches

Vos changements avec les exemples d'utilisation sont maintenant en sécurité dans la branche feature/add-usage-examples. Revenons à la branche principale main pour voir ce qu'il y a là-bas.

Étape 1. Cliquez de nouveau sur le widget du nom de la branche courante.

Étape 2. Dans la liste Local ou Recent, choisissez la branche main, et dans le sous-menu qui apparaît cliquez sur Checkout.

Étape 3. Vérifiez le résultat.

Dès que vous basculez, ouvrez le fichier README.md. Vous verrez que la section d'exemples d'utilisation n'y est pas ! Elle est restée dans l'autre branche. Ainsi, vous pouvez travailler sur une nouvelle fonctionnalité sans toucher à la version stable dans la branche main.

4. Fusion des branches (Merge)

La commande merge prend tous les commits de la branche feature/add-examples (dans cet exemple, le commit C3) et les combine avec la branche courante main, créant un nouveau commit de merge.

            gitGraph
            commit id: "C1"
            commit id: "C2"
            branch feature/add-examples
            checkout feature/add-examples
            commit id: "C3: Add new section"
            checkout main
            merge feature/add-examples
        

Donc, vous avez terminé la tâche dans la branche feature/add-usage-examples et vous voulez intégrer ces changements au projet principal.

Étape 1. Basculez vers la branche cible.

Assurez-vous d'être dans la branche où vous voulez AJOUTER les changements. Dans notre cas, c'est main.

Étape 2. Effectuez la fusion.

Cliquez de nouveau sur le widget de gestion des branches. Dans la liste, choisissez la branche D'OÙ vous voulez prendre les changements (feature/add-usage-examples), et dans le sous-menu sélectionnez Merge feature/add-usage-examples into main.

Étape 3. Vérifiez le résultat.

Maintenant, dans le fichier README.md de la branche main apparaît votre nouvelle section d'exemples. Vous avez réussi à intégrer votre travail à la version principale du projet !

5. Conflits de merge : ne paniquez pas, c'est normal !

Parfois, lors d'une fusion de branches, des conflits surviennent. Ça arrive lorsque les mêmes lignes d'un même fichier ont été modifiées dans les deux branches. Git ne peut pas choisir tout seul quelle version est la bonne et demande votre aide.

            gitGraph
            commit id: "C1: Base commune"
            branch feature/new-title
            checkout main
            commit id: "C2: Changement dans main"
            checkout feature/new-title
            commit id: "C3: Changement dans feature"
        

Modélisons un conflit :

1. Assurez-vous d'être dans la branche main et de ne pas avoir de modifications non sauvegardées.
2. Créez immédiatement une nouvelle branche feature/new-title, mais ne basculez pas dessus tout de suite. Assurez-vous que la case Checkout branch est décochée.
3. Maintenant, restant sur la branche main, changez la première ligne dans README.md en "My Awesome Project" et faites un commit.
4. Basculez sur la branche feature/new-title. Vous verrez que la première ligne dans README.md est restée ancienne : c'est l'état du fichier au moment de la création de la branche. Changez cette même ligne en "My Super Project" et faites un commit.
5. Revenez sur la branche main et lancez la fusion avec feature/new-title.

Maintenant Git verra que les deux branches ont des histoires nouvelles et divergentes depuis leur ancêtre commun. Dans les deux histoires, la même ligne a été modifiée, donc Git ne pourra pas choisir quelle version garder et vous affichera une fenêtre pour résoudre le conflit.

Merge Revision

Ce que vous voyez ici :

• À gauche (Your changes): la version du fichier depuis votre branche courante (main).
• À droite (Changes from branch...): la version du fichier depuis la branche que vous fusionnez.
• Au centre (Result): la version finale du fichier que vous devez composer.

Vous pouvez cliquer sur les flèches >> ou << pour accepter entièrement une des versions.

Quand le résultat dans le panneau central vous convient, cliquez sur Apply. L'IDE créera elle-même le commit de merge, et le conflit sera résolu.

Pourquoi il n'y a pas eu de conflit ?

Il peut arriver que vous suiviez toutes les étapes et qu'aucun conflit ne survienne. Le plus souvent, c'est parce que Git a pu effectuer un fast-forward merge, puisque l'historique d'une branche a simplement continué celui de l'autre. Pour qu'un conflit soit garanti, les histoires des branches doivent diverger à partir d'un ancêtre commun.

Exemple :

1. Vous avez un commit dans main (appelons-le C1).
2. Vous faites un nouveau commit dans main avec le texte "My Awesome Project". La branche main pointe maintenant sur le commit C2 (main -> C1 -> C2).
3. Vous créez la branche feature/new-title à partir de la position actuelle de main. Cela signifie que la nouvelle branche commence aussi depuis le commit C2.
4. Vous faites un commit dans feature/new-title avec le texte "My Super Project". Cette branche avance et pointe maintenant sur le commit C3 (feature/new-title -> C1 -> C2 -> C3).
5. Vous revenez à main (qui est toujours sur le commit C2) et demandez à fusionner feature/new-title.

Git regarde la situation et voit que la branche main est un ancêtre direct de la branche feature/new-title. Il n'y a pas eu de nouveaux commits sur main pendant que vous travailliez dans l'autre branche. Git se dit : "OK, il suffit d'avancer le pointeur main jusqu'au commit C3. Pas de conflit." Et il déplace simplement le pointeur main vers le commit C3.

            gitGraph
            commit id: "C1"
            commit id: "C2"
            branch feature/new-title
            checkout feature/new-title
            commit id: "C3"
            checkout main
            merge feature/new-title
        

6. Visualiser l'historique des changements

Pour mieux comprendre ce qui se passe dans votre projet, il est utile de regarder son historique.

Ouvrez l'onglet Git en bas de l'IDE et choisissez Log. Vous verrez une représentation graphique de toutes vos branches et commits. Ça aide à suivre visuellement quelle branche est issue de laquelle et où elles ont été fusionnées.

Ici vous pouvez cliquer sur n'importe quel commit pour voir quels changements il contient, qui l'a fait et quand. C'est vraiment une machine à remonter le temps pour le code !