git reset

La première arborescence que nous étudierons est « le répertoire de travail ». Cette arborescence est synchronisée avec le système de fichiers local. Elle est représentative des changements immédiats apportés au contenu des fichiers et des répertoires.

Dans notre dépôt de démonstration, nous modifions le fichier reset_lifecycle_file et y ajoutons du contenu. Appeler git status montre que Git est conscient des changements apportés au fichier. Ces changements font actuellement partie de la première arborescence : « Le répertoire de travail ». La commande git status peut être utilisée pour afficher les changements apportés au répertoire de travail. Ils seront affichés en rouge avec un préfixe 'modified'.

Vient ensuite l'arborescence de l'« index de staging ». Cette arborescence procède au suivi des changements du répertoire de travail associés à l'action git add, à stocker dans le commit suivant. Cette arborescence constitue un mécanisme de mise en cache interne complexe. Git tente généralement de masquer à l'utilisateur les détails de mise en œuvre de l'index de staging.

Afin d'afficher l'état de l'index de staging, nous devons utiliser une commande Git moins connue : git ls-files. La commande git ls-files est principalement un utilitaire de débogage permettant de vérifier l'état de l'arborescence de l'index de staging.

Nous avons exécuté git ls-files avec l'option -s ou --stage. Sans l'option -s, la sortie git ls-files est simplement une liste de noms de fichier et de chemins d'accès qui font actuellement partie de l'index. L'option -s affiche des métadonnées supplémentaires pour les fichiers dans l'index de staging. Ces métadonnées sont les bits de mode de contenu stagé, le nom d'objet et le numéro d'indexation. Nous nous intéressons au nom d'objet, la deuxième valeur (d7d77c1b04b5edd5acfc85de0b592449e5303770). Il s'agit d'une empreinte SHA-1 d'objet Git standard. C'est une empreinte d'un contenu des fichiers. L'historique des commits stocke ses propres empreintes SHA d'objet pour identifier des pointeurs vers les commits et les réfs, et l'index de staging dispose de ses propres empreintes SHA d'objet pour suivre les versions des fichiers dans l'index.

Ensuite, nous ferons passer le fichier reset_lifecycle_file modifié dans l'index de staging.

Nous avons appelé git add reset_lifecycle_file qui ajoute le fichier à l'index de staging. Après avoir appelé git status, reset_lifecycle_file s'affiche en vert sous « Changes to be committed ». Il convient de noter que git status n'est pas une vraie représentation de l'index de staging. La sortie de la commande git status affiche les changements entre l'historique des commits et l'index de staging. Examinons le contenu de l'index de staging à ce stade.

Nous pouvons voir que l'objet SHA de reset_lifecycle_file a été mis à jour de e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 vers d7d77c1b04b5edd5acfc85de0b592449e5303770.

L'arborescence finale est l'historique des commits. La commande git commit ajoute des changements à un instantané permanent dans l'historique des commits. Cet instantané contient également l'état de l'index de staging au moment du commit.

Ici, nous avons créé un nouveau commit avec un message "update content of resetlifecyclefile". L'ensemble de changements a été ajouté à l'historique des commits. Appeler git status à ce stade montre qu'il n'y a pas de changements en attente dans les arborescences. L'exécution de git log affichera l'historique des commits. Maintenant que nous avons suivi cet ensemble de changements dans les trois arborescences, nous pouvons commencer à utiliser git reset.

Cet exemple illustre une séquence de commits sur la branche principale (main). Les réfs HEAD et de branche (main) pointent actuellement vers le commit d. Exécutons maintenant git checkout b et git reset b.

Avec git checkout, la réf main pointe toujours vers d. La réf HEAD a été déplacée et pointe désormais vers le commit b. Le dépôt est désormais à l'état « HEAD détaché ».

En comparaison, git reset déplace la réf HEAD et les réfs de branche vers le commit spécifié.

En plus de mettre à jour les pointeurs de réf de commit, git reset modifiera l'état des trois arborescences. La modification du pointeur de réf est systématique et constitue une mise à jour de la troisième arborescence, celle des commits. Les arguments de ligne de commande --soft, --mixed et --hard indiquent comment modifier l'index de staging et les arborescences du répertoire de travail.

