Git

git-commit last updated in 2.43.0

NOM

git-commit - Enregistrer les modifications dans le dépôt

SYNOPSIS

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
	   [--dry-run] [(-c | -C | --fixup | --squash) <commit>]
	   [-F <fichier> | -m <msg>] [--reset-author] [--allow-empty]
	   [--allow-empty-message] [--no-verify] [-e] [--author=<auteur>]
	   [--date=<date>] [--cleanup=<mode>] [--[no-]status]
	   [-i | -o] [--pathspec-from-file=<fichier> [--pathspec-file-nul]]
	   [-S[<idclé>]] [--] [<spec-de-chemin>…]

DESCRIPTION

Crée un nouveau commit contenant le contenu actuel de l’index et avec le message de validation décrivant la modification. Le nouveau commit est un fils direct de HEAD, habituellement au sommet de la branche actuelle et la branche est mise à jour pour pointer dessus (à moins qu’aucune branche ne soit associée avec l’arbre de travail actuel, auquel cas HEAD est « détachée » comme décrit dans git-checkout[1]).

Le contenu à valider peut être spécifié de différentes manières :

en utilisant git-add[1] pour « ajouter » de manière incrémentale des modifications à l’index avant d’utiliser la commande commit (Note : les fichiers doivent être « ajoutés » pour faire partie du commit, même s’ils ont été modifiés);
en utilisant git-rm[1] pour supprimer des fichiers de l’arbre de travail et de l’index, encore une fois avant d’utiliser la commande commit;
en listant les fichiers comme arguments de la commande commit (sans les options --interactive ou --patch), auquel cas la validation ignorera les modifications indexées et enregistrera plutôt le contenu actuel des fichiers listés (qui doivent être déjà connus de Git);
en utilisant l’option -a avec la commande commit pour « ajouter » automatiquement les modifications de tous les fichiers connus (c’est-à-dire les fichiers déjà listés dans l’index) et supprimer (rm) automatiquement les fichiers de l’index qui ont été supprimés dans l’arbre de travail, puis d’effectuer la validation ;
en utilisant les options --interactive ou --patch avec la commande commit pour choisir quels fichiers ou sections de fichier doivent être inclus dans le commit en plus de l’index, avant finalisation de l’opération. Référez-vous à la section « Mode interactif » de git-add[1] pour la description de ces modes.

L’option --dry-run peut être utilisée pour obtenir un résumé de ce qui sera inclus par une des commandes ci-dessus pour la prochaine validation en fournissant le même jeu de paramètres (options et chemins).

Si vous validez et trouvez une erreur immédiatement après, vous pouvez annuler la validation avec git reset.

OPTIONS

-a

--all

Indiquer à la commande d’indexer automatiquement les fichiers qui ont été modifiés ou supprimés, mais les nouveaux fichiers dont vous n’avez pas signalé la présence à Git ne sont pas affectés.

-p

--patch

Utiliser la sélection interactive de correctif pour choisir quelles modifications valider. Référez-vous à git-add[1] pour plus de détails.

-C <commit>

--reuse-message=<commit>

Prendre un objet commit existant et réutiliser son message de validation et son information d’auteur (y compris l’horodatage) pour la création du commit.

-c <commit>

--reedit-message=<commit>

Comme -C, mais avec -c, l’éditeur est appelé pour permettre à l’utilisateur de modifier le message de validation.

--fixup=<commit>

Construire un message de validation pour une utilisation avec rebase --autosquash. Le message de validation sera la ligne de titre du commit spécifié préfixée de « fixup ! ». Référez-vous à git-rebase[1] pour de plus amples détails.

--squash=<commit>

Construire un message de validation pour une utilisation avec rebase --autosquash. La ligne de titre du message de validation est tirée du commit spécifié préfixée par « squash! ». Peut être utilisée avec d’autres options de commit (-m/-c/-C/-F). Référez-vous à git-rebase[1] pour plus de détails.

--reset-author

