git-commit - En ligne dans le Cloud

PROGRAMME:

Nom

git-commit - Enregistrer les modifications dans le référentiel

SYNOPSIS

jet commettre [-a | --interactif | --patch] [-s] [-v] [-u ] [--modifier]
[--dry-run] [(-c | -C | --fixup | --squash) ]
[-F | -m ] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author= ]
[--date= ] [--nettoyage= ] [--[pas de statut]
[-je | -o] [-S[ ]] [--] [ ...]

DESCRIPTION

Stocke le contenu actuel de l'index dans un nouveau commit avec un message de journal du
utilisateur décrivant les changements.

Le contenu à ajouter peut être spécifié de plusieurs manières :

1. en utilisant jet ajouter pour "ajouter" progressivement des modifications à l'index avant d'utiliser le commettre
commande (Remarque : même les fichiers modifiés doivent être « ajoutés »);

2. en utilisant jet rm pour supprimer des fichiers de l'arbre de travail et de l'index, encore une fois avant
utilisant l' commettre commander;

3. en listant les fichiers comme arguments du commettre commande, auquel cas le commit sera
ignorer les changements mis en scène dans l'index, et à la place enregistrer le contenu actuel du
les fichiers listés (qui doivent déjà être connus de Git) ;

4. en utilisant le commutateur -a avec le commettre commande pour "ajouter" automatiquement les modifications de tous
fichiers connus (c'est-à-dire tous les fichiers déjà répertoriés dans l'index) et de
"rm" dans l'index qui ont été supprimés de l'arborescence de travail, puis effectuez
le commit réel ;

5. en utilisant les commutateurs --interactive ou --patch avec le commettre ordre de décider un
par un quels fichiers ou morceaux devraient faire partie du commit, avant de finaliser le
opération. Voir la section « Mode interactif » de git-ajouter(1) pour apprendre à opérer
ces modes.

L'option --dry-run peut être utilisée pour obtenir un résumé de ce qui est inclus par l'un des
ci-dessus pour le prochain commit en donnant le même ensemble de paramètres (options et chemins).

Si vous effectuez un commit et trouvez une erreur immédiatement après cela, vous pouvez récupérer de
avec jet réinitialiser.

OPTIONS

-a, --tous
Dites à la commande de préparer automatiquement les fichiers qui ont été modifiés et supprimés, mais
les nouveaux fichiers dont vous n'avez pas parlé à Git ne sont pas affectés.

-p, --patch
Utilisez l'interface interactive de sélection de correctifs pour choisir les modifications à valider. Voir
git-ajouter(1) pour plus de détails.

-C , --reuse-message=
Prenez un objet commit existant et réutilisez le message de journal et la paternité
informations (y compris l'horodatage) lors de la création du commit.

-c , --reedit-message=
Comme -C, mais avec -c l'éditeur est invoqué, de sorte que l'utilisateur puisse éditer davantage le
message de validation.

--fixup=
Construisez un message de validation à utiliser avec rebase --autosquash. Le message de validation sera
être la ligne d'objet du commit spécifié avec le préfixe "fixup!". Voir git-
rebasement(1) pour plus de détails.

--courge=
Construisez un message de validation à utiliser avec rebase --autosquash. Le message de validation
la ligne d'objet est extraite du commit spécifié avec le préfixe « squash ! » Peut être
utilisé avec des options de message de validation supplémentaires (-m/-c/-C/-F). Voir git-rebase(1) pour
détails.

--reset-auteur
Lorsqu'il est utilisé avec les options -C/-c/--amend, ou lors de la validation après un conflit
cherry-pick, déclare que la paternité du commit résultant appartient désormais au
commis. Cela renouvelle également l'horodatage de l'auteur.

--court
Lorsque vous effectuez un essai, donnez la sortie au format court. Voir git-statut(1) pour
des détails. Implique --dry-run.

--branche
Affichez la branche et les informations de suivi même en format court.

--porcelaine
Lorsque vous effectuez un essai à sec, donnez la sortie dans un format prêt pour la porcelaine. Voir git-statut(1)
pour les détails. Implique --dry-run.

--longue
Lorsque vous effectuez un essai, donnez la sortie au format long. Implique --dry-run.

-z, --null
Lors de l'affichage d'une sortie d'état courte ou porcelaine, terminez les entrées dans la sortie d'état
avec NUL, au lieu de LF. Si aucun format n'est donné, implique le format de sortie --porcelain.

-F , --fichier=
Prenez le message de validation du fichier donné. Utilisation - lire le message du
entrée standard.

--auteur=
Remplacez l'auteur du commit. Spécifiez un auteur explicite en utilisant le standard AU Thor
<[email protected]> formater. Autrement est supposé être un modèle et est utilisé
pour rechercher un commit existant de cet auteur (c'est-à-dire rev-list --all -i
--auteur= ); l'auteur du commit est alors copié à partir du premier commit trouvé.

--date=
Remplacez la date d'auteur utilisée dans le commit.

-m , --message=
Utiliser le donné comme message de validation. Si plusieurs options -m sont données, leur
les valeurs sont concaténées dans des paragraphes séparés.

-t , --template=
Lors de l'édition du message de validation, démarrez l'éditeur avec le contenu du fichier donné.
La variable de configuration commit.template est souvent utilisée pour donner cette option
implicitement à la commande. Ce mécanisme peut être utilisé par des projets qui souhaitent orienter
participants avec quelques conseils sur quoi écrire dans le message dans quel ordre. Si la
l'utilisateur quitte l'éditeur sans éditer le message, la validation est abandonnée. Cela n'a pas
effet lorsqu'un message est transmis par d'autres moyens, par exemple avec les options -m ou -F.

-s, --approbation
Ajoutez une ligne Sign-off-by par le committer à la fin du message de journal de commit. Les
la signification d'une approbation dépend du projet, mais elle certifie généralement que le committer
a le droit de soumettre ce travail sous la même licence et accepte un développeur
Certificat d'origine (voir http://developercertificate.org/ pour plus d'informations).

-n, --no-verify
Cette option contourne les hooks pre-commit et commit-msg. Voir également crochets (5).

--autoriser-vide
Généralement, l'enregistrement d'un commit qui a exactement la même arborescence que son seul commit parent est un
erreur, et la commande vous empêche de faire un tel commit. Cette option contourne
la sécurité et est principalement destiné à être utilisé par des scripts d'interface SCM étrangers.

--allow-vide-message
Comme --allow-empty, cette commande est principalement destinée à être utilisée par des scripts d'interface SCM étrangers.
Il vous permet de créer un commit avec un message de commit vide sans utiliser de plomberie
des commandes comme git-commit-tree (1).

--cleanup=
Cette option détermine comment le message de validation fourni doit être nettoyé avant
s'engager. Les peut être une bande, un espace, un mot à mot, des ciseaux ou par défaut.

bande
Supprimez les lignes vides de début et de fin, les espaces de fin, les commentaires et
réduire les lignes vides consécutives.

whitespace
Identique à la bande, sauf que #commentary n'est pas supprimé.

mot pour mot
Ne changez pas du tout le message.

Des ciseaux
Identique aux espaces, sauf que tout à partir de (et y compris) la ligne "#
------------------------ >8 ------------------------ " est tronqué si le message
est à éditer. "#" peut être personnalisé avec core.commentChar.

défaut
Identique à la bande si le message doit être modifié. Sinon espace.

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

-e, --edit
Le message extrait du fichier avec -F, de la ligne de commande avec -m et de l'objet commit avec
-C sont généralement utilisés comme message de journal de validation non modifié. Cette option vous permet d'approfondir
modifier le message tiré de ces sources.

--Pas de modification
Utilisez le message de validation sélectionné sans lancer d'éditeur. Par exemple, git commit
--amend --no-edit modifie un commit sans changer son message de commit.

--modifier
Remplacez la pointe de la branche actuelle en créant un nouveau commit. L'arbre enregistré est
préparé comme d'habitude (y compris l'effet des options -i et -o et explicite
pathspec) et le message du commit d'origine est utilisé comme point de départ,
au lieu d'un message vide, lorsqu'aucun autre message n'est spécifié à partir de 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'actuel (l'option --reset-author peut l'annuler).

