Défaire des modifications en cours
Commençons par voir ce qu'on peut défaire en phase de préparation de commit, c'est-à-dire les actions qu'on mène entre notre copie de travail et l'index.
La solution classique pour défaire un travail en cours est souvent… un bon Ctrl-Z dans notre éditeur, mais ça peut parfois s'avérer long et fastidieux, voire impossible quand on a fermé les fichiers dans lesquels on veut défaire les modifications.
Dans ce cas, git checkout vole à notre secours et nous permet de venir « annuler » nos modifications dans notre copie de travail, voire même dans l'index si on y avait ajouté des modifs.
Je fais un petit aparté pour vous signaler l'emploi du double tiret avant les chemins de fichiers. On retrouve régulièrement cette notation qui n'est pas propre à Git et qui s'appelle le double tiret POSIX. Elle vise à signaler que tout ce qui se situe après désigne forcément des chemins, de manière à éviter toute confusion avec des options ou identifiants dans le cas de Git. On le retrouve régulièrement dans les documentations Git et dans nos exemples, donc ne soyez pas perturbé·e, ça marche aussi souvent sans les mettre.
Revenons à checkout : il est important de savoir que checkout n'effectue pas exactement une annulation mais un écrasement puisque cette commande prend un état depuis notre base de données Git et vient l'appliquer dans notre copie de travail. L'état qui est appliqué par défaut est celui référencé par l'index, et dans ce cas seule la copie de travail est impactée. Dans les autres cas, c’est-à-dire quand on précise la révision depuis laquelle on souhaite récupérer et appliquer l'état, on impacte l'index et la copie de travail. C'est d'ailleurs ce qui se passe lorsqu'on « change » de branche, mais ce n’est pas le sujet de ce cours…
Une dernière fois j'insiste sur le fait que checkout écrase la version courante des fichiers désignés. Il s'agit ici d'une des très rares situations où l'on perd du travail car Git n'a à aucun moment enregistré une version des fichiers concernés. On est donc prévenus, on ne pourra pas retrouver ces modifications !
La solution classique pour défaire un travail en cours est souvent… un bon Ctrl-Z dans notre éditeur, mais ça peut parfois s'avérer long et fastidieux, voire impossible quand on a fermé les fichiers dans lesquels on veut défaire les modifications.
Dans ce cas, git checkout vole à notre secours et nous permet de venir « annuler » nos modifications dans notre copie de travail, voire même dans l'index si on y avait ajouté des modifs.
Je fais un petit aparté pour vous signaler l'emploi du double tiret avant les chemins de fichiers. On retrouve régulièrement cette notation qui n'est pas propre à Git et qui s'appelle le double tiret POSIX. Elle vise à signaler que tout ce qui se situe après désigne forcément des chemins, de manière à éviter toute confusion avec des options ou identifiants dans le cas de Git. On le retrouve régulièrement dans les documentations Git et dans nos exemples, donc ne soyez pas perturbé·e, ça marche aussi souvent sans les mettre.
Revenons à checkout : il est important de savoir que checkout n'effectue pas exactement une annulation mais un écrasement puisque cette commande prend un état depuis notre base de données Git et vient l'appliquer dans notre copie de travail. L'état qui est appliqué par défaut est celui référencé par l'index, et dans ce cas seule la copie de travail est impactée. Dans les autres cas, c’est-à-dire quand on précise la révision depuis laquelle on souhaite récupérer et appliquer l'état, on impacte l'index et la copie de travail. C'est d'ailleurs ce qui se passe lorsqu'on « change » de branche, mais ce n’est pas le sujet de ce cours…
Une dernière fois j'insiste sur le fait que checkout écrase la version courante des fichiers désignés. Il s'agit ici d'une des très rares situations où l'on perd du travail car Git n'a à aucun moment enregistré une version des fichiers concernés. On est donc prévenus, on ne pourra pas retrouver ces modifications !