Utilisé avec les options -C/-c/--amend ou lors de validation après un picorage conflictuel, déclarer que la paternité du commit résultant appartient à présent au validateur avec un horodatage mis à jour.

--short

Seulement avec --dry-run, fournir la sortie en format court. Voir git-status[1] pour plus de détails.

--branch

Montrer la branche et l’information de suivi, y compris en format court.

--porcelain

Seulement avec --dry-run, donner la sortie en format compatible porcelaine. Voir git-status[1] pour plus de détails.

--long

Avec --dry-run, donner la sortie en format long. Implique --dry-run.

-z

--null

Avec les sorties de statut short ou porcelain, afficher le nom du fichier textuellement et terminer par NUL, au lieu de LF. Si aucun format n’est spécifié, implique le format de sortie --porcelain. Sans l’option -z, les noms de fichier contenant des caractères « inhabituels » sont indiqués selon la variable de configuration core.quotePath (voir git-config[1]).

-F <fichier>

--file=<fichier>

Prendre le message de validation depuis le fichier indiqué. Utilisez - pour lire le message depuis l’entrée standard.

--author=<auteur>

Surcharger l’auteur du commit. Spécifier un auteur explicite avec le format standard Prénom Nom <auteur@exemple.com>. Sinon <auteur> est considéré comme un patron utilisé pour chercher un commit existant par cet auteur (c-à-d rev-list --all -i --author=<auteur>) ; l’auteur du commit est alors copié depuis le premier commit trouvé.

--date=<date>

Surcharger la date d’auteur utilisée dans le commit.

-m <msg>

--message=<msg>

Utiliser le <msg> fourni comme message de validation. Si plusieurs options -m sont fournies, leurs valeurs sont concaténées comme paragraphes séparés.

L’option -m est incompatible avec -c, -C ou -F.

-t <fichier>

--template=<fichier>

À l’édition du message de validation, démarrer l’éditeur avec le contenu du fichier indiqué. La variable de configuration commit.template est souvent utilisée pour fournir implicitement cette option à la commande. Ce mécanisme peut être utilisé par les projets qui souhaitent guider les collaborateurs avec une aide sur ce qu’il faut écrire dans le message et dans quel ordre. Si l’utilisateur sort de l’éditeur sans changer le message, la validation est annulée. Ceci n’a aucun effet quand un message est fourni par un autre moyen, par exemple par les options -m ou -F.

-s

--signoff

