Les trois phases du workflow de Git

Sommaire

I. Les états d'un fichier suivi par Git
II. Prise en main de "git status"
III. Suivre de nouveaux fichiers avec Git
IV. Le workflow de Git
V. Combiner l'utilisation de Add et Commit

I. Les états d'un fichier suivi par Git

Le workflow Git passe par trois phases qu'il faut maîtriser avant de commencer à versionner son code source. Les fichiers du répertoire de travail (working directory) d'un projet Git (celui où nous avons initialisé le dépôt) peuvent être dans l'un des trois états suivants :

Non suivi (Untracked) ou Modifié (Modified) :
- Non suivi (Untracked) : un ou plusieurs fichier(s) du répertoire de travail (working directory) ont été créés, mais ils ne sont pas encore suivis par Git).
- Modifiés (Modified) : un ou plusieurs fichier(s) du répertoire de travail (working directory) qui sont déjà enregistrés dans Git à la suite d'un commit ont été modifiés. Ces nouvelles versions des fichiers ne sont pas encore suivies par Git.
En staging (Staged) : un ou plusieurs fichier(s) du répertoire de travail ont été ajoutés (staged) avec la commande git add et sont maintenant suivis (tracked) par Git. Dans cet état, ces fichiers sont prêts à être enregistrés (commited ou « commités » ) dans Git.
Enregistré (Commited ou « commité ») : le ou les fichiers ajoutés (staged) à l'étape précédente sont enregistrés (commited ou « commités ») dans la base de données de Git (sous /.git) avec la commande git commit qui crée un snapshot des changements.

Pour mieux comprendre ces trois états, prenons l'exemple d'une photo de famille :

Vous êtes photographe et vous devez prendre des photos d'une famille : vous avez devant vous les membres de la famille. Cette situation correspond à l'état non suivi : des personnes sont placées dans votre espace de travail (i.e. vous avez des nouveaux fichiers et/ou modifications dans votre répertoire de travail).
Vous choisissez, par exemple, les parents seulement pour la première photo et vous les positionnez correctement avant de prendre le cliché. C'est l'étape du staging (ou mise en scène), seules quelques personnes sont retenues pour faire partie de la photo (i.e. vous sélectionnez certains fichiers qui contiennent les modifications désirées et vous les placez dans l'espace de staging).
Lorsque la sélection est complétée, vous prenez la photo ou snapshot que vous conservez sur la mémoire de l'appareil (i.e. vous faites un commit qui enregistre le contenu de l'espace de staging de manière persistante sur votre poste de travail).

Si vous n'êtes pas satisfait de la photo, vous pouvez recommencer et faire une nouvelle mise en scène des parents et reprendre une photo. Vous pouvez recommencer ces étapes autant que vous voulez en sélectionnant les personnes désirées (ou toute la famille) et vous aurez toujours la possibilité de revenir à une photo antérieure si la dernière ne vous convient pas.

Voyons maintenant comment ce workflow fonctionne concrètement dans Git en ajoutant du contenu à notre répertoire de travail.

II. Prise en main de "git status"

C'est l'occasion d'introduire la commande « git status » qui, comme son nom l'indique, affiche le statut ou l'état des fichiers dans Git. C'est l'une des commandes les plus utilisées dans Git, donc la première à mémoriser.

Commençons par créer deux fichiers que nous retrouvons très souvent dans des dépôts Git : « README.md » et « .gitignore ». Nous reviendrons plus loin sur le rôle de ces deux fichiers.

# Créer deux fichiers
$ touch README.md .gitignore

Ces nouveaux fichiers se trouvent dans le répertoire du projet mais ne sont pas encore suivis par Git. Dans VS Code, nous pouvons voir qu'un « U » s'est ajouté à la suite des fichiers, ce qui signifie qu'ils sont untracked (non suivis) :

Nous travaillons ici avec VS Code, mais retenez que vous aurez toujours l'équivalent en ligne de commande avec git status que ce soit directement dans Git Bash ou lorsque vous l'utilisez dans PowerShell.

Il existe plusieurs paramètres pour la commande « git status », mais les deux cas d'utilisation les plus courants sont : version longue (verbose) ou courte (sortie abrégée) :

# Version longue
$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        README.md