C'est un équivalent approximatif pour :

$ git reset --soft HEAD^
$ ... faire autre chose pour trouver le bon arbre ...
$ git commit -c ORIG_HEAD

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

Vous devez comprendre les implications de la réécriture de l'historique si vous modifiez un commit qui
a déjà été publié. (Voir la section « RÉCUPÉRATION À PARTIR D'UN REBASE AMONT » dans git-
rebasement(1).)

--no-post-réécriture
Contournez le crochet de post-réécriture.

-j'inclus
Avant de faire un commit à partir du contenu mis en scène jusqu'à présent, mettez en scène le contenu des chemins
également donné sur la ligne de commande. Ce n'est généralement pas ce que vous voulez, sauf si vous êtes
conclure une fusion conflictuelle.

-o, --seulement
Faire un commit en prenant le contenu mis à jour de l'arbre de travail des chemins spécifiés sur
la ligne de commande, sans tenir compte de tout contenu qui a été mis en scène pour d'autres chemins.
C'est le mode de fonctionnement par défaut de jet commettre si des chemins sont indiqués sur le
ligne de commande, auquel cas cette option peut être omise. Si cette option est spécifiée
avec --modifier, alors aucun chemin n'a besoin d'être spécifié, qui peut être utilisé pour modifier
le dernier commit sans valider les modifications qui ont déjà été mises en scène.