Ajouter une ligne Signed-off-by du validateur à la fin du message de validation. La signification de signoff dépend du projet, mais ceci certifie typiquement que le validateur a les droits de soumettre son travail sous la même licence et accepte un Certificat d’Origine de Développeur (voir http://developercertificate.org/ pour plus d’information).

-n

--no-verify

Cette option court-circuite les crochets pre-commit et commit-msg. Voir aussi githooks[5].

--allow-empty

En général, enregistrer un commit qui pointe sur la même version que son unique parent est une erreur et la commande vous empêche de créer un tel commit. Cette option court-circuite cette sécurité et sert principalement dans les scripts d’interface avec d’autres SCM (Software Configuration Management, gestion de configuration logicielle).

--allow-empty-message

Comme --allow-empty, cette commande est principalement utilisée par les scripts d’interface avec d’autres SCM (Software Configuration Management, gestion de configuration logicielle). Elle vous permet de créer un commit avec un message vide sans utiliser de commande de plomberie telle que git-commit-tree[1].

--cleanup=<mode>

Cette option détermine comment le message de validation fourni doit être nettoyé avant la validation. Le <mode> peut être strip, whitespace, verbatim, scissors ou default.

strip

Supprimer les lignes vides de début et de fin, les espaces, les commentaires et réduire les lignes vides consécutives à une seule.

whitespace

Identique à strip sauf que les #commentaires ne sont pas supprimés.

verbatim

Laisser le message inchangé.

scissors

Identique à whitespace, à l’exception que tout à partir de la ligne ci-dessous (incluse) sera éliminé si le message est édité. "#" peut être personnalisé grâce à core.commentChar.

# ------------------------ >8 ------------------------

default

Identique à strip si le messages est édité. Sinon whitespace.

La valeur par défaut peut être modifiée par la variable de configuration commit.cleanup (voir git-config[1]).

-e

--edit

Le message tiré d’un fichier avec -F, ou de la ligne de commande avec -m, ou depuis un objet commit avec -C est généralement utilisé sans modification. Cette option permet d’éditer au passage le message tiré de ces sources.

--no-edit

Utiliser le message de validation sélectionné sans lancer d’éditeur. Par exemple, git commit --amend --no-edit corrige un commit sans changer son message de validation.

--amend

Remplacer le sommet de la branche actuelle en créant un nouveau commit. L’arbre enregistré est préparé comme d’habitude (incluant l’effet des options -i et -o et les spécificateurs explicites de chemin) et le message du commit originel est utilisé comme point de départ au lieu d’un message vide, quand aucun autre message n’est spécifié à la ligne de commande via des options telles que -m, -F, -c, etc. Le nouveau commit a les mêmes parents et auteur que l’originel (l’option --reset-author peut modifier l’auteur).

C’est un équivalent grossier de :

	$ git reset --soft HEAD^
	$ ... faire autre chose pour obtenir l'arbre correct ...
	$ git commit -c ORIG_HEAD

mais peut être utilisé pour corriger un commit de fusion.

Vous devriez comprendre les implications d’une réécriture de l’historique si vous modifiez un commit qui a déjà été publié. (Voir la section « RATTRAPPER UN REBASAGE AMONT » dans git-rebase[1].)

--no-post-rewrite

Court-circuiter le crochet post-rewrite.

-i

--include

Avant de créer un commit à partir du contenu indexé jusqu’à présent, indexer aussi les contenus des chemins fournis sur la ligne de commande. Cela n’est habituellement pas ce que vous souhaitez, à part si vous terminez une fusion conflictuelle.

-o

--only

Réaliser une validation en prenant le contenu de l’arbre de travail des chemins spécifiés sur la ligne de commande, en ignorant tout contenu d’autres chemins déjà indexé. C’est le mode d’opération par défaut de git commit si des chemins sont fournis sur la ligne de commande, auquel cas l’option peut être omise. Si cette option est spécifiée en même temps que --amend, alors il n’est pas nécessaire de spécifier des chemins, ce qui peut être utile pour corriger le dernier commit sans valider les modifications qui ont déjà été indexées. Si utilisé avec --allow-empty, les chemins ne sont pas nécessaires non plus et un commit vide sera créé.

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

-u[<mode>]

--untracked-files[=<mode>]

Montrer les fichiers non-suivis.

Le paramètre de mode est optionnel (par défaut, all) et sert à spécifier la gestion des fichiers non suivis ; quand -u n’est pas utilisé, le mode par défaut est normal, c’est-à-dire montrer les fichiers et les dossiers non-suivis.

Les options possibles sont :

no - Ne montrer aucun fichier non-suivi
normal - Montrer les fichiers non-suivis et les dossiers dont le contenu est non-suivi
all - Montrer aussi les fichiers dans les dossiers dont le contenu n’est pas suivi.

La valeur par défaut est contenue dans la variable de configuration status.showUntrackedFiles documentée dans git-config[1].

-v

--verbose

Afficher en bas du modèle de message de validation un diff unifié entre le commit HEAD et ce qui serait validé pour aider l’utilisateur à décrire le commit en lui rappelant les modifications qui seront validées. Veuillez noter que cette sortie de diff n’est pas préfixée par des #. Elle ne fera pas pour autant partie du message de validation. Référez-vous à la variable de configuration commit.verbose dans git-config[1].

Si spécifié deux fois, afficher en plus le diff unifié entre ce qui serait validé et les fichiers de l’arbre de travail, c’est-à-dire les modifications non-indexées des fichiers suivis.

-q

--quiet

Supprimer le message de résumé de commit.

--dry-run

Ne pas créer de commit, mais montrer une liste des chemins qui seront validés, une de ceux contenant des modifications locales et qui ne seront pas validés, et une de ceux non-suivis.

--status

Inclure la sortie de git-status[1] dans le modèle de message de validation lors de l’utilisation d’un éditeur pour préparer le message de validation. Activé par défaut, mais peut surcharger la variable de configuration commit.status.

--no-status

Ne pas inclure la sortie de git-status[1] dans le modèle de message de validation lors de l’utilisation d’un éditeur pour préparer le message de validation par défaut.

-S[<idclé>]

--gpg-sign[=<idclé>]

--no-gpg-sign

Signer les commits avec GPG. L’argument idclé est optionnel avec par défaut l’identité du validateur ; si spécifiée, elle doit être collée à l’option sans aucun espace. --no-gpg-sign est utile pour annuler l’effet de la variable de configuration commit.gpgSign ainsi que tout --gpg-sign précédent.

--

Ne pas interpréter les arguments qui suivent comme options.

<spécificateur de chemin>…

Quand un spécifcateur de chemins est fourni sur la ligne de commande, valider le contenu des fichiers correspondants, sans enregistrer les modifications déjà indexées. Le contenu de ces fichiers est aussi indexé pour le commit suivant par-dessus ce qui a été indexé auparavant.

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

EXEMPLES

Lors de l’enregistrement de votre propre travail, le contenu des fichiers modifiés dans votre arbre de travail est temporairement stocké au moyen de git add dans une zone de stockage intermédiaire appelée « l’index ». Un fichier peut n’être ramené à son contenu correspondant au dernier commit seulement dans l’index mais pas dans l’arbre de travail grâce à git restore --staged <fichier>, ce qui inverse effectivement le git add et empêche les modifications de ce fichier de participer à la prochaine validation. Après avoir construit l’état à valider de manière incrémentale avec ces commandes, git commit (sans aucun nom de chemin en paramètre) sert à enregistrer ce qui a été préparé jusqu’ici. C’est la forme la plus simple de la commande. Par exemple :

$ edit hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit

Au lieu d’indexer les fichiers après chaque modification individuelle, vous pouvez ordonner à git commit d’inspecter les modifications des fichiers dont le contenu est déjà suivi dans votre arbre de travail et de réaliser les git add et git rm correspondant pour vous. De fait, l’exemple suivant fait la même chose que l’exemple précédent si aucune autre modification n’a eu lieu dans votre arbre de travail :

$ edit hello.c
$ rm goodbye.c
$ git commit -a

La commande git commit -a inspecte votre arbre de travail, remarque que vous avez modifié hello.c et supprimé goodbye.c, puis réalise les git add et git rm nécessaires pour vous.

Après l’indexation des modifications de nombreux fichiers, vous pouvez modifier l’ordre dans lequel les modifications sont enregistrées, en fournissant des chemins à git commit. Quand ces chemins sont fournis, la commande crée un commit qui n’enregistre que les modifications des chemins indiqués :

$ edit hello.c hello.h
$ git add hello.c hello.h
$ edit Makefile
$ git commit Makefile

Ceci crée un commit qui enregistre les modifications de Makefile. Les modifications indexées pour hello.c et hello.h ne sont pas incluses dans le commit résultant. Cependant, leurs modifications ne sont pas perdues — elles sont toujours indexées et simplement suspendues. Après la séquence ci-dessus, si vous faites :

$ git commit

cette seconde validation enregistrerait les modifications de hello.c et hello.h comme attendu.

Après l’arrêt d’une fusion (commencée avec git merge ou git pull) pour cause de conflit, les chemins fusionnés proprement sont déjà indexés pour vous, et les chemins en conflit sont laissés dans un état non-fusionné. Vous auriez à chercher d’abord les chemins en conflit avec git status et après les avoir corrigés manuellement dans votre copie de travail, vous les indexeriez comme d’habitude avec git add :

$ git status | grep non-fusionné
non-fusionné : hello.c
$ edit hello.c
$ git add hello.c

Après avoir résolu les conflits et indexé le résultat, git ls-files -u arrêterait de mentionner les chemins en conflit. Quand vous avez terminé, lancez git commit pour finaliser la validation de la fusion :

$ git commit

Comme dans le cas de la validation de vos propres modifications, vous pouvez utiliser l’option -a pour vous épargner de la frappe. Une différence est que pendant la résolution de fusion, vous ne pouvez pas utiliser git commit avec des noms de chemin pour changer l’ordre des modifications à valider, parce que la fusion doit être enregistrée comme un commit unique. En fait, la commande refuse d’être lancée avec des noms de chemin (voir par contre l’option -i).

INFORMATION DE VALIDATION

Les informations sur les auteurs et les validateurs sont tirées des variables d’environnement suivantes, si elles sont définies :

GIT_AUTHOR_NAME
GIT_AUTHOR_EMAIL
GIT_AUTHOR_DATE
GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE

(nota bene "<", ">" et "\n"s sont supprimés)

Les noms de l’auteur et du validateur sont par convention une forme de nom personnel (c’est-à-dire le nom par lequel les autres humains vous désignent), bien que Git n’impose ou n’exige aucune forme particulière. N’importe quel unicode peut être utilisé, sous réserve des contraintes énumérées ci-dessus. Ce nom n’a aucun effet sur l’authentification ; pour cela, voir la variable credential.username dans git-config[1].

Dans le cas où (certaines de) ces variables d’environnement ne sont pas définies, les informations sont prises à partir des éléments de configuration user.name et user.email, ou, si elle n’est pas présente, la variable d’environnement EMAIL, ou, si ce n’est pas réglé, le nom d’utilisateur du système et le nom d’hôte utilisé pour le courrier sortant (pris depuis /etc/mailname et ou par défaut le nom d’hôte entièrement qualifié lorsque ce fichier n’existe pas).

Les options author.name et committer.name et leurs options de courrier électronique correspondantes remplacent les options user.name et user.email si elles sont définies et sont elles-mêmes remplacées par les variables d’environnement.

L’utilisation typique consiste à définir uniquement les variables user.name et user.email ; les autres options sont fournies pour les cas d’utilisation plus complexes.

FORMATS DE DATE

Les variables d’environnement GIT_AUTHOR_DATE, GIT_COMMITTER_DATE et l’option --date prend en charge les formats de date suivants :

Format interne de Git

Il est de la forme <horodatage unix> <décalage de fuseau horaire>, où <horodatage unix> est un nombre de secondes depuis l’époque UNIX. <décalage de fuseau horaire> est un décalage positif ou négative par rapport à UTC. Par exemple, CET (qui est en avance d’une heure sur UTC) est +0100.

RFC 2822

Le standard de format des courriel tel que décrit par la RFC 2822, par exemple Thu, 07 Apr 2005 22:13:13 +0200.

ISO 8601

Les heures et les dates sont spécifiées par le standard ISO 8601, par exemple 2005-04-07T22:13:13. L’analyseur accepte aussi un espace au lieu du caractère T. Les parties fractionnelles d’une seconde seront ignorées, par exemple, 2005-04-07T22:13:13.019 sera considéré comme étant 2005-04-07T22:13:13.

Note	De plus, la partie date est acceptée dans les formats suivants : `AAAA.MM.JJ`, `MM/JJ/AAAA` et `JJ.MM.AAAA`.

DISCUSSION

Bien que ça ne soit pas requis, c’est une bonne pratique de commencer les messages de validation avec une seule ligne courte (moins de 50 caractères) pour résumer la modification, suivie d’une ligne blanche, suivie d’un description plus précise. Le texte jusqu’à la ligne vide du message de validation est traité comme le titre du commit, et ce titre est utilisé extensivement dans Git. Par exemple, git-format-patch[1] transforme un commit en courriel et utilise le titre comme sujet et le reste du texte comme corps.

Git est dans une certaine mesure agnostique concernant l’encodage des caractères.

Le contenu des objets blob est une séquence d’octets non interprétés. Il n’y a pas de conversion d’encodage au niveau de base.
Les noms de chemins sont encodés en forme C de normalisation UTF-8. Ceci s’applique aux objets arbre, au fichier d’index, au noms de références ainsi qu’aux noms de chemin en argument de ligne de commande, aux variables d’environnement et aux fichiers de configuration (.git/config (voir git-config[1]), gitignore[5], gitattributes[5] and gitmodules[5]).

Remarquez que Git traite les noms de chemins comme des séquences d’octets non-nuls au niveau de base, il n’y a pas de conversion d’encodage des noms de fichiers (sauf sur Mac et Windows). De ce fait, l’utilisation de noms de chemins non-ASCII fonctionnera pratiquement, même sur les plateformes et systèmes de fichier utilisant d’anciens encodages d’ASCII étendu.
Les messages du journal des validations sont typiquement encodés en UTF-8, mais les autres encodages d’ASCII étendu sont aussi pris en charge. Ceci inclut ISO-8859-x, CP125x et de nombreux autres, mais pas UTF-16/32, EBCDIC ni les encodages multi-octets CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).

