Réinitialiser et restaurer dans Git

1. Commande git restore
2. Commande git reset
3. Différence entre git reset et git restore

Git a quelques commandes qui font des choses avec des fichiers individuels, mais elles sont assez rares. Ces commandes sont git add, git rm, git mv, git checkout, git reset, git restore, et leurs opposés respectifs.

Git est intelligent, cependant; il se souvient où nous avons le travail que nous avons récupéré afin qu’il puisse le récupérer plus tard à partir du prochain marqueur de récupération. Cela signifie que nous pouvons avoir un référentiel Git qui ne contient que les commits que nous avons créés localement. Si nous avons déjà récupéré les mêmes commits depuis un autre référentiel, Git peut éviter de les récupérer à nouveau.

Ici, dans cet article, nous discuterons des deux commandes importantes de Git :

1. git restore
2. git reset

Commande git restore

La commande Git restore est utilisée pour restaurer des fichiers dans l’arborescence de travail à partir de l’index ou d’un autre commit. Cette commande ne met pas à jour la branche actuelle. Il peut également restaurer des fichiers dans l’index à partir d’un autre commit. C’est très utile si on veut utiliser le code d’un commit différent du commit sur la branche courante. La commande restore aide à supprimer les modifications locales non validées dans la branche locale.

Git restore peut être utilisé dans trois situations différentes, selon la situation actuelle, si nous aimons revenir au travail dans la copie de travail ou l’index, ou les deux.

git restore [--worktree] <file>

La commande ci-dessus écrasera <file> dans notre copie de travail avec le contenu de notre fichier d’index. Ou nous pouvons dire qu’il annule nos modifications dans la copie de travail. Que nous le précisions n’a pas d’importance car il est suggéré si nous ne disons pas le contraire.

git restore --staged <file>

La commande ci-dessus écrasera <file> dans notre fichier d’index avec le HEAD actuel du référentiel local. Ou nous pouvons dire les modifications non validées du contenu récemment mis en scène. Ce ne sera pas faux si nous disons qu’il est bien égal à l’ancien git reset HEAD <file>.

git restore --staged --worktree --source HEAD <file>

Pour écraser à la fois, comme mentionné ci-dessus, la copie de travail et l’index avec le HEAD actuel, nous utilisons la commande ci-dessus. Cette version pourra faire les deux : rétablir notre copie de travail en HEAD et supprimer le travail récemment mis en scène de la branche locale actuelle.

Commande git reset

Git reset consiste à mettre à jour notre branche, en déplaçant l’astuce pour ajouter ou supprimer des commits de la branche. Cette opération modifie l’historique des commits. Git reset est utilisé pour restaurer l’index, en chevauchement avec Git restore. Si un fichier est modifié, soit en utilisant une édition manuelle, soit par une méthode git add, git reset ne le gère pas bien.

Le fichier est copié dans le nouveau commit, puis marqué comme supprimé dans l’ancien commit. Il donne un avertissement indiquant que le fichier semble avoir été supprimé de la copie de travail. Git reset ne gère pas non plus bien les changements de nom. Cela ne signifie pas supprimer un fichier et ajouter un fichier portant le même nom, mais c’est le cas.

La commande reset ne peut pas être utilisée pour déplacer des fichiers dans la copie de travail. Les fichiers ne sont pas seulement copiés dans un autre commit ; ils sont supprimés de la copie de travail et restaurés en tant que nouveaux fichiers dans le commit cible. Lorsque nous avons apporté des modifications indésirables à un fichier, il n’est pas nécessaire de supprimer le fichier. Nous pouvons annuler toutes les modifications apportées à un fichier, mais cela n’annule pas le fichier lui-même.

Différence entre git reset et git restore

La commande restore nous aide à supprimer ou à supprimer les modifications locales non validées. Il peut être utilisé pour restaurer des fichiers dans l’arborescence de travail à partir de l’index ou d’un autre commit. Cette commande ne met pas à jour notre branche. Il peut également être utile de restaurer des fichiers dans l’index à partir d’un autre commit.

Git reset est utilisé pour mettre à jour la branche actuelle. Il peut également être utile de restaurer l’index, en intersection avec git restore. Git reset est utilisé pour réinitialiser l’index afin d’annuler les modifications dans l’arbre de travail. Cette commande ne mettra pas à jour notre branche. Il est principalement utilisé avec l’option --soft, qui ne fait que réinitialiser l’index et laisse l’arbre de travail inchangé. C’est utile si nous avons mis en scène des changements que nous ne voulons pas ignorer.

Git reset se terminera avec succès si le répertoire de travail est propre (aucune modification à valider), tandis que git restore échouera si le répertoire de travail est propre. Les deux peuvent affecter la TÊTE. Cependant, Git restore n’affectera le HEAD qu’indirectement via la zone de staging. Git reset peut travailler directement avec l’index et le HEAD. Les deux peuvent affecter la TÊTE. Git restore n’affectera l’index et le HEAD qu’indirectement via la zone de staging.

Git reset peut être utilisé pour modifier le référentiel local uniquement si nous n’avons encore rien poussé. Si nous avons poussé vers le serveur distant, git-reset modifiera la zone de staging et la copie de travail, mais pas le référentiel. C’est utile si nous voulons annuler les modifications locales mais ne voulons pas les réintroduire à nouveau.

Git restore est le contraire car il ne peut être utilisé que pour modifier notre référentiel, pas la zone de staging ou la copie de travail locale. Cela n’affectera pas les commits que nous avons poussés.