Il s'agit de l'option la plus directe, DANGEREUSE et fréquemment utilisée. Lorsque vous transmettez l'argument --hard, les pointeurs de la réf d'historique des commits sont mis à jour au commit spécifié. L'index de staging et le répertoire de travail sont ensuite réinitialisés de sorte qu'ils correspondent à ceux du commit spécifié. Les changements précédemment en attente apportés à l'index de staging et au répertoire de travail sont réinitialisés de sorte qu'ils correspondent à l'état de l'arborescence des commits. Cela signifie que toute tâche en attente qui traînait dans l'index de staging et le répertoire de travail sera perdue.

Pour démontrer cet état de fait, poursuivons avec l'exemple de dépôt à trois arborescences mentionné précédemment. Apportons tout d'abord certains changements au dépôt. Exécutez les commandes suivantes dans l'exemple de dépôt :

Ces commandes ont créé un nouveau fichier intitulé new_file, que nous avons ajouté au dépôt. En outre, le contenu du fichier reset_lifecycle_file sera modifié. Une fois ces changements en place, examinons l'état du dépôt à l'aide de git status.

Nous avons appelé git add reset_lifecycle_file qui ajoute le fichier à l'index de staging. Après avoir appelé git status, reset_lifecycle_file s'affiche en vert sous « Changes to be committed ». Il convient de noter que git status n'est pas une vraie représentation de l'index de staging. La sortie de la commande git status affiche les changements entre l'historique des commits et l'index de staging. Examinons le contenu de l'index de staging à ce stade.

Nous pouvons voir que new_file a été ajouté à l'index. Nous avons effectué des mises à jour sur reset_lifecycle_file, mais l'empreinte SHA de l'index de staging (d7d77c1b04b5edd5acfc85de0b592449e5303770) reste inchangée. Ce comportement est attendu, car git add n'a pas été utilisée pour promouvoir ces changements dans l'index de staging. Ces changements apparaissent dans le répertoire de travail.

Exécutons maintenant une commande git reset --hard et examinons le nouvel état du dépôt.

Nous avons exécuté un « hard reset » à l'aide de l'option --hard. Git affiche une sortie indiquant que HEAD pointe vers le dernier commit dc67808. Nous vérifions ensuite l'état du dépôt avec git status. Git indique qu'aucun changement n'est en attente. Nous examinons également l'état de l'index de staging et nous nous apercevons qu'il a été réinitialisé à un point antérieur à l'ajout de new_file. Les changements apportés à reset_lifecycle_file et l'ajout de new_file ont été supprimés. Il est essentiel de noter que cette perte de données est définitive.

Il s'agit du mode de fonctionnement par défaut. Les pointeurs de réf sont mis à jour. L'index de staging est réinitialisé à l'état du commit spécifié. Les changements annulés depuis l'index de staging sont déplacés vers le répertoire de travail. Continuons.

Dans l'exemple ci-dessus, nous avons apporté certains changements au dépôt. À nouveau, nous avons ajouté un fichier new_file et modifié le contenu de reset_lifecycle_file. Ces changements sont ensuite appliqués à l'index de staging avec git add. Lorsque le dépôt est dans cet état, nous exécutons le reset.

Nous avons exécuté un « reset mixte ». Petit rappel : --mixed est le mode par défaut et a le même effet que l'exécution de la commande git reset. Examiner la sortie de git status et de git ls-files montre que l'index de staging a été réinitialisé à un état où reset_lifecycle_file est le seul fichier dans l'index. L'empreinte SHA d'objet pour reset_lifecycle_file a été réinitialisée à la version précédente.

L'important à retenir est que la commande git status nous montre que certains changements ont été apportés au fichier reset_lifecycle_file et qu'un fichier non tracké existe : new_file. Il s'agit du comportement --mixed explicite. L'index de staging a été réinitialisé, et les changements en attente ont été déplacés vers le répertoire de travail. Comparez cette opération au reset --hard au cours duquel l'index de staging et le répertoire de travail ont été réinitialisés, entraînant la perte de ces mises à jour.

