Pour moi le concept de branches est le coeur de Git, ou plutôt, la puissance de Git. Une branche permet, depuis un commit spécifique, d’avoir une nouvelle version du code source. Grâce à cela, nous pouvons faire des ajouts ou des modifications de manière isolée. Changer de branche, revenir sur celle d’avant, en créer de nouvelle, la supprimer, bref. Pouvoir avoir un nombre infini de versions de son code source offre beaucoup de possibilités. En plus Git comprend cela, au point que si l’on veut fusionner (merger) des branches ensemble, cela est possible et relativement simple, ce qui fait des branches, selon moi, le point central de Git.

Dans ce premier chapitre sur les branches, je vais t’expliquer comment les manipuler simplement et te donner les commandes essentielles à connaître afin d’être à l’aise pour aborder la fusion (merge).

Lorsque tu initialises un dépôt, une branche par défaut est créée, elle porte le nom de « master ». C’est le nom généralement utilisé et que l’on considérera comme la branche de production. Avec certains services, notamment celui de Gitlab, on pourra retrouver le nom « main » au lieu de master.

Il y a deux façons de voir sur quelle branche on se trouve. La première est l’utilisation de la commande git status, elle sera directement affichée sur la première ligne :

La seconde est l’utilisation de git branch, une commande dédiée aux branches qui permet de voir à la fois la branche courante et toutes les autres branches.

La branche sur laquelle on se trouve (master) sera préfixée par un astérisque.

Pour créer une nouvelle branche, je vais utiliser la commande git branch en lui donnant un nom.

En exécutant cette commande, Git va créer une branche depuis le HEAD, c’est-à-dire depuis la branche et le commit sur lequel je me trouve. On peut imaginer ça comme « une copie » de telle sorte à ce que si je fais des modifications sur cette nouvelle branche, l’original ne sera pas impacté.

Git est conçu d’une façon à ce que la création de branche ne coute presque rien en espace disque. Sans trop entrer dans les détails, le système fonctionne avec des références (pointeurs) et stocke uniquement les changements.

Après avoir créé la nouvelle branche « staging », si je fais un git branch, je peux voir qu’elle a bien été créée mais l’astérisque m’indique que je suis toujours sur master.

Pour basculer sur la nouvelle branche, je vais utiliser la commande git checkout en spécifiant le nom de celle-ci.

Je peux voir maintenant que l’astérisque est positionné sur staging.

P.S. « checkout » est un nom de commande défini pour trop de choses dans Git à tel point que pour les débutants c’est parfois compliqué de s’y retrouver. À partir de la version 2.23, il est possible d’utiliser une commande (switch à la place de checkout) qui a plus de sens pour changer de branche.

Il est également possible de créer une branche et de switcher dessus en une seule commande. Je te conseille d’utiliser cette commande afin d’éviter de créer une branche et de commiter sur la mauvaise par oubli de checkout. Il faudra donc utiliser la commande checkout avec le flag -b et spécifier le nom de la branche que tu souhaites créer.

Cette commande est un raccourci qui exécutera deux commandes en série, un git branch suivi d’un git checkout sauf que ce sera transparent pour toi.

Comme pour le switch juste au-dessus, il est possible d’utiliser la commande moderne, cette fois-ci avec le paramètre -c (pour create).

Il y a deux cas de figure typiques où changer de branche causera un message d’erreur. Le premier, c’est lorsque je crée un fichier dans une branche sans l’ajouter dans l’index et que je tente d’aller sur une branche où ce fichier existe déjà. Voici le message d’erreur que j’obtiens :

Il me dit qu’il va se faire écraser par le checkout. Git m’oblige à le déplacer ou le supprimer avant de changer de branche.

Le deuxième cas de figure, c’est dans le même ordre d’idées sauf qu’ici j’ai ajouté le fichier à l’index.

Git me demande soit de commit, soit de stash (on verra un peu plus loin cette commande). Dans les opérations de changement de branche, Git veille toujours à ce qu’aucune modification de fichier ne soit perdue.

Le conseil que je peux te donner, c’est de toujours lire le retour de Git et de comprendre le message. Dans la plupart des cas Git te dira quoi faire pour résoudre le problème.

Il peut arriver de vouloir supprimer des branches lorsque le travail peut être totalement supprimé ou alors pour faire du nettoyage. C’est la commande git branch avec le drapeau -d (pour delete) que j’utilise pour effectuer cette tâche.

Git te protège de la perte de données, c’est pour cela que dans certains cas il peut empêcher la suppression de branche. Voilà le genre de message que tu pourrais avoir si cela arrive un jour.

Deux possibilités. Fusionner la branche ou alors forcer la suppression en remplaçant -d par -D. Je ne te recommande pas de forcer la suppression sauf si tu es sûr de ce que tu fais.

Le plus tôt possible dès que tu maîtrises la fusion de branches (le prochain chapitre). Que tu travailles seul ou en équipe, utiliser rapidement les branches t’offrira plus de possibilités, entre autres pour isoler le développement de feature, faire des tests de fonctionnalité, préparer des releases, faire du déploiement continu.