Les idées fusent

Avant d'aller plus loin dans la découverte de nouvelles fonctionnalités de Git comme la création et la gestion des branches, j'aimerais vous parler d'un problème que vous risquez de rencontrer à partir du moment où vous gérez plusieurs fichiers avec un logiciel de gestion de versions et que l'effervescence de la création part un peu dans tous les sens. Autant dire que cela vous arrivera tôt ou tard.

Plutôt que de me lancer dans un discours théorique ennuyeux, je préfère vous faire une petite démonstration pratique.

Semer la pagaille dans son dépôt Git

Créez un répertoire formation-git/atelier-11/hello. Initialisez un projet Git à l'intérieur de ce répertoire :

$ cd ~/formation-git/
$ mkdir -pv atelier-11/hello
mkdir: created directory 'atelier-11'
mkdir: created directory 'atelier-11/hello'
$ cd atelier-11/hello/
$ git init
Initialized empty Git repository in .../formation-git/atelier-11/hello/.git/

Créez un script hello.sh et éditez-le comme ceci :

#!/bin/bash
#
# hello.sh

echo "Hello world !"

Enregistrez le script et rendez-le exécutable :

$ chmod +x hello.sh

Exécutez-le pour le fun :

$ ./hello.sh
Hello world !

Ajoutez-le à votre projet :

$ git add hello.sh
$ git commit -m "Ajout d'un script qui dit bonjour"
[master (root-commit) 9e5640a] Ajout d'un script qui dit bonjour
1 file changed, 7 insertions(+)
create mode 100755 hello.sh

Et là, l'inspiration vous frappe. Une idée pour un script plus élaboré.

Une vache qui dit bonjour !

 _____________________
< Quelle bonne idée ! >
 ---------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Vous commencez aussitôt à éditer le premier jet du script hello-cow.sh qui ressemble à ceci :

#!/bin/bash
#
# hello-cow.sh

if [ -x /usr/bin/cowsay ]
then
  cowsay "Hello world !"
else
  # Que faire si Cowsay n'est pas installé ? Hmmm.
fi

Vous êtes au beau milieu de l'édition du script hello-cow.sh quand une autre idée vous traverse la tête. C'est que vous avez oublié d'ajouter un code retour dans le script hello.sh. Vous ouvrez ce fichier et vous l'éditez pour ajouter une ligne :

#!/bin/bash
#
# hello.sh

echo "Hello world !"

exit 0

Vous voilà donc avec un script modifié hello.sh et un script inachevé hello-cow.sh dans votre répertoire de travail. Pour l'instant, seul hello.sh est suivi :

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified: hello.sh

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        hello-cow.sh

no changes added to commit (use "git add" and/or "git commit -a")

Dans ce cas vous pouvez très bien valider les seules modifications faites à hello.sh :

$ git add hello.sh
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified: hello.sh

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        hello-cow.sh

$ git commit -m "Ajout d'un code retour"
[master f21367d] Ajout d'un code retour
1 file changed, 2 insertions(+)

Maintenant, vous vous dites qu'il est temps d'ajouter hello-cow.sh au projet, même s'il est inachevé :

$ git add hello-cow.sh

Au moment où vous effectuez cette opération, vous vous dites que ce serait quand-même bien d'espacer l'affichage de hello.sh. Vous ouvrez le fichier et vous l'éditez comme ceci :

#!/bin/bash
#
# hello.sh

echo
echo "Hello world !"
echo

exit 0

Dans l'état actuel des choses, ces modifications ne seront pas prises en compte :

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file: hello-cow.sh

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified: hello.sh

Vous les ajoutez donc à l'index :

$ git add hello.sh
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file: hello-cow.sh
        modified: hello.sh

Et vous voilà avec un joli bazar de modifications en vrac :

• un fichier hello.sh avec les dernières améliorations

• un fichier inachevé hello-cow.sh

Et maintenant ?

Le problème ici, c'est que chacun de vos commits est basé sur le commit précédent. Tous ces commits s'enchaînent comme autant de petites ampoules sur une guirlande de noël. Dans ce cas, ce n'est pas évident de travailler avec les idées qui fusent et qui partent dans tous les sens.

Le même problème dans le quotidien d'un développeur

Imaginez que vous travaillez sur une application professionnelle. Vous avez une idée pour une nouvelle fonctionnalité, et vous commencez à modifier le code source de l'application pour implémenter vos idées. Vous êtes en plein travail quand tout à coup votre chef d'équipe vous demande de corriger un bug dans la version de production de l'application. Vous cherchez un peu, vous corrigez le bug en question, vous enregistrez les modifications dans Git... et tout d'un coup vous vous retrouvez avec une forêt de nouveaux bugs, puisque votre dernier commit a également intégré le code expérimental sur lequel vous étiez en train de travailler juste avant de corriger le bug.

Heureusement pour nous, Git offre une fonctionnalité fort pratique pour gérer un travail de développement au gré de votre inspiration et des exigences du jour : les branches.