Lorsque l'argument --soft est transmis, les pointeurs de réf sont mis à jour et le reset s'arrête. L'index de staging et le répertoire de travail ne sont pas modifiés. Ce comportement peut s'avérer difficile à démontrer clairement. Poursuivons avec notre dépôt de démonstration et préparons-le pour un soft reset.

Nous avons de nouveau utilisé git add pour promouvoir le fichier reset_lifecycle_file modifié dans l'index de staging. Nous confirmons que l'index a été mis à jour avec la sortie git ls-files. La sortie de git status affiche désormais la partie « Changes to be committed » en vert. Le fichier new_file mentionné dans les exemples précédents se situe dans le répertoire de travail sous forme de fichier non tracké. Exécutons rapidement rm new_file pour supprimer le fichier, étant donné que nous n'en aurons pas besoin pour les exemples suivants.

Lorsque le dépôt présente cet état, nous effectuons un soft reset.

Nous avons exécuté un « soft reset ». L'examen de l'état du dépôt avec git status et git ls-files montre que rien n'a changé. C'est le comportement attendu. Un soft reset réinitialisera uniquement l'historique des commits. Par défaut, la commande git reset est appelée avec HEAD en tant que commit cible. Puisque notre historique des commits se situait déjà sur HEAD et que nous avons implicitement réinitialisé sur HEAD, rien n'a réellement changé.

Pour mieux comprendre et utiliser --soft, nous avons besoin d'un commit cible autre que HEAD. Nous avons reset_lifecycle_file en attente dans l'index de staging. Créons un nouveau commit.

À ce stade, notre dépôt devrait comporter trois commits. Nous allons revenir au premier commit. Pour ce faire, nous allons avoir besoin de l'ID du premier commit. Vous le trouverez en affichant la sortie de git log.

N'oubliez pas que les ID d'historique des commits seront uniques pour chaque système. Les ID de commit dans cet exemple seront donc différents que ceux que vous voyez sur votre machine personnelle. L'ID de commit qui nous intéresse dans le cadre de cet exemple est 780411da3b47117270c0e3a8d5dcfd11d28d04a4. Cet ID correspond au « commit initial ». Lorsque nous aurons trouvé cet ID, nous l'utiliserons comme cible pour notre soft reset.

Avant de retourner dans le passé, commençons par examiner l'état actuel du dépôt.

Nous exécutons ici les deux commandes git status et git ls-files -s qui nous indiquent que des changements sont en attente dans le dépôt et que la version du fichier reset_lifecycle_file dans l'index de staging est 67cc52710639e5da6b515416fd779d0741e3762e. En gardant cela à l'esprit, exécutons un soft reset pour revenir à notre premier commit.

Le code ci-dessus exécute un « soft reset » et appelle également les deux commandes git status et git ls-files qui génère l'état du dépôt. Nous pouvons examiner la sortie de l'état du dépôt et noter certains points intéressants. Tout d'abord, git status indique que des changements sont apportés à reset_lifecycle_file et les met en évidence en précisant qu'il s'agit de changements stagés pour le commit suivant. Ensuite, l'entrée git ls-files indique que l'index de staging n'a pas changé et conserve l'empreinte SHA 67cc52710639e5da6b515416fd779d0741e3762e précédente.

Pour clarifier davantage ce qui s'est produit au cours de cette réinitialisation, examinons git log :

La sortie de log montre désormais que l'historique des commits ne comprend qu'un seul commit. Cela permet d'illustrer clairement l'effet de l'argument --soft. Comme pour tous les appels de git reset, la première action de reset est de réinitialiser l'arborescence des commits. Nos exemples précédents avec --hard et --mixed portaient tous deux sur HEAD et n'ont pas replacé l'arborescence des commits à temps. Au cours d'un soft reset, il ne se passe rien d'autre.

