7.7 Utilitaires Git - Reset démystifié

Le moyen le plus simple de penser à reset et checkout consiste à représenter Git comme un gestionnaire de contenu de trois arborescences différentes. Par « arborescence », il faut comprendre « collection de fichiers », pas spécifiquement structure de données. Il existe quelques cas pour lesquels l’index ne se comporte pas exactement comme une arborescence, mais pour ce qui nous concerne, c’est plus simple de l’imaginer de cette manière pour le moment.

Git, comme système, gère et manipule trois arbres au cours de son opération normale :

L’objet principal de Git est d’enregistrer des instantanés de votre projet comme des états successifs évolutifs en manipulant ces trois arbres.

Visualisons ce processus : supposons que vous allez dans un nouveau répertoire contenant un fichier unique. Nous appellerons ceci v1 du fichier et nous le marquerons en bleu. Maintenant, nous allons lancer git init, ce qui va créer le dépôt Git avec une référence HEAD qui pointe sur une branche à naître (master n’existe pas encore).

À ce point, seul le répertoire de travail contient quelque chose.

Maintenant, nous souhaitons valider ce fichier, donc nous utilisons git add qui prend le contenu du répertoire de travail et le copie dans l’index.

Ensuite, nous lançons git commit, ce qui prend le contenu de l’index et le sauve comme un instantané permanent, crée un objet commit qui pointe sur cet instantané et met à jour master pour pointer sur ce commit.

Si nous lançons git status, nous ne verrons aucune modification parce que les trois arborescences sont identiques.

Maintenant, nous voulons faire des modifications sur ce fichier et le valider. Nous suivons le même processus ; en premier nous changeons le fichier dans notre copie de travail. Appelons cette version du fichier v2 et marquons-le en rouge.

Si nous lançons git status maintenant, nous verrons le fichier en rouge comme « Modifications qui ne seront pas validées » car cette entrée est différente entre l’index et le répertoire de travail. Ensuite, nous lançons git add dessus pour le monter dans notre index.

À ce point, si nous lançons git status, nous verrons le fichier en vert sous « Modifications qui seront validées » parce que l’index et HEAD diffèrent, c’est-à-dire que notre prochain commit proposé est différent de notre dernier commit. Finalement, nous lançons git commit pour finaliser la validation.

Maintenant, git status n’indique plus rien, car les trois arborescences sont à nouveau identiques.

Les basculements de branches ou les clonages déroulent le même processus. Quand vous extrayez une branche, cela change HEAD pour pointer sur la nouvelle référence de branche, alimente votre index avec l’instantané de ce commit, puis copie le contenu de l’index dans votre répertoire de travail.

La commande reset est plus compréhensible dans ce contexte.

Pour l’objectif des exemples à suivre, supposons que nous avons modifié file.txt à nouveau et validé une troisième fois. Donc maintenant, notre historique ressemble à ceci :

Détaillons maintenant ce que reset fait lorsque vous l’appelez. Il manipule directement les trois arborescences d’une manière simple et prédictible. Il réalise jusqu’à trois opérations basiques.

Tout cela couvre le comportement de reset dans sa forme de base, mais vous pouvez aussi lui fournir un chemin sur lequel agir. Si vous spécifiez un chemin, reset sautera la première étape et limitera la suite de ses actions à un fichier spécifique ou à un ensemble de fichiers. Cela fait sens ; en fait, HEAD n’est rien de plus qu’un pointeur et vous ne pouvez pas pointer sur une partie d’un commit et une partie d’un autre. Mais l’index et le répertoire de travail peuvent être partiellement mis à jour, donc reset continue avec les étapes 2 et 3.

Donc, supposons que vous lancez git reset file.txt. Cette forme (puisque vous n’avez pas spécifié un SHA-1 de commit ni de branche, et que vous n’avez pas non plus spécifié --soft ou --hard) est un raccourci pour git reset --mixed HEAD file.txt, qui va :

Donc, en substance, il ne fait que copier file.txt de HEAD vers index.

Ceci a l’effet pratique de désindexer le fichier. Si on regarde cette commande dans le diagramme et qu’on pense à ce que git add fait, ce sont des opposés exacts.

C’est pourquoi le résultat de la commande git status suggère que vous lanciez cette commande pour désindexer le fichier (voir Désindexer un fichier déjà indexé pour plus de détail).

Nous pourrions tout aussi bien ne pas laisser Git considérer que nous voulions dire « tirer les données depuis HEAD » en spécifiant un commit spécifique d’où tirer ce fichier. Nous lancerions juste quelque chose comme git reset eb43bf file.txt.

Ceci fait effectivement la même chose que si nous remettions le contenu du fichier à la v1 dans le répertoire de travail, lancions git add dessus, puis le ramenions à nouveau à la v3 (sans forcément passer par toutes ces étapes). Si nous lançons git commit maintenant, il enregistrera la modification qui remet le fichier à la version v1, même si nous ne l’avons jamais eu à nouveau dans notre répertoire de travail.

Il est intéressant de noter que comme git add, la commande reset accepte une option --patch pour désindexer le contenu section par section. Vous pouvez donc sélectivement désindexer ou ramener du contenu.

Voyons comment faire quelque chose d’intéressant avec ce tout nouveau pouvoir - écrasons des commits.

Supposons que vous avez une série de commits contenant des messages tels que « oups », « en chantier » ou « ajout d’un fichier manquant ». Vous pouvez utiliser reset pour les écraser tous rapidement et facilement en une seule validation qui vous donne l’air vraiment intelligent (Écraser un commit explique un autre moyen de faire pareil, mais dans cet exemple, c’est plus simple de faire un reset).

Disons que vous avez un projet où le premier commit contient un fichier, le second commit a ajouté un nouveau fichier et a modifié le premier, et le troisième a remodifié le premier fichier. Le second commit était encore en chantier et vous souhaitez le faire disparaître.

Vous pouvez lancer git reset --soft HEAD~2 pour ramener la branche de HEAD sur l’ancien commit (le premier commit que vous souhaitez garder) :

Ensuite, relancez simplement git commit :

Maintenant vous pouvez voir que votre historique accessible, l’historique que vous pousseriez, ressemble à présent à un premier commit avec le fichier file-a.txt v1, puis un second qui modifie à la fois file-a.txt à la version 3 et ajoute file-b.txt. Le commit avec la version v2 du fichier ne fait plus partie de l’historique.

Finalement, vous pourriez vous demander quelle différence il y a entre checkout et reset. Comme reset, checkout manipule les trois arborescences et se comporte généralement différemment selon que vous indiquez un chemin vers un fichier ou non.

J’espère qu’à présent vous comprenez mieux et vous sentez plus à l’aise avec la commande reset, même si vous pouvez vous sentir encore un peu confus sur ce qui la différencie exactement de checkout et avoir du mal à vous souvenir de toutes les règles de ses différentes invocations.

Voici un aide-mémoire sur ce que chaque commande affecte dans chaque arborescence. La colonne « HEAD » contient « RÉF » si cette commande déplace la référence (branche) pointée par HEAD, et « HEAD » si elle déplace HEAD lui-même. Faites particulièrement attention à la colonne « préserve RT ? » (préserve le répertoire de travail) – si elle indique NON, réfléchissez à deux fois avant de lancer la commande.