Français ▾ Topics ▾ Latest version ▾ git-reset last updated in 2.39.3

NOM

git-reset - Réinitialise la HEAD actuelle à l’état spécifié

SYNOPSIS

git reset [-q] [<arbre-esque>] [--] <spec-de-chemin>…​
git reset [-q] [--pathspec-from-file=<fichier> [--pathspec-file-nul]] [<arbre-esque>]
git reset (--patch | -p) [<arbre-esque>] [--] [<spec-de-chemin>…​]
git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]

DESCRIPTION

Dans la première et la troisième forme, cette commande copie les entrées depuis <arbre-esque> vers l’index. Dans la dernière forme, elle amène le sommet de la branche actuelle (HEAD) à <commit>, optionnellement en modifiant l’index et l’arbre de travail en correspondance. L'<arbre-esque>/<commit> vaut par défaut HEAD dans toutes les formes.

git reset [-q] [<arbre-esque>] [--] <spec-de-chemin>…​
git reset [-q] [--pathspec-from-file=<fichier> [--pathspec-file-nul]] [<arbre-esque>]

Ces formes réinitialisent les entrées d’index pour tous fichiers correspondant à <spec-de-chemin> à leur état de <arbre-esque> (ceci n’affecte pas l’arbre de travail ou la branche actuelle.)

Cela signifie que git reset <spec-de-chemin> est l’opposé de git add <spec-de-chemin>. Cette commande est équivalent à git restore [--source=<arbre-esque>] --staged <spec-de-chemin>....

Après avoir lancé git reset <spec-de-chemin> pour mettre à jour l’entrée d’index, vous pouvez git-restore[1] pour extraire le contenu de l’index dans l’arbre de travail. Alternativement, en utilisant git-restore[1] et en spécifiant un commit avec --source, vous pouvez copier le contenu d’un chemin d’un commit vers l’index et l’arbre de travail d’une seule traite.

git reset (--patch | -p) [<arbre-esque>] [--] [<spec-de-chemin>…​]

Sélectionner interactivement les sections dans la différence entre l’index et l'<arbre-esque> (par défaut HEAD). Les sections choisies sont ensuite appliquées en ordre inversé à l’index.

Ceci signifie que git reset -p est l’opposé de git add -p, autrement dit, vous pouvez l’utiliser pour réinitialiser sélectivement les sections. Voir la section « Mode interactif » de git-add[1] pour apprendre comment utiliser le mode --patch.

git reset [<mode>] [<commit>]

Cette forme réinitialise le sommet de la branche actuelle à <commit> et met à jour l’index éventuellement (en le réinitialisant à l’arbre de <commit>) et l’arbre de travail en fonction de <mode>. Avant l’opération, ORIG_HEAD est définie sur le sommet de la branche actuelle. Si <mode> est omis, l’option par défaut est --mixed. Le mode est une valeur parmi :

--soft

Ne pas toucher du tout le fichier d’index ou l’arbre de travail (mais réinitialise le sommet à <commit>, juste comme le font tous les modes). Cela laisse tous vos fichiers modifiés « Modifications qui seront validées », comme l’indiquerait git status.

--mixed

Réinitialiser l’index mais pas l’arbre de travail (c’est-à-dire, les fichiers modifiés sont préservés mais marqués pour la validation) et affiche ce qui n’a pas été mis à jour. C’est l’action par défaut.

Si -N est spécifié, les chemins supprimés sont marqués comme « à ajouter » (voir git-add[1]).

--hard

Réinitialiser l’index et l’arbre de travail. Toute modification sur les fichiers suivis dans l’arbre de travail depuis <commit> est supprimée. Tous les fichiers ou répertoires non suivis qui empêchent l’écriture des fichiers suivis sont simplement supprimés.

--merge

Réinitialiser l’index et mettre à jour les fichiers de l’arbre de travail qui sont différents entre <commit> et HEAD, mais conserver ceux qui sont différents entre l’index et l’arbre de travail (c-à-d qui ont des modifications qui n’ont pas été indexés). Si un fichier qui est différent entre <commit> et l’index a des modifications non indexées, la réinitialisation est annulée.

