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.

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

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.

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

Créer un nouveau commit qui « répare » <commit> quand il est appliqué avec git 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>.

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.

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.

Lors d’un essai sans effet, fournir la sortie en format court. Voir git-status[1] pour plus de détails. implique --dry-run.

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

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.

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

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

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

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

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

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’é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.

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.

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 configuration trailer.* (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.

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

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

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

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.

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.

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.

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

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

Court-circuiter le crochet post-rewrite.

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.

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

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.

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

Montrer les fichiers non-suivis.

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

Supprimer le message de résumé de commit.

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.

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.

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.

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.

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.

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.

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

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.

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.