Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
- 2.34.1 no changes
- 2.34.0 11/15/21
- 2.33.0 → 2.33.1 no changes
- 2.32.0 06/06/21
- 2.26.1 → 2.31.1 no changes
- 2.26.0 03/22/20
- 2.16.6 → 2.25.5 no changes
- 2.15.4 12/06/19
- 2.14.6 12/06/19
- 2.13.7 05/22/18
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.
OPTIONS
- <spécificateur de chemin>…
-
Fichiers à supprimer. Un nom de répertoire en préfixe (par exemple
rép
pour supprimerrép/fichier1
etré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
etr2
, il y a une différence entre utilisergit rm 'r*'
etgit rm 'r/*'
, car la première forme supprime aussi le répertoirer2
.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.
- -q
- --quiet
-
git rm
affiche normalement une ligne (sous la forme d’une commanderm
) 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 configurationcore.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-submodules[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épertoireDocumentation
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épertoireDocumentation/
. -
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.
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 .