-u[ ], --untracked-files[= ]
Afficher les fichiers non suivis.

Le paramètre mode est facultatif (par défaut TOUTE), et est utilisé pour spécifier le traitement
de fichiers non suivis ; lorsque -u n'est pas utilisé, la valeur par défaut est Ordinaire, c'est-à-dire montrer non suivi
fichiers et répertoires.

Les options possibles sont :

· aucune - N'afficher aucun fichier non suivi

· Ordinaire - Affiche les fichiers et répertoires non suivis

· TOUTE - Affiche également les fichiers individuels dans les répertoires non suivis.

La valeur par défaut peut être modifiée à l'aide de la configuration status.showUntrackedFiles
variable documentée dans git-config (1).

-v, --verbeux
Afficher la différence unifiée entre le commit HEAD et ce qui serait commis au bas de
le modèle de message de commit pour aider l'utilisateur à décrire le commit en lui rappelant ce que
change le commit a. Notez que cette sortie diff n'a pas ses lignes préfixées
avec #. Ce diff ne fera pas partie du message de commit.

Si spécifié deux fois, affiche en plus la différence unifiée entre ce qui serait validé
et les fichiers de l'arbre de travail, c'est-à-dire les modifications non planifiées des fichiers suivis.

-q, --calme
Supprimer le message récapitulatif de validation.

- à sec
Ne créez pas de commit, mais affichez une liste des chemins à valider, les chemins avec
les changements locaux qui ne seront pas validés et les chemins non suivis.

--statut
Inclure la sortie de git-statut(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, mais peut être utilisé pour remplacer
variable de configuration commit.status.

--pas de statut
N'incluez pas la sortie de git-statut(1) dans le modèle de message de validation lors de l'utilisation
un éditeur pour préparer le message de validation par défaut.

-S[ ], --gpg-signe[= ]
Les commits du signe GPG. L'argument keyid est facultatif et par défaut le committer
identité; si spécifié, il doit être collé à l'option sans espace.

--no-gpg-signe
Countermand commit.gpgSign variable de configuration qui est définie pour forcer chaque
s'engager à être signé.

--
N'interprétez plus d'arguments comme des options.

...
Lorsque des fichiers sont fournis sur la ligne de commande, la commande valide le contenu du
nommés, sans enregistrer les modifications déjà effectuées. Le contenu de ces fichiers
sont également mis en scène pour le prochain commit en plus de ce qui a été mis en scène auparavant.

DATES FORMATS

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 , où est le nombre de
secondes depuis l'époque UNIX. est un décalage positif ou négatif
de l'UTC. Par exemple, CET (qui a 2 heures d'avance sur UTC) est +0200.

RFC 2822
Le format d'e-mail standard tel que décrit par RFC 2822, par exemple Thu, 07 Apr 2005
22:13:13 +0200.