Bien que l’usage de UTF-8 dans les messages de validation soit encouragé, le cœur de Git et la porcelaine sont conçus pour ne pas forcer l’usage d’UTF-8 dans les projets. Si tous les participants d’un projet donné trouvent plus simple d’utiliser des encodages anciens, Git ne l’interdit pas. Cependant, il y a quelques détails à garder en tête.

git commit et git commit-tree affichent un avertissement si le message de validation fourni ne semble pas être une chaîne de caractères UTF-8 valide, à moins que vous n’indiquiez explicitement que votre projet utilise un encodage ancien. La manière de l’indiquer est d’avoir i18n.commitencoding dans .git/config, comme ceci :
```
[i18n]
	commitEncoding = ISO-8859-1
```
Les objets commit créés avec le réglage ci-dessus enregistrent la valeur de i18n.commitEncoding dans leur entête d’encodage encoding. Ceci permet d’aider les personnes qui les liront plus tard. L’absence de cet entête implique que les message de validation est encodé en UTF-8.
Sauf indication contraire, git log, git show, git blame et consort lisent l’entête encoding d’un objet commit et essaient de ré-encoder le message de validation en UTF-8. Vous pouvez spécifier l’encodage de sortie que vous souhaitez avec i18n.logOutputEncoding dans le fichier .git/config, comme ceci :
```
[i18n]
	logOutputEncoding = ISO-8859-1
```
Si vous n’avez pas changé cette variable de configuration, c’est la valeur de i18n.commitEncoding qui est utilisée.