# Version courte
$ git status -s
?? .gitignore
?? README.md

Dans le premier cas, le « U » (dans VS Code) est désigné littéralement par « Untracked files », tandis que la version courte utilise deux points d'interrogation (« ?? ») pour indiquer que les fichiers ne sont pas encore suivis (tracked) par Git.

III. Suivre de nouveaux fichiers avec Git

Pour que ces fichiers soient suivis par Git, nous devons les faire passer du répertoire de travail à l'espace de staging. Dans l'exemple qui suit, nous allons placer uniquement le README.md en staging (comme les parents que nous avons choisis de mettre en scène pour la photo). Cette opération se fait avec la commande « git add ».

Voyons ce que fait cette commande et ce qu'indique la commande git status par la suite :

# Commande git add
$ git add README.md

# git status version longue
git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md

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

Nous pouvons constater que la mention « Changes to be commited » s'est ajoutée pour le fichier « README.md », ce qui signifie que le fichier a été ajouté à l'espace de staging et qu'il pourrait être enregistré ou « commité » dans Git.

Dans VS Code, nous voyons qu'un « A » (pour « ajouté ») a remplacé le « U » à droite du fichier « README.md » (comme dans la version courte de git status). Notons aussi que Git nous indique qu'il y a un fichier non suivi (« Untracked file ») qui correspond au « .gitignore » que nous n'avons pas ajouté encore à l'espace de staging.

# Commande git status version courte
$ git status -s
A  README.md

Une fois que nos fichiers sont ajoutés dans l'espace de staging, nous pouvons faire un commit (snapshot) pour les enregistrer de manière persistante. Cette opération se fait avec la commande git commit suivie obligatoirement du paramètre « -m » (« message ») pour permettre aux utilisateurs d'identifier les modifications qu'ils ont apportées à un fichier dans le temps.

Il est important de prendre le temps d'écrire un message de commit qui soit précis et facile à retrouver par la suite. Il peut aussi être pertinent lorsque vous travaillez en équipe de s'entendre sur une nomenclature à respecter dans les messages commits comme : « Bug fix », « Hot fix », « Feature » et d'adopter une méthode comme le « Semantic versioning » (https://semver.org/) pour indiquer les numéros de versions du code source.

# Commande git commit 
$ git commit -m "Commit initial"
[master (root-commit) 443dfe5] Commit initial
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 README.md

Voyons maintenant ce que va indiquer la commande « git status » :

# Commande git status version longue
$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore

nothing added to commit but untracked files present (use "git add" to track)

Il n'y a plus rien dans l'espace de staging puisque nous venons de faire un commit. Dans VS Code, le fichier « README.md » n'est plus suivi d'une lettre indiquant son statut, car il est stocké en mémoire sous « .git ». Encore une fois, il est mentionné qu'il reste des fichiers non suivis (untracked), ce qui est normal parce que nous n'avons pas encore fait de « git add » pour ajouter le fichier « .gitignore » dans l'espace de staging.

Nous avons mentionné plus haut qu'un fichier dans le répertoire de travail peut être non suivi (untracked) ou modifié. Ce dernier état est possible lorsqu'un fichier a déjà été enregistré (« commité ») dans Git et que vous le modifiez ultérieurement. Insérez du texte dans votre fichier « README.md » et ajoutez-le à nouveau dans l'espace de staging avec la commande « git add » :

Nous voyons qu'un « M » pour « modified » (modifié) s'est ajouté pour désigner l'état du fichier « README.me ». Il y a donc deux états possibles pour le contenu du répertoire de travail : non suivi ou modifié.

Vous pouvez pratiquer les étapes précédentes en ajoutant le fichier .gitignore dans votre dépôt Git : comme ce fichier est non suivi, il le deviendra avec la commande « git add », puis il sera ajouté au dépôt Git avec « git commit ».

IV. Le workflow de Git

En résumé, le workflow Git comporte trois phases ou sections :

Répertoire de travail (working Directory) : espace où les fichiers sont créés ou modifiés.
Espace de staging (staging area) ou index : espace (tampon) où les fichiers sont sélectionnés pour être enregistrés.
Répertoire .git ou Git Repository : espace où les fichiers sont enregistrés de manière persistante.

