Les bases des branches

Introduction

Imaginez que vous écrivez une histoire. Vous arrivez à un moment où l’intrigue peut prendre deux directions différentes : le héros combat le dragon ou se lie d’amitié avec lui. Vous voulez écrire les deux versions pour voir laquelle est la meilleure, mais vous ne voulez pas modifier votre manuscrit principal.

Avec Git, le branching, c’est-à-dire la gestion des branches, vous permet de faire exactement cela. Git crée une ligne de développement parallèle dans laquelle vous pouvez expérimenter en toute sécurité. Les branches sont l’un des concepts les plus importants de Git, car elles permettent de travailler séparément de manière simple et peu coûteuse.

Dans Git, une branche n’est pas une copie complète du projet. Il s’agit principalement d’un pointeur déplaçable vers une suite de commits. C’est pourquoi la création de branches est rapide et légère.

1. Développer des fonctionnalités : créer un nouveau système de connexion dans un espace séparé.
2. Expérimenter : essayer une nouvelle idée de design sans casser le site actuel.
3. Corriger des bugs : corriger une erreur critique de manière isolée.

Dans cet atelier, vous allez créer une chronologie parallèle (une branche), y effectuer des modifications, puis revenir à la chronologie principale afin de vérifier que vos expérimentations n’ont pas modifié le projet d’origine.

Créer une branche de fonctionnalité

Par défaut, chaque dépôt Git commence avec une branche principale, généralement appelée master ou main. Considérez-la comme la « chronologie principale » : la version officielle et stable de votre projet.

Pour travailler sur une nouvelle fonctionnalité, comme une page de connexion, sans compromettre la stabilité du projet principal, vous devez créer une nouvelle branche.

Vérifiez votre emplacement actuel :

git branch

Sortie :

* master

Le symbole * indique que vous vous trouvez actuellement sur la chronologie master.

Ce marqueur indique le contexte de branche actuel. Dans Git, de nombreuses commandes s’appliquent par rapport à la branche vers laquelle pointe HEAD. Il est donc important de savoir où vous vous trouvez.

Créez une nouvelle branche appelée feature_login :

git branch feature_login

Vous venez de créer une nouvelle chronologie ! Cependant, vous ne vous trouvez pas encore dessus.

Cela montre une distinction importante dans Git : créer une branche et basculer vers une branche sont deux actions distinctes. Une branche peut exister sans être votre contexte de travail actuel.

Vérifiez que la branche a été créée :

git branch

Sortie :

  feature_login
* master

La branche feature_login existe, mais le symbole * indique que vous êtes toujours sur master.

Basculer vers la nouvelle branche

Créer une chronologie ne suffit pas : vous devez y accéder. La commande permettant de changer de branche est git checkout.

Basculez vers votre nouvelle branche :

git checkout feature_login

Sortie :

Switched to branch 'feature_login'

Vérifiez que vous avez bien changé de branche :

git branch

Sortie :

* feature_login
  master

L’astérisque (*) a changé de position ! Vous travaillez maintenant dans la chronologie feature_login. Toutes les modifications que vous effectuerez à partir de maintenant seront réalisées uniquement dans cette branche.

Plus précisément, les nouveaux commits créés maintenant feront progresser feature_login, et non master. Les deux branches partagent toujours l’historique précédent, jusqu’au point où elles ont divergé.

Travailler dans la branche de fonctionnalité

Maintenant que vous vous trouvez dans votre espace d’expérimentation sécurisé, écrivez du code. Vous allez créer un script pour notre « fonctionnalité de connexion ».

Créez un fichier appelé login.sh :

echo "echo 'Logging in...'" > login.sh

Vérifiez qu’il existe dans votre dossier :

ls

Vous devez voir README.md (hérité de master) ainsi que le nouveau fichier login.sh.

À ce stade, login.sh est simplement un fichier présent sur votre disque. Pour l’enregistrer officiellement dans l’historique de cette branche, vous devez créer un commit.

Cela renforce le concept de branche : les fichiers apparaissent dans votre arbre de travail, mais l’historique d’une branche ne change que lorsque vous créez des commits sur cette branche.

Valider les modifications dans la branche

Enregistrez votre travail. Souvenez-vous du flux de travail Git standard : Initialiser -> Préparer -> Valider.

Vérifiez l’état du dépôt :

git status

login.sh apparaît comme fichier non suivi (Untracked).

Ajoutez le fichier à la zone de préparation :

git add login.sh

Validez le fichier dans l’historique de feature_login :

git commit -m "Add login feature script"

Sortie :

[feature_login 8a2b3c] Add login feature script

Vous avez maintenant enregistré définitivement cette modification, mais uniquement dans la chronologie feature_login.

Cette isolation explique pourquoi les branches sont si utiles. Elles vous permettent de développer, de tester ou d’expérimenter sans faire progresser la branche principale tant que vous n’êtes pas prêt.

Vérifier l’isolation des branches

C’est le moment clé. Nous affirmons que feature_login constitue un univers distinct de master. Vérifions-le en revenant sur master.

Basculez vers la branche master :

git checkout master

Sortie :

Switched to branch 'master'

Affichez vos fichiers :

ls

Où se trouve login.sh ? Il a disparu !

C’est exactement le résultat attendu. Le fichier login.sh n’existe pas dans la chronologie master. Votre expérimentation est correctement isolée.

Pour vérifier qu’il n’a pas été perdu définitivement, revenez à votre branche de fonctionnalité :

git checkout feature_login
ls

Le fichier est de nouveau présent ! Git remplace instantanément les fichiers de votre répertoire lorsque vous passez d’une chronologie à l’autre.

Résumé

Dans cet atelier, vous avez découvert la puissance des branches :

1. Sécurité : vous pouvez développer de nouvelles fonctionnalités dans une branche distincte (feature_login) sans risquer de modifier le code principal (master).
2. Changement de contexte : vous avez utilisé git checkout pour passer d’une chronologie parallèle à l’autre.
3. Isolation : vous avez vérifié que les modifications validées dans une branche n’apparaissent pas dans une autre.

C’est ainsi que travaillent les équipes professionnelles. Les développeurs créent une branche pour chaque nouvelle fonctionnalité ou correction de bug, afin de conserver une base de code principale propre et stable.