Git 🌙
Français â–Ÿ Topics â–Ÿ Latest version â–Ÿ git-rm last updated in 2.43.0

NOM

git-rm - Supprime des fichiers de l’arbre de travail et de l’index

SYNOPSIS

git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch]
	  [--quiet] [--pathspec-from-file=<fichier> [--pathspec-file-nul]]
	  [--] [<spec-de-fichier>…​]

DESCRIPTION

Supprime les fichiers correspondant Ă  spec-de-fichier de l’index, ou de l’arbre de travail et de l’index. git rm ne supprimera pas un fichier seulement de votre rĂ©pertoire de travail (il n’y a aucune option pour supprimer un fichier seulement depuis l’arbre de travail et le conserver dans l’index ; utilisez /bin/rm si c’est ce que vous souhaitez faire). Les fichiers Ă  supprimer doivent ĂȘtre identiques Ă  ceux du sommet de la branche, et avec aucune mise Ă  jour indexĂ©e, mais ce comportement par dĂ©faut peut ĂȘtre outrepassĂ© avec l’option -f. Quand --cached est fourni, le contenu indexĂ© doit correspondre soit au sommet de la branche soit au fichier sur disque, de sorte que le fichier puisse n’ĂȘtre supprimĂ© que de l’index. Lorsque des extractions partielles sont utilisĂ©es (voir git-sparse-checkout[1]), git rm ne supprimera que les chemins qui correspondent aux motifs d’extraction partielle.

OPTIONS

<spĂ©cificateur de chemin>…​

Fichiers Ă  supprimer. Un nom de rĂ©pertoire en prĂ©fixe (par exemple rĂ©p pour supprimer rĂ©p/fichier1 et rĂ©p/fichier2) peut ĂȘtre indiquĂ© pour supprimer tous les fichiers dans un rĂ©pertoire, et rĂ©cursivement dans tous ses sous-rĂ©pertoires, mais cela nĂ©cessite explicitement l’option -r.

La commande ne supprime que les chemins qui sont connus de Git.

La correspondance de motifs de fichiers fonctionne à travers les limites de répertoires. Ainsi, étant donnés deux répertoires r et r2, il y a une différence entre utiliser git rm 'r*' et git rm 'r/*', car la premiÚre forme supprime aussi le répertoire r2.

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

-f
--force

Outrepasser la vérification de synchronisation.

-n
--dry-run

Ne pas supprimer rĂ©ellement les fichiers. À la place, montrer juste s’ils existent dans l’index et seraient de ce fait supprimĂ©s par la commande.

-r

Permettre la suppression récursive quand un répertoire est fourni.

--

Cette option permet de sĂ©parer les options de la ligne de commande de la liste des fichiers (utile si certains noms de fichiers peuvent ĂȘtre confondus avec des options).

--cached

Utilisez cette option pour dĂ©sindexer et supprimer les chemins seulement depuis l’index. Les fichiers de l’arbre de travail, qu’ils soient modifiĂ©s ou non, seront prĂ©servĂ©s.

--ignore-unmatch

Sortir avec un Ă©tat zĂ©ro mĂȘme si rien ne correspondait.

--sparse

Autoriser la mise Ă  jour des entrĂ©es d’index en dehors du cĂŽne d’extraction clairsemĂ©e. Normalement, git rm refuse de mettre Ă  jour les entrĂ©es d’index dont les chemins ne tiennent pas dans le cĂŽne d’extraction clairsemĂ©e. Voir git-sparse-checkout[1] pour plus d’informations.

-q
--quiet

git rm affiche normalement une ligne (sous la forme d’une commande rm) pour chaque fichier supprimĂ©. Cette option Ă©limine cet affichage.

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

SUPPRESSION DE FICHIERS QUI ONT DISPARU DU SYSTÈME DE FICHIERS

Il n’y a aucune option de git rm pour ne supprimer de l’index que les chemins qui ont disparu du systĂšme de fichier. Cependant, en fonction des cas, il y divers moyens d’y arriver.

En utilisant “git commit -a”

Si votre objectif est que le prochain commit enregistre toutes les modifications des fichiers suivis dans l’arbre de travail et enregistre toutes les suppressions de fichiers qui ont Ă©tĂ© supprimĂ©s de l’arbre de travail avec rm (par opposition Ă  git rm), utilisez git commit -a, qui va automatiquement dĂ©tecter et enregistrer toutes les suppressions. Vous pouvez aussi obtenir un effet similaire sans valider en utilisant git add -u.