Lorsque le commit est complété, Git effectue automatiquement un checkout, c'est-à-dire qu'il met à jour l'espace de travail à la dernière version qui vient d'être enregistrée dans la branche en cours (ici : « main »). Voici une illustration de ce workflow (en prenant pour acquis qu'il s'agit d'un dépôt qui contient déjà quelques commits, d'où le checkout initial) :

Nous avons vu la commande « git add » pour l'ajout d'un fichier spécifique, mais si vous souhaitez ajouter tous les fichiers et/ou modifications dans l'espace de staging, vous pouvez le faire de deux manières :

# Commande git add pour ajouter l'entièreté du contenu du répertoire de travail
$ git add -A
# ou
$ git add .

Prenez l'habitude d'exécuter la commande « git status » régulièrement pour connaître l'état des fichiers que vous créez et/ou éditez.

V. Combiner l'utilisation de Add et Commit

Vous pouvez aussi faire toutes les étapes en une seule commande, en combinant « add » et « commit » de la manière suivante :

# Combiner git add et git commit en une seule commande
$ git commit -a -m "Ajout modifications"
[main eede2d4] Ajout modifications
 1 file changed, 1 insertion(+)
# ou
$ git commit -am "Ajout modifications"
[main eede2d4] Ajout modifications
 1 file changed, 1 insertion(+)

Il peut arriver que vous ayez oublié les modifications que vous avez apportées à votre répertoire de travail et que vous souhaitez les consulter avant de faire un « git add » pour les ajouter dans l'espace de staging. Dans ce cas, vous pouvez utiliser la commande « git diff » qui vous permettra de voir ce qui a été modifié avant de procéder.

En voici un exemple où la ligne « Ajout de texte pour faire un git diff » a été ajoutée au fichier « README.md » alors que le contenu initial du fichier était "# Ceci est un fichier README pour le projet git-test" :

# Commande git diff
git diff
diff --git a/README.md b/README.md
index c5af905..55ddbb2 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
 # Ceci est un fichier README pour le projet git-test

 Ajout de texte pour faire un git diff

La sortie indique que Git a consulté son index pour comparer le contenu du dernier commit avec les modifications du répertoire de travail pour afficher les différences. Lorsque vous ferez un « git add », la commande « git diff » ne retournera rien parce que vous avez ajouté le contenu du répertoire de travail en vue d'un commit.

Si vous souhaitez annuler la commande « add », c'est-à-dire retirer le contenu de l'espace de staging, vous avez pouvez utiliser la commande « git reset » qui offre deux options :

# Retirer un fichier spécifique de l'espace de staging
$ git reset nom_du_fichier

# Retirer tout le contenu de l'espace de staging
$ git reset

Ces deux commandes vont faire un unstaging, mais elles ne supprimeront pas les fichiers et/ou modifications du répertoire de travail. Pour retirer les modifications dans les deux emplacements, vous pouvez utiliser la commande « git rm » :

# Retirer un fichier spécifique de l'espace de staging et du répertoire de travail
$ git rm <nom_du_fichier>

# Retirer tout le contenu de l'espace de staging et du répertoire de travail
$ git rm  *

L'annulation d'un commit sera abordée dans la prochaine section.

Voici un petit récapitulatif des commandes que nous avons vues depuis le début de ce cours :

# Récapitulatif des commandes de base

git init      Créer un nouveau répertoire .git local pour faire le suivi de changements
git add       Déplacer un (ou plusieurs) fichier(s) ou modifications dans l'espace de staging
git status    Faire afficher le statut des fichiers dans Git
git commit    Créer un snapshot des changements (contenu de l'espace de staging) et les conserver dans la base de données .git
git diff      Faire afficher les changements entre le répertoire de travail et l'espace de staging

Module Précédent

Retour au Module

Chapitre Suivant

Luc BRETON Administrateur système et cloud

Administrateur système et cloud avec une orientation DevOps pour une grande chaîne de pharmacies québécoise. Je suis plutôt généraliste avec une forte expérience côté virtualisation, stockage, cloud hybride et un intérêt particulier pour l'automatisation. J'aime le transfert de connaissances et il me fait plaisir d'être la première voix nord-américaine d'IT-Connect !

See Full Bio