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

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 courante à <commit> et met à jour l’index éventuellement (en le réinitialisant à l’arbre de <commit>) et l’arbre de travail en fonction de <mode>. 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.

--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
--no-quiet

Mode silencieux, ne reporter que les erreurs. Le comportement par défaut est géré par l’option de configuration reset.quiet. --quiet et --no-quiet outrepassent le comportement 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].

Réinitialiser un seul fichier dans l’index

Supposons que vous avez ajouté un fichier à votre index, mais décidez plus tard que vous ne voulez plus l’ajouter à votre validation. Vous pouvez retirer le fichier de l’index tout en conservant vos modifications avec git reset.

$ git reset -- frotz.c                      (1)
$ git commit -m "Validation de l'index"     (2)
$ git add frotz.c                           (3)
  1. Ceci supprime un fichier de l’index tout en le conservant dans le répertoire de travail.

  2. Ceci valide tous les autres fichiers dans l’index.

  3. Ajouter à nouveau le fichier à l’index.

Conserver les modifications dans l’arbre de travail tout en éliminant les validations précédentes

Supposons que vous êtes en train de travailler sur quelque chose et que vous le validez, et qu’alors vous continuez à travailler un peu plus, mais vous pensez maintenant que ce que vous avez dans votre arbre de travail devrait aller dans une autre branche qui n’a rien à voir avec ce que vous avez validé précédemment. Vous pouvez commencer une nouvelle branche et la réinitialiser tout en conservant les modifications dans votre arbre de travail.

$ git tag debut
$ git switch -c branche1
$ édition
$ git commit ...                            (1)
$ édition
$ git switch -c branche2                  (2)
$ git reset --keep debut                    (3)
  1. Ceci valide vos premières éditions dans branche1.

  2. Dans un monde idéal, vous pourriez avoir réalisé que le commit précédent n’appartenait pas au nouveau sujet quand vous avez créé et avez basculé sur branche2 (c-à-d git switch -c branche2 debut), mais personne n’est parfait.

  3. Mais vous pouvez utiliser reset --keep pour retirer le commit non voulu après avoir basculé sur branche2.

Découper un commit en une séquence de commits

Supposons que vous avez créé de nombreuses modifications logiquement atomiques et les avez toutes validées ensemble. Plus tard, vous décidez qu’il serait mieux d’avoir chaque section logique associée à son propre commit. Vous pouvez utiliser git reset pour rembobiner l’historique sans changer le contenu de vos fichiers locaux, puis successivement utiliser git add -p pour sélectionner interactivement quelles sections inclure dans chaque validation, en utilisant git commit -c pour pré-charger le message de validation.

$ git reset -N HEAD^                        (1)
$ git add -p                                (2)
$ git diff --cached                         (3)
$ git commit -c HEAD@{1}                    (4)
...                                         (5)
$ git add ...                               (6)
$ git diff --cached                         (7)
$ git commit ...                            (8)
  1. Réinitialise d’abord l’historique en arrière d’un commit de manière à retirer le commit original, mais laisse l’arbre de travail avec toutes ses modifications. Le drapeau -N garantit que tous les nouveaux fichiers ajoutés avec HEAD sont toujours marqués de telle manière que git add -p les trouve.

  2. Ensuite, on sélectionne interactivement les sections de diff à ajouter en utilisant git add -p. Ceci vous demandera pour chaque section de diff l’une après l’autre et vous pouvez répondre simplement « oui, à inclure », « non, ne pas inclure » ou même utiliser la fonctionnalité puissante d’édition de la section.

  3. Une fois satisfait des sections à inclure, vous devriez vérifier ce qui a été préparé pour la première validation en utilisant git diff --cached. Cela montre toutes les modifications qui ont été indexées et sont sur le point d’être validées.

  4. Ensuite, valider les modifications stockées dans l’index. L’option -c indique de pré-remplir le message de validation avec le message original qui a servi au premier commit. C’est utile pour éviter de le retaper. Le HEAD@{1} est une notation spéciale pour le commit que HEAD a été avant le commit original réinitialisé (il y a une modification). Voir git-reflog[1] pour plus de détails. Vous pouvez aussi utiliser une référence à tout autre commit valide.

  5. Vous pouvez répéter les étapes 2 à 4 plusieurs fois pour scinder le code original en un certain nombre de commits.

  6. Maintenant, vous avez séparé beaucoup des modifications dans leurs propres commits, et pourriez ne plus utiliser le mode patch du git add pour sélectionner toutes les modifications non validées restantes.

  7. Une fois de plus, vérifiez que vous avez inclus ce que vous souhaitez. Vous souhaitez peut-être vérifier que git diff ne montre aucune modification restante à valider plus tard.

  8. Et finalement crée le commit final.

