Viewing: git-scm.com

Franais Topics Latest version git-commit last updated in 2.55.0

Changes in the git-commit manual

2.55.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2026-06-29
2.54.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2026-04-20
2.53.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2026-02-02
2.52.0 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2025-11-17
2.51.1 2.51.2 no changes
2.51.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2025-08-18
2.50.1 no changes
2.50.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] 2025-06-16
2.49.1 no changes
2.49.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2025-03-14
2.46.2 2.48.2 no changes
2.46.1 [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2024-09-13
2.45.1 2.46.0 no changes
2.45.0 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2024-04-29
2.43.2 2.44.4 no changes
2.43.1 [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2024-02-09
2.43.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2023-11-20
2.38.1 2.42.4 no changes
2.38.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2022-10-02
2.35.1 2.37.7 no changes
2.35.0 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2022-01-24
2.34.1 2.34.8 no changes
2.34.0 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2021-11-15
2.33.1 2.33.8 no changes
2.33.0 [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2021-08-16
2.32.1 2.32.7 no changes
2.32.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2021-06-06
2.31.1 2.31.8 no changes
2.31.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2021-03-15
2.30.1 2.30.9 no changes
2.30.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2020-12-27
2.27.1 2.29.3 no changes
2.27.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2020-06-01
2.25.2 2.26.3 no changes
2.25.1 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2020-02-17
2.25.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2020-01-13
2.24.1 2.24.4 no changes
2.24.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2019-11-04
2.23.1 2.23.4 no changes
2.23.0 [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2019-08-16
2.21.1 2.22.5 no changes
2.21.0 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2019-02-24
2.17.0 2.20.5 no changes
2.16.6 [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2019-12-06
2.14.6 2.15.4 no changes
2.13.7 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2018-05-22
2.12.5 [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2017-09-22
2.11.4 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2017-09-22
2.10.5 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2017-09-22
2.9.5 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2017-07-30
2.8.6 no changes
2.7.6 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2017-07-30
2.6.7 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2017-05-05
2.5.6 no changes
2.4.12 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2017-05-05
2.3.10 no changes
2.2.3 [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] [grey-dot.png] 2015-09-04
2.1.4 no changes
2.0.5 [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [green-dot.png] [red-dot.png] [red-dot.png] [grey-dot.png] [grey-dot.png] 2014-12-17

Check your version of git by running

git --version

NOM

git-commit - Enregistrer les modifications dans le dpt

SYNOPSIS

git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend]
	   [--dry-run] [(-c | -C | --squash) <commit>] | --fixup <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]]
	   [(--trailer <token>[(=|:)<valeur>])…] [-S[<idcl>]]
	[--] [<spec-de-chemin>…]

DESCRIPTION

Cre un nouveau commit contenant le contenu actuel de l’index et avec le message de validation dcrivant 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 associe avec l’arbre de travail actuel, auquel cas HEAD est dtache comme dcrit dans git-checkout[1]).

Le contenu valider peut tre spcifi de diffrentes manires:

en utilisant git-add[1] pour ajouter de manire incrmentale des modifications l’index avant d’utiliser la commande 'commit (Note: les fichiers doivent tre ajouts pour faire partie du commit, mme s’ils ont t modifis);
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 le commit ignorera les modifications indexes et enregistrera plutt le contenu actuel des fichiers lists (qui doivent tre dj 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 dj lists dans l’index) et supprimer (rm) automatiquement les fichiers de l’index qui ont t supprims dans l’arbre de travail, puis d’effectuer le commit ;
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’opration. Rfrez-vous la section Mode interactif de git-add[1] pour la description de ces modes.

L’option --dry-run peut tre utilise pour obtenir un rsum de ce qui sera inclus par une des commandes ci-dessus pour le prochain commit en fournissant le mme jeu de paramtres (options et chemins).

Si vous validez et trouvez une erreur immdiatement aprs, vous pouvez annuler le commit avec git reset.

OPTIONS

-a
--all: Indexer automatiquement les fichiers qui ont t modifis ou supprims, mais les nouveaux fichiers dont vous n’avez pas signal la prsence Git ne sont pas affects.
-p
--patch: Utiliser la slection interactive de correctif pour choisir quelles modifications valider. Rfrez-vous git-add[1] pour plus de dtails.
-U<n>
--unified=<n>: Gnrer des diffs avec <n> lignes de contexte. Le nombre de lignes de contexte par dfaut diff.context ou 3 si la variable de configuration est indfinie. (-U sans <n> est silencieusement accept comme synonyme de -p en raison d’un accident historique.
--inter-hunk-context=<n>: Afficher le contexte entre des sections de diff, jusqu’au <nombre> spcifi de lignes, fusionnant de ce fait les sections qui sont proches. Par dfaut, diff.interHunkContext ou 0 si l’option de configuration n’est pas configure.

-C <commit>
--reuse-message=<commit>: Prendre un objet <commit> existant et rutiliser son message de validation et son information d’auteur (y compris l’horodatage) pour la cration 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=[(amend|reword):]<commit>: Crer un nouveau commit qui rpare <commit> quand il est appliqu avec git rebase --autosquash. Un simple --fixup=<commit> cre un commit "fixup!" qui change le contenu de <commit> mais laisse son message de validation inchang. --fixup=amend:<commit> est similaire mais cre un commit "amend!" qui remplace aussi le message de validation de <commit> par le message de validation du commit "amend!". --fixup=reword:<commit> cre un commit "amend!" qui remplace le message de validation de <commit> par son propre message de log mais ne fait aucun changement au contenu de <commit>.

Le commit cr par le simple --fixup=<commit> a un titre compos de "fixup!" suivi du titre de <commit>, et est reconnu spcialement par git rebase --autosquash. L’option -m peut tre utilise pour complter le message du journal du commit cr, mais le commentaire supplmentaire sera jet une fois que le commit "fixup!" sera cras dans <commit> par git rebase --autosquash.

Le commit cr par --fixup=amend:<commit> est similaire mais son sujet est la place prfix par "amend!". Le message de validation de <commit> est copi dans le message de validation du commit "amend!" et ouvert dans un diteur afin qu’il puisse tre affin. Lorsque git rebase --autosquash crase le commit "amend!" dans <commit>, le message de validation de <commit> est remplac par le message de validation raffin du commit "amend!". C’est une erreur si le message du journal du commit "amend!" est vide, moins que --allow-empty-message soit spcifi.

--fixup=reword:<commit> est un raccourci pour --fixup=amend:<commit> --only. Il cre un commit "amend!" qui touche seulement au message de validation (en ignorant les changements mis en place dans l’index). Lorsqu’il est cras par git rebase --autosquash, il remplace le message du commit de <commit> sans faire d’autres changements.

Ni les commits "fixup!" ni les commits "amend!" ne changent la paternit de <commit> quand ils sont appliqus par git rebase --autosquash. Voir git-rebase[1] pour plus de dtails.
--squash=<commit>: Construire un message de validation pour une utilisation avec git rebase --autosquash. La ligne de titre du message de validation est tire du commit spcifi prfixe par squash!. Peut tre utilise avec d’autres options de commit (-m/-c/-C/-F). Rfrez-vous git-rebase[1] pour plus de dtails.
--reset-author: Utilis avec les options -C/-c/--amend ou lors de commit aprs un picorage conflictuel, dclarer que la paternit du commit rsultant appartient prsent au validateur avec un horodatage mis jour.
--short: Lors d’un essai sans effet, fournir la sortie en format court. Voir git-status[1] pour plus de dtails. implique --dry-run.
--branch: Montrer la branche et l’information de suivi, y compris en format court. voir git-status[1] pour plus de dtails.
--porcelain: Lors d’un essai sans effet, fournir la sortie en format prt pour la porcelaine. Voir git-status[1] pour plus de dtails. implique --dry-run.
--long: Lors d’un essai sans effet, fournir la sortie en format long. C’est la sortie par dfaut de git-status[1]. Implique --dry-run.
-z
--null: Avec les sorties de git-status[1] short ou porcelain, afficher le nom du fichier textuellement et terminer par NUL, au lieu de LF. Si aucun format n’est spcifi, implique le format de sortie --porcelain. Sans l’option -z, les noms de fichier contenant des caractres inhabituels sont indiqus selon la variable de configuration core.quotePath (voir git-config[1]).
-F <fichier>
--file=<fichier>: Prendre le message de validation depuis le <fichier>. Utilisez - pour lire le message depuis l’entre standard.
--author=<auteur>: Surcharger l’auteur du commit. Spcifier un auteur explicite avec le format standard Prnom Nom <auteur@exemple.com>. Sinon <auteur> est considr comme un patron utilis pour chercher un commit existant par cet auteur (c--d git 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 utilise dans le commit.
-m <msg>
--message=<msg>: Utiliser le <msg> fourni comme message de validation. Si plusieurs options -m sont fournies, leurs valeurs sont concatnes comme paragraphes spars.

L’option -m est incompatible avec -c, -C ou -F.
-t <fichier>
--template=<fichier>: l’dition du message de validation, dmarrer l’diteur avec le contenu du <fichier>. La variable de configuration commit.template est souvent utilise pour fournir implicitement cette option la commande. Ce mcanisme 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, le commit est annul. Ceci n’a aucun effet quand un message est fourni par un autre moyen, par exemple par les options -m ou -F.
-s
--signoff
--no-signoff: Ajouter une ligne finale Signed-off-by du validateur la fin du message de validation. La signification de signoff dpend du projet sur lequel vous validez. Par exemple, cela peut certifier que le validateur a le droit de soumettre son travail sous la licence du projet ou accepte une certaine reprsentation du contributeur, tel qu’un Certificat d’Origine de Dveloppeur. (Voir https://developercertificate.org/ pour celui utilis par les projet du noyau Linux ou de Git). Consultez la documentation ou la direction du projet auquel vous contribuez pour comprendre comment les signatures sont utilises dans ce projet.

L’option --no-signoff peut tre utilise pour contrecarrer une option --signoff prcdente sur la ligne de commande.

Git n’a pas (et n’aura pas) de variable de configuration pour activer l’option de ligne de commande --signoff par dfaut; voir l’entre commit.signoff dans gitfaq[7] pour plus de dtails.

--trailer <jeton>[(=|:)<valeur>]

Spcifier une paire (<jeton>, <valeur>) qui doit tre applique comme une ligne terminale (par exemple, git commit --trailer "Signed-off-by:C O Mitter \ <committer@example.com>" --trailer "Helped-by:C O Mitter \ <committer@example.com>" ajoutera la ligne terminale Signed-off-by et la ligne terminale Helped-by au message de validation). Les variables de configuration trailer.* (git-interpret-trailers[1]) peuvent tre utilises pour dfinir si une ligne terminale duplique est omise, ou o chaque ligne terminale apparatrait dans la srie de lignes terminales, et d’autres dtails.

-n

--verify

--no-verify

Court-circuiter les crochets pre-commit et commit-msg. Voir aussi githooks[5].

--allow-empty

En gnral, enregistrer un commit qui pointe sur la mme version que son unique parent est une erreur et la commande vous empche de crer un tel commit. Cette option court-circuite cette scurit et sert principalement dans les scripts d’interface avec d’autres SCM (Software Configuration Management, gestion de configuration logicielle).

--allow-empty-message

Crer un commit avec un message de validation vide sans utiliser des commandes de plomberie comme git-commit-tree[1]. Comme --allow-empty, cette commande est principalement utilise par les scripts d’interface de SCM externes.

--cleanup=<mode>

Dterminer comment le message de validation fourni doit tre nettoy avant le commit. Le <mode> peut tre strip, whitespace, verbatim, scissors ou default.

strip

Supprimer les lignes vides de dbut et de fin, les espaces, les commentaires et rduire les lignes vides conscutives une seule.

whitespace

Identique strip sauf que les #commentaires ne sont pas supprims.

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 grce core.commentChar.

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

default

Identique strip si le messages est dit. Sinon whitespace.

La valeur par dfaut peut tre modifie par la variable de configuration commit.cleanup (voir git-config[1]).

-e

--edit

Laissez l’utilisateur diter plus avant le message pris partir de <fichier> avec -F <fichier>, la ligne de commande avec -m <message>, et de <commit> avec -C <commit>.

--no-edit

Utiliser le message de validation slectionn 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 crant un nouveau commit. L’arbre enregistr est prpar comme d’habitude (incluant l’effet des options -i et -o et les spcificateurs explicites de chemin) et le message du commit originel est utilis comme point de dpart au lieu d’un message vide, quand aucun autre message n’est spcifi la ligne de commande via des options telles que -m, -F, -c, etc. Le nouveau commit a les mmes 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 rcriture de l’historique si vous modifiez un commit qui a dj 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 crer un commit partir du contenu index jusqu’ prsent, 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

Raliser un commit en prenant le contenu de l’arbre de travail des chemins spcifis sur la ligne de commande, en ignorant tout contenu d’autres chemins dj index. C’est le mode d’opration par dfaut de git commit si des chemins sont fournis sur la ligne de commande, auquel cas l’option peut tre omise. Si cette option est spcifie en mme temps que --amend, alors il n’est pas ncessaire de spcifier des chemins, ce qui peut tre utile pour corriger le dernier commit sans valider les modifications qui ont dj t indexes. Si utilis avec --allow-empty, les chemins ne sont pas ncessaires non plus et un commit vide sera cr.

--pathspec-from-file=<fichier>

Passer le spcificateur de chemin <fichier> au lieu des arguments de la ligne de commande. Si <fichier> vaut - alors l’entre standard est utilise. Les lments du spcificateur de chemin sont spars par LF ou CR/LF. Les lments du spcificateur de chemin peuvent tre cits 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 lments du spcificateur de chemin sont spars par le caractre NUL et tous les autres caractres sont utiliss littralement (y compris les retours la ligne et les guillemets).

-u[<mode>]

--untracked-files[=<mode>]

Montrer les fichiers non-suivis.

Le paramtre de <mode> est optionnel (par dfaut, all) et sert spcifier la gestion des fichiers non suivis; quand -u n’est pas utilis, le mode par dfaut 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.

Toutes les expressions pour la valeur boolenne true sont interprtes comme normal et false comme no. La valeur par dfaut est contenue dans la variable de configuration status.showUntrackedFiles documente dans git-config[1].

-v

--verbose

Afficher en bas du modle de message de validation un diff unifi entre le commit HEAD et ce qui serait valid pour aider l’utilisateur dcrire le commit en lui rappelant les modifications qui seront valides. Veuillez noter que cette sortie de diff n’est pas prfixe par des #. Elle ne fera pas pour autant partie du message de validation. Rfrez-vous la variable de configuration commit.verbose dans git-config[1].

Si spcifi 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-indexes des fichiers suivis.

-q

--quiet

Supprimer le message de rsum de commit.

--dry-run

Ne pas crer de commit, mais montrer une liste des chemins qui seront valids, une de ceux contenant des modifications locales et qui ne seront pas valids, et une de ceux non-suivis.

--status

Inclure la sortie de git-status[1] dans le modle de message de validation lors de l’utilisation d’un diteur pour prparer le message de validation. Activ par dfaut, mais peut surcharger la variable de configuration commit.status.

--no-status

Ne pas inclure la sortie de git-status[1] dans le modle de message de validation lors de l’utilisation d’un diteur pour prparer le message de validation par dfaut.

-S[<id-cl>]

--gpg-sign[=<id-cl>]

--no-gpg-sign

Signer les commits avec GPG. L’argument <id-cl> est optionnel avec par dfaut l’identit du validateur; si spcifie, elle doit tre colle 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 prcdent.

--

Ne pas interprter les arguments qui suivent comme options.

<spcificateur-de-chemin>...

Quand un <spcifcateur-de-chemin> est fourni sur la ligne de commande, valider le contenu des fichiers correspondants, sans enregistrer les modifications dj indexes. Le contenu de ces fichiers est aussi index pour le commit suivant par-dessus ce qui a t index auparavant.

Pour plus de dtail, voir l’entre spcificateur de chemin dans gitglossary[7].

EXEMPLES

Lors de l’enregistrement de votre propre travail, le contenu des fichiers modifis dans votre arbre de travail est temporairement stock au moyen de git add dans une zone de stockage intermdiaire appele l’index. Un fichier peut n’tre ramen son contenu correspondant au dernier commit seulment dans l’index mais pas dans l’arbre de travail grce git restore --staged <fichier>, ce qui inverse effectivement le git add et empche les modifications de ce fichier de participer le prochain commit. Aprs avoir construit l’tat valider de manire incrmentale avec ces commandes, git commit (sans aucun nom de chemin en paramtre) sert enregistrer ce qui a t prpar 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 aprs chaque modification individuelle, vous pouvez ordonner git commit d’inspecter les modifications des fichiers dont le contenu est dj suivi dans votre arbre de travail et de raliser les git add et git rm correspondant pour vous. De fait, l’exemple suivant fait la mme chose que l’exemple prcdent 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 ralise les git add et git rm ncessaires pour vous.

Aprs l’indexation des modifications de nombreux fichiers, vous pouvez modifier l’ordre dans lequel les modifications sont enregistres, en fournissant des chemins git commit. Quand ces chemins sont fournis, la commande cre un commit qui n’enregistre que les modifications des chemins indiqus:

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

Ceci cre un commit qui enregistre les modifications de Makefile. Les modifications indexes pour hello.c et hello.h ne sont pas incluses dans le commit rsultant. Cependant, leurs modifications ne sont pas perdues — elles sont toujours indexes et simplement suspendues. Aprs la squence ci-dessus, si vous faites:

$ git commit

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

Aprs l’arrt d’une fusion (commence avec git merge ou git pull) pour cause de conflit, les chemins fusionns proprement sont dj indexs pour vous, et les chemins en conflit sont laisss dans un tat non-fusionn. Vous auriez chercher d’abord les chemins en conflit avec git status et aprs les avoir corrigs manuellement dans votre copie de travail, vous les indexeriez comme d’habitude avec git add:

$ git status | grep unmerged
unmerged: hello.c
$ edit hello.c
$ git add hello.c

Aprs avoir rsolu les conflits et index le rsultat, git ls-files -u arrterait de mentionner les chemins en conflit. Quand vous avez termin, lancez git commit pour finaliser le commit de la fusion:

$ git commit

Comme dans le cas du commit de vos propres modifications, vous pouvez utiliser l’option -a pour vous pargner de la frappe. Une diffrence est que pendant la rsolution 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 enregistre comme un commit unique. En fait, la commande refuse d’tre lance avec des noms de chemin (voir par contre l’option -i).

INFORMATION DE VALIDATION

Les informations sur les auteurs et les validateurs sont tires des variables d’environnement suivantes, si elles sont dfinies :

GIT_AUTHOR_NAME
GIT_AUTHOR_EMAIL
GIT_AUTHOR_DATE
GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE

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

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 dsignent), bien que Git n’impose ou n’exige aucune forme particulire. N’importe quel unicode peut tre utilis, sous rserve des contraintes numres 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 denvironnement ne sont pas dfinies, les informations sont prises partir des lments de configuration user.name et user.email, ou, si elle nest pas prsente, la variable denvironnement EMAIL, ou, si ce nest pas rgl, le nom dutilisateur du systme et le nom dhte utilis pour le courrier sortant (pris depuis /etc/mailname et ou par dfaut le nom dhte entirement qualifi lorsque ce fichier nexiste 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 dfinies et sont elles-mmes remplaces par les variables d’environnement.

L’utilisation typique consiste dfinir 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 et GIT_COMMITTER_DATE supportent les formats de date suivants :

Format interne de Git

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

RFC 2822

Le standard de format de date tel que dcrit par la RFC 2822, par exemple Thu, 07 Apr 2005 22:13:13 +0200.

ISO 8601

Les heures et les dates sont spcifies par le standard ISO 8601, par exemple 2005-04-07T22:13:13. L’analyseur accepte aussi un espace au lieu du caractre T. Les parties fractionnelles d’une seconde seront ignores, par exemple, 2005-04-07T22:13:13.019 sera considr comme tant 2005-04-07T22:13:13.

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

En plus de reconnatre tous les formats de date ci-dessus, l’option --date essaiera galement de donner un sens d’autres formats de date plus humainement comprhensibles, tels que les dates relatives comme "yesterday" ou "last Friday at noon".

DISCUSSION

Bien que a ne soit pas requis, c’est une bonne pratique de commencer les messages de validation avec une seule ligne courte (pas plus de 50 caractres) pour rsumer la modification, suivie d’une ligne blanche, suivie d’un description plus prcise. 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 caractres.

Le contenu des objets blob est une squence d’octets non interprts. Il n’y a pas de conversion d’encodage au niveau de base.
Les noms de chemins sont encods en forme C de normalisation UTF-8. Ceci s’applique aux objets arbre, au fichier d’index, au noms de rfrences 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 squences 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, mme sur les plateformes et systmes de fichier utilisant d’anciens encodages d’ASCII tendu.
Les messages du journal des validations sont typiquement encods 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 cur de Git et la porcelaine sont conus 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 dtails garder en tte.

git commit et git commit-tree affichent un avertissement si le message de validation fourni ne semble pas tre une chane de caractres UTF-8 valide, moins que vous n’indiquiez explicitement que votre projet utilise un encodage ancien. La manire de l’indiquer est d’avoir i18n.commitEncoding dans .git/config, comme ceci:
```
[i18n]
	commitEncoding = ISO-8859-1
```
Les objets commit crs avec le rglage ci-dessus enregistrent la valeur de i18n.commitEncoding dans leur entte d’encodage encoding. Ceci permet d’aider les personnes qui les liront plus tard. L’absence de cet entte implique que les message de validation est encod en UTF-8.
Sauf indication contraire, git log, git show, git blame et consort lisent l’entte encoding d’un objet commit et essaient de r-encoder le message de validation en UTF-8. Vous pouvez spcifier 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 utilise.

Remarquez qu’il a t dlibrment 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 ncessairement une opration rversible.

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

Tout ce qui se trouve au-dessus de cette ligne dans cette section n’est pas inclus dans la documentation git-config[1]. Le contenu qui suit est le mme que celui qui s’y trouve :

commit.cleanup: Ce paramtre surcharge la valeur par dfaut de l’option --cleanup dans git commit. Changer la valeur par dfaut peut tre utile lorsque vous voulez toujours garder des lignes qui commencent par le caractre de commentaire (core.commentChar, par dfaut #) dans votre message de journal, auquel cas vous feriez git config commit.cleanup whitespace (notez que vous devrez supprimer les lignes d’aide qui commencent par le caractre de commentaire dans le modle de journal de validation vous-mme, si vous le faites).
commit.gpgSign: Un boolen pour spcifier si tous les commits doivent tre signs GPG. L’utilisation de cette option lors d’oprations telles que le rebasage peut entraner un grand nombre de signature de commits. Il peut tre pratique d’utiliser un agent pour viter de taper votre mot de passe GPG plusieurs fois.
commit.status: Un boolen pour activer/dsactiver l’inclusion d’information de status dans le modle de message de validation lors de l’utilisation d’un diteur pour prparer le message de validation. Valeur par dfaut true.
commit.template: Spcifier le nom de chemin d’un fichier utiliser comme modle pour de nouveaux messages de validation.
commit.verbose: Un boolen ou un int pour prciser le niveau de verbosit avec git commit.

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

GIT

Fait partie de la suite git[1]

TRADUCTION

Cette page de manuel a t traduite par Jean-Nol 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