Git
Français ▾ Topics ▾ Latest version ▾ git-restore last updated in 2.43.0

NOM

git-restore - Restaure les fichier d’un arbre de travail

SYNOPSIS

git restore [<options>] [--source=<arbre>] [--staged] [--worktree] [--] <spec-de-chemin>…​
git restore [<options>] [--source=<arbre>] [--staged] [--worktree] --pathspec-from-file=<fichier> [--pathspec-file-nul]
git restore (-p|--patch) [<options>] [--source=<arbre>] [--staged] [--worktree] [--] [<spec-de-chemin>…​]

DESCRIPTION

Restaurer les chemins spécifiés dans l’arbre de travail avec certains contenus d’une source de restauration. Si un chemin est suivi mais n’existe pas dans la source de restauration, il sera supprimé pour correspondre à la source.

La commande peut aussi être utilisée pour restaurer le contenu de l’index avec --staged, ou restaurer à la fois l’arbre de travail et l’index avec --staged --worktree.

Par défaut, si --staged est donné, le contenu est restauré depuis HEAD, sinon depuis l’index. Utilisez --source pour restaurer à partir d’un commit différent.

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

CETTE COMMANDE EST EXPÉRIMENTALE. LE COMPORTEMENT PEUT CHANGER.

OPTIONS

-s <arbre>
--source=<arbre>

Restaurer les fichiers de l’arbre de travail avec le contenu de l’arbre donné. Il est courant de spécifier l’arbre source en nommant un commit, une branche ou une étiquette qui lui est associée.

Si ce n’est pas spécifié, le contenu est restauré depuis HEAD. Si --staged est donné sinon, depuis l’index.

Autre cas spécial supplémentaire, vous pouvez utiliser « A…​B » comme raccourci pour la base de fusion de A et B s’il y a exactement une seule base de fusion. Vous pouvez ne pas spécifier A ou B, auquel cas ce sera HEAD par défaut.

-p
--patch

Sélectionner interactivement les sections dans la différence entre la source de restauration et location de restauration. Voir la section « Mode Interactif » de git-add[1] pour apprendre à utiliser le mode --patch.

Notez que --patch peut accepter une absence de spécificateur de chemin et demandera de restaurer tous les chemins modifiés.

-W
--worktree
-S
--staged

Spécifier l’emplacement de restauration. Si aucune option n’est spécifiée, l’arbre de travail est restauré par défaut. En spécifiant --staged, seul l’index sera restauré. Spécifier les deux restaure les deux.

-q
--quiet

Silencieux, supprimer les messages d’état. Implique --no-progress.

--progress
--no-progress

L’état d’avancement est affiché sur la sortie standard d’erreur par défaut quand elle est attachée à un terminal, à moins que --quiet ne soit spécifié. Cette bascule active l’état d’avancement même sans être attaché à un terminal, indépendamment de --quiet.

--ours
--theirs

Lors de la restauration de fichiers dans l’arbre de travail, utiliser l’état #2 (ours, le nôtre) ou #3 (theirs, le leur) pour les chemins non fusionnés. Cette option ne peut pas être utilisée lors de l’extraction des chemins d’un arbre-esque (c.-à-d. avec l’option -source).

Veuillez noter que pendant git rebase et git pull --rebase, ours et theirs peuvent sembler échangés. Voir l’explication des mêmes options dans git-checkout[1] pour plus de détails.

-m
--merge

Lors de la restauration de l’arbre de travail depuis l’index, récréer la fusion en conflit dans les chemins non fusionnés. Cette option ne peut pas être utilisée lors de l’extraction des chemins d’un arbre-esque (c.-à-d. avec l’option -source).

--conflict=<style>

Identique à l’option --merge ci-dessus, mais la manière dont les sections en conflits sont présentées est modifiée, en surchargeant la variable de configuration merge.conflictStyle. Les valeurs possibles sont merge (fusion, par défaut), diff3 et zdiff3.

--ignore-unmerged

Lors de la restauration des fichiers sur l’arbre de travail à partir de l’index, ne pas interrompre l’opération s’il y a des entrées non fusionnées et qu’aucune option --ours, --theirs, --merge ou --conflict n’est spécifiée. Les chemins non-fusionnés sur l’arbre de travail sont laissés seuls.

--ignore-skip-worktree-bits

En mode d’extraction clairsemé, le comportement par défaut met seulement à jour les entrées correspondant à <spécificateur-de-chemin> et aux motifs clairsemés dans $GIT_DIR/info/sparse-checkout. Cette option ignore les motifs clairsemés et restaure tous les fichiers de <spécificateur-de-chemin>.

--recurse-submodules
--no-recurse-submodules

Si <pathspec> nomme un sous-module actif et que l’emplacement de la restauration inclut l’arbre de travail, le sous-module ne sera mis à jour que si cette option est donnée, auquel cas son arbre de travail sera restauré au commit enregistré dans le superprojet, et toute modification locale sera écrasée. Si rien (ou --no-recurse-submodules) n’est utilisé, les arbres de travail des sous-modules ne seront pas mis à jour. Tout comme git-checkout[1], cela détachera le HEAD du sous-module.

--overlay
--no-overlay

En mode sur-écriture, la commande ne supprime jamais les fichiers lors de la restauration. En mode sans sur-écriture, les fichiers suivis qui n’apparaissent pas dans l’arbre --source sont supprimés, pour qu’ils correspondent exactement à <arbre>. La valeur par défaut est le mode sans sur-écriture.

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

La séquence suivante bascule sur la branche master, ramène le fichier Makefile à deux révisions en arrière, supprime hello.c par erreur et le récupère de l’index.

$ git switch master
$ git restore --source master~2 Makefile  (1)
$ rm -f hello.c
$ git restore hello.c                     (2)

  1. prend un fichier depuis un autre commit

  2. restaure hello.c depuis l’index

Si vous souhaitez restaurer tous les fichiers source C pour correspondre à la version de l’index, vous pouvez lancer

$ git restore '*.c'

Notez les guillemets autour de *.c. Le fichier hello.c sera aussi restauré, même s’il n’est plus dans l’arbre de travail, parce que le patron de fichier est utilisé pour trouver les entrées dans l’index (et non dans l’arbre de travail par le shell).

Pour restaurer tous les fichiers du répertoire actuel

$ git restore .

ou pour restaurer tous les fichiers de l’arbre de travail avec la magie du spécificateur de chemin top (voir gitglossary[7])

$ git restore :/

Pour restaurer un fichier dans l’index pour qu’il corresponde à la version dans HEAD (c’est la même chose que d’utiliser git-reset[1])

$ git restore --staged hello.c

ou vous pouvez restaurer à la fois l’index et l’arbre de travail (c’est la même chose que d’utiliser git-checkout[1])

$ git restore --source=HEAD --staged --worktree hello.c

ou la forme courte qui est plus pratique mais moins lisible :

$ git restore -s@ -SW hello.c

VOIR AUSSI

git-checkout[1], git-reset[1]

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