En d’autres termes, --merge fait quelque chose comme git read-tree -u -m <commit>, mais transfère les entrées d’index non indexées.

--keep

Réinitialiser les entrées d’index et mettre à jour les fichiers dans l’arbre de travail qui sont différents entre <commit> et HEAD. Si un fichier qui est différent entre <commit> et HEAD a des modifications locales, la réinitialisation est annulée.

--[no-]recurse-submodules

Lorsque l’arbre de travail est mis à jour, l’utilisation de --recurse-submodules réinitialisera également de manière récursive l’arbre de travail de tous les sous-modules actifs en fonction du commit enregistré dans le superprojet, en définissant également la HEAD des sous-modules à détacher à ce commit.

Voir « Reset, restore et revert » dans git[1] pour les différences entre les trois commandes.

OPTIONS

-q
--quiet

mode silencieux, n’afficher que les messages d’erreur.

--refresh
--no-refresh

Rafraîchir l’index après une réinitialisation mixte. Activé par défaut.

--pathspec-from-file=<fichier>

Le spécificateur de chemin est passé dans <fichier> au lieu des arguments de la ligne de commande. Si <fichier> vaut - alors l’entrée standard est utilisée. Les éléments du spécificateur de chemin sont séparés par LF ou CR/LF. Les éléments du spécificateur de chemin peuvent être cités comme expliqué pour la variable de configuration core.quotePath (voir git-config[1]). Voir aussi l’option --pathspec-file-nul et l’option globale --literal-pathspecs.

--pathspec-file-nul

Uniquement significatif avec --pathspec-from-file. Les éléments du spécificateur de chemin sont séparés par le caractère NUL et tous les autres caractères sont utilisés littéralement (y compris les retours à la ligne et les guillemets).

--

Ne pas interpréter les arguments qui suivent comme options.

<spécificateur de chemin>…​

Limite les chemins affectés par l’opération.

Pour plus de détail, voir l’entrée spécificateur de chemin dans gitglossary[7].

EXEMPLES

Défaire un ajout 
$ edit                                     (1)
$ git add frotz.c filfre.c
$ mailx                                    (2)
$ git reset                                (3)
$ git pull git://info.example.com/ nitfol  (4)

  1. Vous travaillez joyeusement sur quelque chose, et trouvez que les modifications dans ces fichiers sont prêtes. Vous ne voulez pas les voir lorsque vous lancez git diff, parce que vous allez travailler sur d’autres fichiers et les modifications à ces fichiers vous distrairaient de votre travail.

  2. Quelqu’un vous demande de tirer, et les modifications paraissent valoir le coup d’être fusionnées.

  3. Cependant, vous avez déjà sali l’index (c-à-d votre index ne correspond pas au commit HEAD). Mais vous savez que le tirage que vous allez faire n’affecte ni frotz.c ni filfre.c, donc vous rembobinez les modifications de l’index pour ces deux fichiers. Vos modifications dans l’arbre de travail restent là.

  4. Puis vous pouvez tirer et fusionner, en laissant les modifications à frotz.c et filfre.c dans l’arbre de travail.

Défaire un commit et le refaire 
$ git commit ...
$ git reset --soft HEAD^      (1)
$ éditer                      (2)
$ git commit -a -c ORIG_HEAD  (3)

  1. Cela sert le plus souvent quand vous vous êtes souvenu que ce que vous avez validé est incomplet, ou que vous avez mal orthographié votre message de validation, ou les deux. Cela laisse l’arbre de travail comme il était avant « reset ».

  2. Corrige les fichiers de l’arbre de travail.

  3. "reset" copie l’ancienne HEAD vers .git/ORIG_HEAD ; refait le commit en démarrant par son message de validation. Si vous n’avez pas besoin d’éditer plus le message, vous pouvez plutôt passer l’option -C.

    Voir aussi l’option --amend de git-commit[1].