DISCUSSION

Les tables ci-dessous montrent ce qui arrive lorsqu’on lance :

git reset --option cible

pour réinitialiser HEAD à un autre commit (cible) avec des options de réinitialisation en fonction de l’état des fichiers.

Dans ces tableaux, A, B, C et D sont différents états d’un fichier. Par exemple, la première ligne du premier tableau signifie que si un fichier est dans l’état A dans l’arbre de travail, dans l’état B dans l’index, dans l’état C dans HEAD et dans l’état D dans la cible, alors git reset --soft cible laissera le fichier dans l’arbre de travail dans l’état A et dans l’index dans l’état B. Il réinitialise (c-à-d déplace) la HEAD (en d’autres termes le sommet de la branche actuelle, si vous êtes dessus) à cible (qui a le fichier dans l’état D).

travail index HEAD cible         travail index HEAD
----------------------------------------------------
 A       B     C    D     --soft   A       B     D
			  --mixed  A       D     D
			  --hard   D       D     D
			  --merge (interdit)
			  --keep  (interdit)
travail index HEAD cible         travail index HEAD
----------------------------------------------------
 A       B     C    C     --soft   A       B     C
			  --mixed  A       C     C
			  --hard   C       C     C
			  --merge (interdit)
			  --keep   A       C     C
travail index HEAD cible         travail index HEAD
----------------------------------------------------
 B       B     C    D     --soft   B       B     D
			  --mixed  B       D     D
			  --hard   D       D     D
			  --merge  D       D     D
			  --keep  (interdit)
travail index HEAD cible         travail index HEAD
----------------------------------------------------
 B       B     C    C     --soft   B       B     C
			  --mixed  B       C     C
			  --hard   C       C     C
			  --merge  C       C     C
			  --keep   B       C     C
travail index HEAD cible         travail index HEAD
----------------------------------------------------
 B       C     C    D     --soft   B       C     D
			  --mixed  B       D     D
			  --hard   D       D     D
			  --merge (interdit)
			  --keep  (interdit)
travail index HEAD cible         travail index HEAD
----------------------------------------------------
 B       C     C    C     --soft   B       C     C
			  --mixed  B       C     C
			  --hard   C       C     C
			  --merge  B       C     C
			  --keep   B       C     C

reset --merge est fait pour être utilisé lors de la réinitialisation d’une fusion conflictuelle. Toute opération de type fusion garantit que le fichier de l’arbre de travail qui est impliqué dans une fusion ne subit pas de modification locale par rapport à l’index avant son démarrage, et qu’elle écrit le résultat dans l’arbre de travail. Donc si nous voyons des différences entre l’index et la cible et aussi entre l’index et l’arbre de travail, alors cela signifie que nous ne réinitialisons pas depuis un état qu’une opération de type fusion a laissé après un échec de conflit. C’est pourquoi l’option --merge est interdite dans ce cas.

reset --keep est fait pour être utilisé lors de la suppression d’un certain nombre des derniers commits dans la branche actuelle tout en conservant les modifications dans l’arbre de travail. S’il pouvait y avoir conflit entre les modifications dans le commit que nous souhaitons retirer et les modifications dans l’arbre de travail que nous souhaitons conserver, la réinitialisation est interdite. C’est pourquoi il est interdit s’il y a des modifications à la fois dans l’arbre de travail et dans HEAD, et entre HEAD et la cible. Pour plus de sécurité, c’est aussi interdit quand des entrées sont non fusionnées.

Le tableau suivant montre ce qui arrive quand il y a des entrées non fusionnées :

travail index HEAD cible          travail index HEAD
----------------------------------------------------
 X       U     A    B     --soft  (disallowed)
			  --mixed  X       B     B
			  --hard   B       B     B
			  --merge  B       B     B
			  --keep  (disallowed)
travail index HEAD cible          travail index HEAD
----------------------------------------------------
 X       U     A    A     --soft  (interdit)
			  --mixed  X       A     A
			  --hard   A       A     A
			  --merge  A       A     A
			  --keep  (interdit)

X signifie n’importe quel état et U signifie un index non fusionné.

GIT

Fait partie de la suite git[1]

TRADUCTION

Cette page de manuel a été traduite par Jean-Noël Avila <jn.avila AT free DOT fr> et les membres du projet git-manpages-l10n. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le site https://github.com/jnavila/git-manpages-l10n .

scroll-to-top