La raison pour laquelle git status indique que des fichiers modifiés existent peut prêter à confusion. L'argument --soft ne touche pas l'index de staging. C'est pourquoi les mises à jour de notre index de staging sont revenues en arrière dans l'historique des commits. Cela peut être confirmé par la sortie de git ls-files -s indiquant que l'empreinte SHA pour reset_lifecycle_file reste inchangée. Pour rappel, git status n'affiche pas l'état des « trois arborescences », elle les compare. Dans ce cas, elle indique que l'index de staging vient avant les changements dans l'historique des commits, comme si nous les avions déjà stagés.

Dès que vous ajoutez de nouveaux commits après le reset, Git pense que votre historique local diverge de la branche origin/main, et le commit de merge requis pour synchroniser vos dépôts risque de perturber votre équipe.

Par conséquent, assurez-vous d'utiliser git reset ＜commit＞ sur une expérience locale qui a mal tourné, et pas sur des changements publiés. Si vous devez corriger un commit public, la commande git revert est spécialement conçue à cet effet.

Supprimez le fichier spécifié dans la zone de staging, mais ne modifiez pas le répertoire de travail. Cette commande permet de stager un fichier sans écraser les changements.

Reset de la zone de staging de sorte qu'elle corresponde au commit le plus récent, sans modifier le répertoire de travail. Cette opération permet de stager tous les fichiers sans écraser les changements, ce qui vous permet de re-builder l'instantané stagé à partir de zéro.

Réinitialisez la zone de staging et le répertoire de travail pour qu'ils correspondent au commit le plus récent. Outre les changements non stagés, le flag --hard demande à Git de remplacer également tous les changements dans le répertoire de travail. Autrement dit : il annule tous les changements non commités, vérifiez donc que vous souhaitez supprimer vos développements locaux avant de l'utiliser.

Faites reculer la pointe de la branche courante pour faire un commit, réinitialisez la zone de staging pour garantir la correspondance et laissez le répertoire de travail seul. Tous les changements apportés depuis ＜commit＞ seront consignés dans le répertoire de travail, qui vous permet de commiter de nouveau l'historique du projet à l'aide d'instantanés plus clairs et plus atomiques.

Faitez reculer la pointe de la branche courante vers ＜commit＞ et faites un reset de la zone de staging et du répertoire de travail à des fins d'alignement. Non seulement cette action supprime les changements non commités, mais aussi tous les commits suivants.

La commande git reset est fréquemment rencontrée lors de la préparation de l'instantané stagé. L'exemple suivant part du principe que vous avez deux fichiers appelés hello.py et main.py que vous avez déjà ajoutés au dépôt.

Comme vous pouvez le voir, git reset vous aide à maintenir une forte concentration de vos commits en vous permettant d'annuler le staging des changements qui ne sont pas liés au commit suivant.

L'exemple suivant illustre une utilisation plus avancée. Il montre ce qui arrive lorsque vous avez travaillé sur un nouveau projet pendant un temps et que vous décidez de tout abandonner après avoir intégré certains instantanés à des commits.

La commande git reset HEAD~2 recule la branche courante de deux commits, ce qui supprime les deux instantanés que nous venons de créer à partir de l'historique du projet. N'oubliez pas que ce genre de réinitialisation ne devrait être utilisé que sur les commits non publiés. N'effectuez jamais l'opération ci-dessus si vous avez déjà effectué un push de vos commits vers un dépôt partagé.

Pour conclure, git reset est une commande puissante utilisée pour annuler des changements locaux liés à l'état d'un dépôt Git. Git reset agit sur « les trois arborescences de Git ». Ces trois arborescences sont l'historique des commits (HEAD), l'index de staging et le répertoire de travail. Il existe trois options de ligne de commande qui correspondent à ces trois arborescences. Les options --soft, --mixed et --hard peuvent être transmise à git reset.

Dans cet article, nous avons utilisé un certain nombre de commandes Git supplémentaires afin d'illustrer les processus de reset. Pour en savoir plus sur ces commandes, reportez-vous aux pages correspondantes : git status, git log, git add, git checkout, git reflog, et git revert.