Défaire le commit, en le transformant en branche thématique 
$ git branch theme/wip     (1)
$ git reset --hard HEAD~3  (2)
$ git switch theme/wip   (3)

  1. Vous avez fait des commits, mais vous vous êtes aperçu qu’ils étaient prématurés pour la branche master. Vous voulez continuer à le polir dans une branche thématique, donc vous créez la branche theme/wip de la HEAD actuelle.

  2. Rembobinez la branche master pour en éliminer ces trois commits.

  3. Basculez sur la branche theme/wip et continuez à travailler.

Défaire des commit de manière permanente 
$ git commit ...
$ git reset --hard HEAD~3   (1)

  1. Les trois derniers commits (HEAD, HEAD^ et HEAD~2) étaient mauvais et vous ne plus jamais les voir. Ne faites pas ceci si vous avez déjà fourni ces commits à quelqu’un d’autre. (Voir la section « RÉPARER UN REBASAGE AMONT » dans git-rebase[1] pour les implications d’une telle action.)

Défaire une fusion ou un tirage 
$ git pull                         (1)
Auto-fusion nitfol
CONFLIT (contenu): Conflit de fusion dans nitfol
La fusion automatique a échoué ; réglez les conflits et validez le résultat.
$ git reset --hard                 (2)
$ git pull . theme/branche         (3)
Avance rapide de  41223... sur 13134...

$ git reset --hard ORIG_HEAD       (4)

  1. L’essai de mettre à jour depuis l’amont a apporté beaucoup de conflits ; vous n’êtes pas prêt à passer beaucoup de temps à les fusionner maintenant, donc vous décidez de le faire plus tard.

  2. "pull" n’a pas créé de commit de fusion, donc git reset --hard qui est synonyme de git reset --hard HEAD nettoie le bazar dans l’index et l’arbre de travail.

  3. Fusionne une branche thématique dans la branche actuelle, qui a résulté en une avance rapide.

  4. Mais vous avez décidé que la branche thématique n’est pas encore prête pour la publication. "pull" et "merge" laissent toujours le sommet originel de la branche actuelle dans ORIG_HEAD, donc la réinitialisation dure sur elle remet votre fichier d’index et l’arbre de travail à cet état et réinitialise le sommet de la branche à ce commit.

Défaire une fusion ou un tirage dans un arbre de travail sale 
$ git pull                         (1)
Auto-merging nitfol
Merge made by recursive.
 nitfol                |   20 +++++----
 ...
$ git reset --merge ORIG_HEAD      (2)

  1. Même si vous pouviez avoir des modifications locales dans votre arbre de travail, vous pouvez lancer git pull en toute sécurité quand vous savez que les modifications dans l’autre branche n’entrent pas en conflit avec elles.

  2. Après inspection du résultat de la fusion, vous pouvez trouver que cette modification dans l’autre branche n’est pas satisfaisante. Lancer git reset --hard ORIG_HEAD vous ramènera à l’état antérieur, mais cela éliminera aussi vos modifications locales, ce que vous ne désirez pas. git reset --merge conserve vos modifications locales.

Interruption du flux de travail

Supposons que vous êtes interrompu par une demande urgente de correctif pendant que vous êtes au milieu d’une grande modification. Les fichiers dans votre arbre de travail ne sont pas du tout en état d’être validés, mais vous devez aller sur une autre branche pour votre correctif rapide.

$ git switch feature ;# vous travailliez sur la branche feature
$ travail travail      ;# et arrive une interruption
$ git commit -a -m "instantané en cours"          (1)
$ git switch master
$ correctif correctif
$ git commit           ;# validation avec un vrai message
$ git switch feature
$ git reset --soft HEAD^ ;# retour au travail     (2)
$ git reset                                       (3)

  1. Ce commit sera écrasé donc un message de validation jetable, c’est OK.

  2. Ceci élimine le commit « instantané » de l’historique des commits et met votre arbre de travail dans l’état précédent cet instantané.

  3. À ce point, le fichier d’index a toujours toutes les modifications en cours que vous avez validées comme « instantané en cours ». Ceci met à jour l’index pour afficher vos fichiers en cours d’édition comme non validés.

    Voir aussi git-stash[1].