En utilisant “git add -A”

Pour accepter une nouvelle livraison de code d’une branche de vendeur, vous souhaiterez probablement enregistrer Ă  la fois les suppressions de chemins et les ajouts de nouveaux chemins ainsi que les modifications de chemins existants.

Typiquement, vous supprimeriez d’abord tous les fichiers suivis de l’arbre de travail en utilisant la commande :

git ls-files -z | xargs -0 rm -f

Ensuite, vous dĂ©compresseriez le nouveau code dans l’arbre de travail. D’une autre maniĂšre, vous pourriez utiliser rsync dans votre arbre de travail.

AprĂšs cela, le moyen le plus simple d’enregistrer toutes les suppressions, les ajouts et les modifications dans l’arbre de travail consiste à :

git add -A

Voir git-add[1].

Autres moyens

Si tout ce que vous voulez vraiment faire, c’est de supprimer de l’index les fichiers qui ne sont plus prĂ©sents dans l’arbre de travail (peut-ĂȘtre parce que votre arbre de travail est sale, donc vous ne pouvez pas utiliser git commit -a), utilisez la commande suivante :

git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached

SOUS-MODULES

Seuls les sous-modules utilisant un gitfile (ce qui signifie qu’ils ont Ă©tĂ© clonĂ©s avec Git version 1.7.8 ou plus rĂ©cent) seront supprimĂ©s de l’arbre de travail, car leur dĂ©pĂŽt rĂ©side dans le rĂ©pertoire .git du superprojet. Si un sous-module (ou un sous-module de celui-ci) utilise encore un rĂ©pertoire .git, git rm va dĂ©placer le rĂ©pertoire git du sous-module dans le rĂ©pertoire git du superprojet pour protĂ©ger l’historique du sous-module. Si elle existe, la section submodule.<nom> dans le fichier gitmodules[5] sera aussi supprimĂ©e et ce fichier sera indexĂ© (Ă  moins que --cached ou -n ne soient utilisĂ©s).

Un sous-module est considĂ©rĂ© Ă  jour quand la HEAD est identique Ă  ce qui est enregistrĂ© dans l’index, qu’aucun fichier suivi n’est modifiĂ© ni qu’aucun fichier non suivi non ignorĂ© n’est prĂ©sent dans l’arbre de travail du sous-module. Les fichiers ignorĂ©s sont considĂ©rĂ©s jetables et n’empĂȘchent pas un sous-module d’ĂȘtre supprimĂ©.

Si vous voulez seulement supprimer une extraction locale d’un sous-module de votre arbre de travail sans valider la suppression, utilisez git-submodule[1] deinit Ă  la place. Voir aussi gitsubmodules[7] pour des dĂ©tails sur la suppression de sous-modules.

EXEMPLES

git rm Documentation/\*.txt

Supprimer tous les fichiers *.txt de l’index qui sont sous le rĂ©pertoire Documentation et ses sous-rĂ©pertoires.

Remarquez que l’astĂ©risque * est Ă©chappĂ© du shell dans cet exemple ; cela permet, par l’expansion des chemins par Git et non par le shell, d’inclure les fichiers dans les sous-rĂ©pertoires du RĂ©pertoire Documentation/.

git rm -f git-*.sh

Comme cet exemple laisse le shell rĂ©aliser l’expansion de l’astĂ©risque (c’est-Ă -dire que vous listez explicitement les fichiers du rĂ©pertoire), il ne supprime pas sous-rĂ©pertoire/git-toto.sh.

BOGUES

Chaque fois qu’une mise Ă  jour du super-projet supprime un sous-module peuplĂ© (par exemple, lors d’un basculement d’un commit prĂ©cĂ©dent la suppression Ă  un commit postĂ©rieur), une extraction pĂ©rimĂ©e du sous-module restera Ă  l’ancienne place. La suppression de l’ancien rĂ©pertoire n’est sĂ©curisĂ©e que lorsque le sous-module utilise un gitfile, car sinon l’historique du sous-module serait aussi supprimĂ©. Cette Ă©tape sera obsolĂšte lorsque la mise Ă  jour rĂ©cursive de sous-modules sera implantĂ©e.

VOIR AUSSI

git-add[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