Remarquez qu’il a été délibérément choisi de ne pas ré-encoder le message de validation quand le commit est créé pour forcer l’UTF-8 au niveau de l’objet commit parce que ré-encoder en UTF-8 n’est pas nécessairement une opération réversible.

ENVIRONNEMENT ET VARIABLES DE CONFIGURATION

L’éditeur utilisé pour éditer le message de validation sera choisi dans l’ordre de recherche depuis la variable d’environnement GIT_EDITOR, puis depuis la variable de configuration core.editor, puis depuis la variable d’environnement VISUAL ou la variable d’environnement EDITOR. Voir git-var[1] pour plus de détails.

CROCHETS

Cette commande peut lancer les crochets commit-msg, prepare-commit-msg, pre-commit, post-commit et post-rewrite. Voir githooks[5] pour de plus amples informations.

FICHIERS

$GIT_DIR/COMMIT_EDITMSG: Ce fichier contient le message de validation en cours. Si git commit sort à cause d’une erreur avant de créer un commit, tout message de validation fourni par l’utilisateur (par exemple dans une session d’éditeur) sera disponible dans ce fichier, mais sera écrasé par l’invocation suivante de git commit.

VOIR AUSSI

git-add[1], git-rm[1], git-mv[1], git-merge[1], git-commit-tree[1]

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 .

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands

NOM