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.46.2 → 2.47.0 no changes
- 2.46.1 09/13/24
- 2.45.1 → 2.46.0 no changes
- 2.45.0 04/29/24
- 2.43.2 → 2.44.2 no changes
- 2.43.1 02/09/24
- 2.43.0 11/20/23
- 2.38.1 → 2.42.3 no changes
- 2.38.0 10/02/22
- 2.35.1 → 2.37.7 no changes
- 2.35.0 01/24/22
- 2.34.1 → 2.34.8 no changes
- 2.34.0 11/15/21
- 2.33.1 → 2.33.8 no changes
- 2.33.0 08/16/21
- 2.32.1 → 2.32.7 no changes
- 2.32.0 06/06/21
- 2.31.1 → 2.31.8 no changes
- 2.31.0 03/15/21
- 2.30.1 → 2.30.9 no changes
- 2.30.0 12/27/20
- 2.27.1 → 2.29.3 no changes
- 2.27.0 06/01/20
- 2.25.2 → 2.26.3 no changes
- 2.25.1 02/17/20
- 2.25.0 01/13/20
- 2.24.1 → 2.24.4 no changes
- 2.24.0 11/04/19
- 2.23.1 → 2.23.4 no changes
- 2.23.0 08/16/19
- 2.21.1 → 2.22.5 no changes
- 2.21.0 02/24/19
- 2.17.0 → 2.20.5 no changes
- 2.16.6 12/06/19
- 2.14.6 → 2.15.4 no changes
- 2.13.7 05/22/18
- 2.12.5 09/22/17
- 2.11.4 09/22/17
- 2.10.5 09/22/17
- 2.9.5 07/30/17
- 2.8.6 no changes
- 2.7.6 07/30/17
- 2.6.7 05/05/17
- 2.5.6 no changes
- 2.4.12 05/05/17
- 2.3.10 no changes
- 2.2.3 09/04/15
- 2.1.4 no changes
- 2.0.5 12/17/14
SYNOPSIS
git commit [-a | --interactive | --patch] [-s] [-v] [-u<mode>] [--amend] [--dry-run] [(-c | -C | --squash) <commit>] | --fixup [(amend|reword):]<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
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=[(amend|reword):]<commit>
-
Créer un nouveau commit qui « répare »
<commit>
quand il est appliqué avecgit rebase --autosquash`
. Un simple--fixup=<commit>
crée un commit "fixup!" qui change le contenu de<commit>
mais laisse son message de validation inchangé.--fixup=amend:<commit>
est similaire mais crée un commit "amend!" qui remplace aussi le message de validation de<commit>
par le message de validation du commit "amend!".--fixup=reword:<commit>
crée 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 sujet composé de "fixup !" suivi de la ligne de sujet de <commit>, et est reconnu spécialement pargit rebase --autosquash
. L’option-m
peut être utilisée pour compléter le message du journal du commit créé, mais le commentaire supplémentaire sera jeté une fois que le commit "fixup !" sera écrasé dans<commit>
pargit rebase --autosquash
.Le commit créé par
--fixup=amend:<commit>
est similaire mais son sujet est à la place préfixé 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é. Lorsquegit 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 spécifié.--fixup=reword:<commit>
est un raccourci pour--fixup=amend:<commit> --only
. Il crée un commit "amend !" qui touche seulement au message de validation (en ignorant les changements mis en place dans l’index). Lorsqu’il est écrasé pargit rebase --autosquash
, il remplace le message du validation de<commit>
sans faire d’autres changements.Ni les commits "fixup!" ni les commits "amend!" ne changent la paternité de
<commit>
quand ils sont appliqués pargit rebase --autosquash
. Voir git-rebase[1] pour plus de 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
-
Lors d’un essai sans effet, fournir la sortie en format court. Voir git-status[1] pour plus de détails. implique
--dry-run
. - --branch
-
Montrer la branche et l’information de suivi, y compris en format court.
- --porcelain
-
Lors d’un essai sans effet, fournir la sortie en format prêt pour la porcelaine. Voir git-status[1] pour plus de détails. implique
--dry-run
. - --long
-
Avec --dry-run, donner la sortie en format long. Implique
--dry-run
. - -z
- --null
-
Avec les sorties de statut
short
ouporcelain
, 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 configurationcore.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
- --no-signoff
-
Ajouter une ligne finale
Signed-off-by
du validateur à la fin du message de validation. La signification de signoff dépend 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 représentation du contributeur, tel qu’un Certificat d’Origine de Développeur. (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 utilisées dans ce projet.L’option --no-signoff peut être utilisée pour contrecarrer une option --signoff précédente sur la ligne de commande.
- --trailer <jeton>[(=| :)<valeur>]
-
Spécifier une paire (<jeton>, <valeur>) qui doit être appliquée 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 configurationtrailer.*
(git-interpret-trailers[1]) peuvent être utilisées pour définir si une ligne terminale dupliquée est omise, ou où chaque ligne terminale apparaîtrait dans la série de lignes terminales, et d’autres détails. - -n
- --[no-]verify
-
Par défaut, les crochets pre-commit et commit-msg sont exécutés. Lorsque l’une des options
--no-verify
ou-n
est donnée, ils sont contournés. 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
oudefault
.- 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é. Sinonwhitespace
.
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 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). - -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.
Toutes les expressions pour la valeur booléenne
true
sont interprétées commenormal
etfalse
commeno
. 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 configurationcommit.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 unmerged unmerged: 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
et GIT_COMMITTER_DATE
supportent 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 de date 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èreT
. Les parties fractionnelles d’une seconde seront ignorées, par exemple,2005-04-07T22:13:13.019
sera considéré comme étant2005-04-07T22:13:13
.NoteDe plus, la partie date est acceptée dans les formats suivants : AAAA.MM.JJ
,MM/JJ/AAAA
etJJ.MM.AAAA
.
En plus de reconnaître tous les formats de date ci-dessus, l’option --date
essaiera également de donner un sens à d’autres formats de date plus humainement compréhensibles, 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 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
etgit 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’avoiri18n.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’encodageencoding
. 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 aveci18n.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.
Warning
|
Missing See original version for this content. |
Warning
|
Missing See original version for this content. |
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 degit commit
.
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 .