ISO 8601
Heure et date spécifiées par la norme ISO 8601, par exemple 2005-04-07T22:13:13. Les
l'analyseur accepte également un espace au lieu du caractère T.

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

EXEMPLES

Lors de l'enregistrement de votre propre travail, le contenu des fichiers modifiés dans votre arbre de travail est
temporairement stocké dans une zone de transit appelée « index » avec jet ajouter. Un fichier peut être
revient, uniquement dans l'index mais pas dans l'arbre de travail, à celui du dernier commit
avec git reset HEAD -- , ce qui revient effectivement jet ajouter et empêche les changements
à ce fichier de participer au prochain commit. Après avoir construit l'État à
commit de manière incrémentielle avec ces commandes, git commit (sans aucun paramètre de nom de chemin)
est utilisé pour enregistrer ce qui a été mis en scène jusqu'à présent. C'est la forme la plus basique de la commande.
Un exemple:

$ modifier bonjour.c
$ git rm au revoir.c
$ git ajouter bonjour.c
$ git commettre

Au lieu de transférer les fichiers après chaque modification individuelle, vous pouvez dire à git commit de noter
les modifications apportées aux fichiers dont le contenu est suivi dans votre arbre de travail et ne
git add et git rm correspondants pour vous. C'est-à-dire que cet exemple fait la même chose que le
exemple précédent s'il n'y a pas d'autre changement dans votre arbre de travail :

$ modifier bonjour.c
$ rm au revoir.c
$ git commettre -a

La commande git commit -a regarde d'abord votre arbre de travail, remarque que vous avez modifié
hello.c et supprimé goodbye.c, et effectue les git add et git rm nécessaires pour vous.

Après avoir mis en scène les modifications apportées à de nombreux fichiers, vous pouvez modifier l'ordre dans lequel les modifications sont enregistrées,
en donnant des chemins à git commit. Lorsque des chemins sont donnés, la commande effectue un commit
qui enregistre uniquement les modifications apportées aux chemins nommés :

$ modifier bonjour.c bonjour.h
$ git ajouter bonjour.c bonjour.h
$ modifier le Makefile
$ git commit Makefile

Cela crée un commit qui enregistre la modification dans Makefile. Les changements mis en scène pour
hello.c et hello.h ne sont pas inclus dans le commit résultant. Cependant, leurs changements sont
pas perdus - ils sont toujours mis en scène et simplement retenus. Après la séquence ci-dessus, si vous
faire:

$ git commettre

ce deuxième commit enregistrerait les modifications apportées à hello.c et hello.h comme prévu.

Après une fusion (initiée par jet fusionner or jet tirer) s'arrête à cause de conflits, proprement
les chemins fusionnés sont déjà mis en scène pour être validés pour vous, et les chemins en conflit sont
laissé à l'état non fusionné. Vous devez d'abord vérifier quels chemins sont en conflit avec jet
statuts et après les avoir corrigés manuellement dans votre arbre de travail, vous mettriez en scène le résultat comme
d'habitude avec jet ajouter:

$ git statut | grep non fusionné
non fusionné : hello.c
$ modifier bonjour.c
$ git ajouter bonjour.c

Après avoir résolu les conflits et mis en scène le résultat, git ls-files -u cesserait de mentionner
le chemin conflictuel. Lorsque vous avez terminé, exécutez git commit pour enfin enregistrer la fusion :

$ git commettre

Comme pour le cas pour enregistrer vos propres modifications, vous pouvez utiliser l'option -a pour enregistrer la saisie. Une
la différence est que lors d'une résolution de fusion, vous ne pouvez pas utiliser git commit avec des noms de chemin pour
modifier l'ordre dans lequel les modifications sont validées, car la fusion doit être enregistrée en tant que
engagement unique. En fait, la commande refuse de s'exécuter lorsqu'on lui donne des chemins (mais voir -i
option).

DISCUSSION

Bien que cela ne soit pas obligatoire, c'est une bonne idée de commencer le message de validation avec un seul court
(moins de 50 caractères) ligne résumant la modification, suivie d'une ligne vierge puis d'un
description plus complète. Le texte jusqu'à la première ligne vide dans un message de validation est
traité comme le titre du commit, et ce titre est utilisé dans Git. Par exemple, git-
patch-format(1) transforme un commit en e-mail, et il utilise le titre sur la ligne Objet et
le reste du commit dans le corps.

