Pour ne défaire que l’index suite à des ajouts nous devrons utiliser une autre commande, celle que nous suggérait git status il y a quelques instants, la commande git reset. Tout comme la commande checkout, reset peut prendre des chemins en paramètres qui sont en fait des globs. L’utiliser revient à dire à l'index de ne plus référencer les photos pour les chemins demandés. On peut aussi ne passer aucun paramètre auquel cas l’ensemble des ajouts à l’index seront défaits.

Il s’agit ici du seul cas d’utilisation de reset sur fichiers et qu’on pourrait renommer virtuellement "unindex" ou "unstage". Ça nous permettrait aussi de différencier cette utilisation de celles que nous verrons plus tard.

Enfin, parlons d'un autre cas particulier : celui du tout premier commit de notre historique projet, appelé "root commit". Lorsqu'on veut défaire l’index, Git n’a pas de référence dans sa base de données puisqu’aucun commit n’a été effectué sur le projet. La commande reset ne peut donc pas agir et on devra passer par un autre mécanisme qui consiste à dire à Git de simplement retirer la photo de l’index. C’est le rôle de la commande git rm et de son option --cached.

Notez également que dans Git, les options --cached ou --staged ont toujours trait à l’index, car le nom de l’index a varié dans le temps et on l’a connu sous des appellations comme “cache”, “stage” et “staging area”. Il est donc fréquent de retrouver ces noms historiques sous forme d’options de commande, comme ici avec git rm --cached.

Si on reprend notre base d’exemple animée utilisée précédemment, avec un fichier qu’on modifie et qu’on ajoute à l’index, on voit que l’action d’un reset sur ce fichier vient écraser la référence dans l’index en prenant la dernière version connue dans le dépôt local.

Si on reprend notre terminal, on voit à l’aide d’un git status que des fichiers modifiés ont été indexés. On l’avait vu précédemment, git status nous donne la marche à suivre : « utilisez "git reset HEAD <fichier>..." pour désindexer ».

On va donc suivre son conseil et désindexer nos deux fichiers : git reset HEAD fichier-1 sous-repertoire/fichier-3.

On vérifie avec un git status : nos deux fichiers sont bien revenus à l’état modifié dans la copie de travail, donc en rouge dans mon terminal.

Défaire un ajout seulement dans l’index

En revanche, pour un fichier qui n’existe pas dans la version courante du dépôt local et qui sera donc considéré comme une création, une fois ajouté à l’index, reset n’est pas utilisable. Comme pour un “root commit”, c’est un git rm --cached qui nous permettra de le sortir de l’index, mais pas de la copie de travail.

(Exemple 04-rm-cached)

On retourne dans notre terminal. On est dans un exemple de projet tout beau, tout neuf et surtout sans historique existant comme nous l’indique une tentative d’affichage du log.

On fait comme à notre habitude un git status. Celui-ci nous montre un fichier nommé de manière très originale « mon-fichier » et qui a été ajouté à l’index. Comme précédemment la procédure nous est décrite par git status : « utilisez "git rm --cached <fichier>..." pour désindexer ».

On s’exécute et on constate avec un dernier git status que notre fichier est toujours présent dans notre copie de travail avec un état « non-suivi ».