Resetting, checking out & reverting

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.

Il s'agit d'une mise à jour de l'arborescence « Historique des commits ». La commande git checkout peut être utilisée dans un commit ou un périmètre de niveau fichier. Un checkout de niveau fichier modifiera le contenu du fichier pour correspondre à celui du commit spécifique.

Un revert est une opération qui prend un commit spécifique et crée un nouveau commit qui inverse le commit spécifique. La commande git revert peut uniquement être exécutée pour un périmètre de niveau commit et ne dispose d'aucune fonctionnalité de niveau fichier.

Un reset est une opération qui prend un commit spécifique et réinitialise les « trois arborescences » de sorte qu'elles correspondent à l'état du dépôt au niveau du commit spécifique. Un reset peut être appelé dans trois modes différents qui correspondent aux trois arborescences.

Le checkout et le reset sont généralement utilisés pour procéder à des « annulations » locales ou privées. Ils modifient l'historique d'un dépôt, ce qui peut entraîner des conflits lors d'un push vers des dépôts partagés distants. Le revert est considéré comme une opération sûre, étant donné qu'il crée un nouvel historique qui peut être partagé à distance et n'écrase pas un historique dont peuvent dépendre les membres de l'équipe à distance.

Le tableau ci-dessous répertorie les utilisations les plus courantes de toutes ces commandes. Veillez à le conserver pour vous y référer ultérieurement, car vous aurez sans doute besoin d'en utiliser au moins quelques-unes en tant que développeur Git.

Les paramètres que vous définissez pour git reset et git checkout déterminent leur périmètre. Si vous ne spécifiez pas de chemin d'accès dans vos paramètres, ceux-ci s'appliqueront à tous les commits. Pour plus d'informations sur le sujet, consultez la section ci-dessous. Remarque : git revert n'a pas d'homologue au niveau fichier.

Les deux commits situés à la fin de hotfix constituent désormais des commits libres ou orphelins. Cela signifie qu'ils seront supprimés au prochain nettoyage de type garbage collection effectué par Git. En d'autres termes, cette opération revient à supprimer les commits concernés. Elle peut être visualisée comme suit :

Cette utilisation de git reset constitue une manière simple d'annuler des changements qui n'ont pas encore été partagés. Cette commande est incontournable lorsque vous commencez à travailler sur une fonctionnalité, puis que tout à coup, vous vous rendez compte que vous vous êtes trompé et que vous voulez tout recommencer.

En plus de déplacer la branche courante, vous pouvez exécuter git reset pour modifier l'instantané stagé et/ou le répertoire de travail en y ajoutant l'un des flags suivants :

• --soft – L'instantané stagé et le répertoire de travail restent inchangés.
• --mixed – L'instantané stagé est aligné sur le commit spécifié, tandis que le répertoire de travail reste inchangé. C'est l'option par défaut.
• --hard : l'instantané stagé et le répertoire de travail sont tous deux alignés sur le commit spécifié.
  

It’s easier to think of these modes as defining the scope of a git reset operation. For further detailed information visit the git reset page.

La commande git checkout est utilisée pour mettre à jour l'état du dépôt à un point spécifique de l'historique des projets. Une fois la branche nommée, vous pouvez basculer entre les branches.

En interne, la commande ci-dessus a pour seul effet de déplacer HEAD vers une autre branche et de mettre à jour le répertoire de travail. Puisque cette opération est susceptible d'annuler vos changements en local, Git vous oblige à faire un commit ou un stash de tout changement dans le répertoire de travail qui sera perdu lors du checkout. Contrairement à git reset, git checkout ne déplace aucune branche.

Vous pouvez également réaliser un checkout des commits arbitraires en ajoutant la référence du commit plutôt qu'une branche. Cette opération revient à faire un checkout d'une branche : la référence HEAD est déplacée vers le commit spécifié. Par exemple, la commande suivante va extraire le grand-parent du commit courant :

Elle peut s'avérer utile pour jeter un coup d'œil rapide à une ancienne version de votre projet. Cependant, puisqu'aucune référence de branche n'est associée au marqueur HEAD courant, vous passez à l'état HEAD détaché. Attention : si vous commencez à ajouter de nouveaux commits, il vous sera impossible de les récupérer une fois que vous aurez basculé sur une autre branche. C'est la raison pour laquelle vous devez toujours créer une nouvelle branche avant d'ajouter des commits à un HEAD détaché.

Elle peut être visualisée comme suit :

Veillez à ne pas confondre cette commande avec git reset, qui modifie l'historique des commits existant. Par conséquent, utilisez git revert pour annuler des changements apportés à une branche publique, et git reset pour faire de même, mais sur une branche privée.

Gardez à l'esprit que git revert sert à annuler des changements commités, tandis que git reset HEAD permet d'annuler des changements non commités.

À l'instar de git checkout, git revert est susceptible d'écraser des fichiers dans le répertoire de travail et vous demandera donc de faire un commit ou un stash des changements qui risqueraient d'être perdus pendant le revert.

Associée à un chemin d'accès, la commande git reset met à jour l'instantané stagé staged snapshot pour l'aligner sur la version issue du commit spécifié. Par exemple, elle récupère la version de foo.py dans l'avant-dernier commit et l'indexe pour le prochain commit :

Tout comme la version de git reset de niveau commit, elle est plus souvent utilisée avec HEAD plutôt qu'avec un commit arbitraire. L'exécution de git reset HEAD foo.py annulera foo.py. Les changements qu'il contient seront toujours apparents dans le répertoire de travail.

Les flags --soft, --mixed et --hard n'ont aucun effet sur la version de git reset de niveau fichier, puisque l'instantané stagé est continuellement mis à jour, tandis que le répertoire de travail ne l'est jamais.

L'extraction de fichiers s'apparente à l'utilisation de git reset associée à un chemin d'accès, à cela près que c'est le répertoire de travail qui est mis à jour, et non la zone de staging. Contrairement à la version de cette commande de niveau commit, la référence HEAD n'est pas déplacée, donc vous ne basculez pas entre les branches.

Par exemple, la commande suivante aligne le fichier foo.py du répertoire de travail sur celui de l'avant-dernier commit :

Tout comme la version de git checkout de niveau commit, cette commande peut être utilisée pour examiner les anciennes versions d'un projet. Cependant, son périmètre est limité au fichier spécifié.

Si vous indexez et commitez le fichier extrait, il sera remplacé par son ancienne version. Remarque : cette opération supprime tous les changements ultérieurs apportés au fichier, alors que la commande git revert annule uniquement les changements apportés par le commit spécifié.

À l'instar de git reset, cette commande est souvent utilisée avec HEAD en guise de référence de commit. Par exemple, git checkout HEAD foo.py a pour effet d'ignorer les changements non stagés apportés à foo.py. Le résultat est le même que pour git reset HEAD --hard à cela près que seul le fichier spécifié est concerné.

You should now have all the tools you could ever need to undo changes in a Git repository. The git reset, git checkout, and git revert commands can be confusing, but when you think about their effects on the working directory, staged snapshot, and commit history, it should be easier to discern which command fits the development task at hand.