Git est dans une certaine mesure agnostique en matière de codage de caractères.

· Le contenu des objets blob sont des séquences d'octets non interprétées. Il n'y a pas
traduction de codage au niveau de base.

· Les noms de chemin sont codés dans le formulaire de normalisation UTF-8 C. Cela s'applique aux objets arborescents,
le fichier d'index, les noms de référence, ainsi que les noms de chemin dans les arguments de la ligne de commande,
variables d'environnement et fichiers de configuration (.git/config (voir git-config(sept)), gitignore(5),
attributs gitde Géographie (5) et avec la gitmodules(5)).

Notez que Git au niveau du noyau traite les noms de chemin simplement comme des séquences de non-NUL
octets, il n'y a pas de conversions de codage de nom de chemin (sauf sur Mac et Windows).
Par conséquent, l'utilisation de noms de chemin non ASCII fonctionnera principalement même sur les plates-formes et les fichiers
systèmes qui utilisent des codages ASCII étendus hérités. Cependant, les référentiels créés sur
de tels systèmes ne fonctionneront pas correctement sur les systèmes basés sur UTF-8 (par exemple Linux, Mac, Windows)
et vice versa. De plus, de nombreux outils basés sur Git supposent simplement que les noms de chemin sont
UTF-8 et ne parviendra pas à afficher correctement les autres encodages.

· Les messages de journal de validation sont généralement encodés en UTF-8, mais d'autres encodages ASCII étendus
sont également pris en charge. Cela inclut ISO-8859-x, CP125x et bien d'autres, mais ne sauraient
Encodages multi-octets UTF-16/32, EBCDIC et CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx
etc).

Bien que nous encourageons que les messages du journal de validation soient codés en UTF-8, le noyau et
Git Porcelain est conçu pour ne pas forcer UTF-8 sur les projets. Si tous les participants d'un
projet particulier trouve plus pratique d'utiliser des encodages hérités, Git n'interdit pas
ce. Cependant, il y a quelques choses à garder à l'esprit.

1. jet commettre ainsi que jet arbre de validation émet un avertissement si le message de journal de validation lui est donné
ne ressemble pas à une chaîne UTF-8 valide, à moins que vous ne disiez explicitement que votre projet utilise un
codage hérité. La façon de dire cela est d'avoir i18n.commitencoding dans .git/config
fichier, comme ceci :

[i18n]
codage de validation = ISO-8859-1

Les objets de validation créés avec le paramètre ci-dessus enregistrent la valeur de i18n.commitencoding
dans son en-tête d'encodage. C'est pour aider d'autres personnes qui les regarderont plus tard. Manque de
cet en-tête implique que le message de journal de validation est encodé en UTF-8.

2. jet enregistrer, jet montrer, jet blâmer et les amis regardent l'en-tête d'encodage d'un commit
objet et essayez de recoder le message de journal en UTF-8, sauf indication contraire. Tu
peut spécifier l'encodage de sortie souhaité avec i18n.logoutputencoding dans .git/config
fichier, comme ceci :

[i18n]
codage de sortie = ISO-8859-1

Si vous n'avez pas cette variable de configuration, la valeur de i18n.commitencoding est
utilisé à la place.

Notez que nous avons délibérément choisi de ne pas recoder le message du journal de commit lorsqu'un commit est
fait pour forcer UTF-8 au niveau de l'objet de validation, car le recodage en UTF-8 n'est pas
nécessairement une opération réversible.

ENVIRONNEMENT ET CONFIGURATION VARIABLES

L'éditeur utilisé pour éditer le message du journal de validation sera choisi dans le GIT_EDITOR
variable d'environnement, la variable de configuration core.editor, l'environnement VISUAL
variable ou la variable d'environnement EDITOR (dans cet ordre). Voir git-var(1) pour plus de détails.

HOOKS

Cette commande peut exécuter commit-msg, prepare-commit-msg, pre-commit et post-commit hooks.
See crochets(5) pour plus d'informations.

Utilisez git-commit en ligne en utilisant les services onworks.net