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