git-commit - Online nel cloud

PROGRAMMA:

NOME

git-commit - Registra le modifiche nel repository

SINOSSI

git commettere [-a | --interactive | --patch] [-s] [-v] [-u ] [--modificare]
[--dry-run] [(-c | -C | --fixup | --squash) ]
[-F | -m ] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author= ]
[--data= ] [--pulizia= ] [--[nessuno Stato]
[-i | -o] [-S[ ]] [--] [ ...]

DESCRIZIONE

Memorizza il contenuto corrente dell'indice in un nuovo commit insieme a un messaggio di registro dal
utente che descrive le modifiche.

Il contenuto da aggiungere può essere specificato in diversi modi:

1. usando git aggiungere per "aggiungere" in modo incrementale le modifiche all'indice prima di utilizzare il commettere
comando (Nota: anche i file modificati devono essere "aggiunti");

2. usando git rm per rimuovere i file dall'albero di lavoro e dall'indice, ancora prima
usando il commettere comando;

3. elencando i file come argomenti per il commettere comando, nel qual caso verrà eseguito il commit
ignorare le modifiche messe in scena nell'indice e registrare invece il contenuto corrente del
file elencati (che devono essere già noti a Git);

4. utilizzando l'interruttore -a con il commettere comando per "aggiungere" automaticamente le modifiche da tutti
file conosciuti (cioè tutti i file che sono già elencati nell'indice) e automaticamente
file "rm" nell'indice che sono stati rimossi dall'albero di lavoro, quindi eseguire
il commit effettivo;

5. utilizzando gli switch --interactive o --patch con il tasto commettere comando per deciderne uno
da uno quali file o blocchi dovrebbero far parte del commit, prima di finalizzare il
operazione. Vedere la sezione "Modalità interattiva" di git-aggiungi(1) per imparare a operare
queste modalità.

L'opzione --dry-run può essere utilizzata per ottenere un riepilogo di ciò che è incluso da uno qualsiasi dei
sopra per il prossimo commit dando lo stesso set di parametri (opzioni e percorsi).

Se fai un commit e poi trovi un errore subito dopo, puoi recuperare da
con git azzerare.

VERSIONI

-a, --tutto
Dire al comando di mettere in scena automaticamente i file che sono stati modificati ed eliminati, ma
i nuovi file di cui non hai parlato con Git non sono interessati.

-p, --patch
Utilizzare l'interfaccia di selezione patch interattiva per scegliere quali modifiche eseguire il commit. Vedere
git-aggiungi(1) per i dettagli.

-C , --reuse-message=
Prendi un oggetto commit esistente e riutilizza il messaggio di registro e l'autore
informazioni (incluso il timestamp) durante la creazione del commit.

-C , --reedit-message=
Come -C, ma con -c viene richiamato l'editor, in modo che l'utente possa modificare ulteriormente il
messaggio di commit.

--fixup=
Costruisci un messaggio di commit da usare con rebase --autosquash. Il messaggio di commit sarà
essere la riga dell'oggetto del commit specificato con il prefisso "fixup!". Vedere idiota-
rebase(1) per i dettagli.

--squash=
Costruisci un messaggio di commit da usare con rebase --autosquash. Il messaggio di commit
la riga dell'oggetto è presa dal commit specificato con il prefisso "squash!". Può essere
utilizzato con opzioni di messaggio di commit aggiuntive (-m/-c/-C/-F). Vedere git-rebase(1) per
dettagli.

--reset-autore
Se usato con le opzioni -C/-c/--amend, o quando si esegue il commit dopo un conflitto
cherry-pick, dichiara che la paternità del commit risultante ora appartiene al
committente. Questo rinnova anche il timestamp dell'autore.

--breve
Quando si esegue una prova a secco, fornire l'output nel formato breve. Vedere stato git(1) per
particolari. Implica --funzionamento a secco.

--ramo
Mostra le informazioni sulla filiale e sul monitoraggio anche in formato breve.

--porcellana
Quando si esegue una tiratura a secco, fornire l'output in un formato pronto per la porcellana. Vedere stato git(1)
per dettagli. Implica --funzionamento a secco.

--lungo
Quando si esegue una prova a secco, fornire l'output in un formato lungo. Implica --funzionamento a secco.

-z, --null
Quando si visualizza l'output di stato corto o in porcellana, terminare le voci nell'output di stato
con NUL, invece di LF. Se non viene fornito alcun formato, implica il formato di output --porcelain.

-F , --file=
Prendi il messaggio di commit dal file specificato. Utilizzo - per leggere il messaggio del
ingresso standard.

--autore=
Sostituisci l'autore del commit. Specificare un autore esplicito utilizzando lo standard AU Thor
<[email protected]> formato. Altrimenti si presume che sia un modello e viene utilizzato
per cercare un commit esistente di quell'autore (cioè rev-list --all -i
--autore= ); l'autore del commit viene quindi copiato dal primo commit trovato.

--data=
Sostituisci la data dell'autore utilizzata nel commit.

-m , --message=
Usa il dato come messaggio di commit. Se vengono fornite più opzioni -m, loro
i valori sono concatenati come paragrafi separati.

-T , --template=
Quando si modifica il messaggio di commit, avviare l'editor con i contenuti nel file specificato.
La variabile di configurazione commit.template viene spesso utilizzata per fornire questa opzione
implicitamente al comando. Questo meccanismo può essere utilizzato da progetti che vogliono guidare
partecipanti con alcuni suggerimenti su cosa scrivere nel messaggio in quale ordine. Se la
l'utente esce dall'editor senza modificare il messaggio, il commit viene interrotto. Questo non ha
effetto quando un messaggio viene fornito con altri mezzi, ad esempio con le opzioni -mo -F.

-s, --signoff
Aggiungi la riga Firma da parte del committente alla fine del messaggio di registro del commit. Il
il significato di un signoff dipende dal progetto, ma in genere certifica che committer
ha i diritti per inviare quest'opera con la stessa licenza e accetta uno sviluppatore
Certificato di origine (vedi http://developercertificate.org/ per maggiori informazioni).

-n, --no-verifica
Questa opzione ignora gli hook pre-commit e commit-msg. Guarda anche githooks(5).

--allow-vuoto
Di solito la registrazione di un commit che ha lo stesso albero esatto del suo commit padre unico è a
errore e il comando ti impedisce di eseguire tale commit. Questa opzione ignora
la sicurezza ed è principalmente per l'utilizzo da parte di script di interfaccia SCM esterni.

--allow-vuoto-messaggio
Come --allow-empty, questo comando è principalmente per l'uso da parte di script di interfaccia SCM esterni.
Ti consente di creare un commit con un messaggio di commit vuoto senza utilizzare l'impianto idraulico
comandi come git-commit-albero(1).

--cleanup=
Questa opzione determina come il messaggio di commit fornito deve essere ripulito prima
commettere. Il può essere strip, whitespace, verbatim, forbici o default.

striscia
Elimina le righe vuote iniziali e finali, gli spazi bianchi finali, i commenti e
comprimi le righe vuote consecutive.

spazio bianco
Uguale alla striscia tranne che #commentary non viene rimosso.

Verbatim
Non modificare affatto il messaggio.

forbici
Uguale agli spazi bianchi, tranne per il fatto che tutto dalla (e inclusa) la riga "#
------------------------ >8 ------------------------ " viene troncato se il messaggio
è da modificare. "#" può essere personalizzato con core.commentChar.

difetto
Uguale a strip se il messaggio deve essere modificato. Altrimenti spazi bianchi.

L'impostazione predefinita può essere modificata dal commit.cleanup variabile di configurazione (vedi idiota-
config(1)).

-e, --edit
Il messaggio preso dal file con -F, dalla riga di comando con -m e dall'oggetto commit con
-C vengono solitamente utilizzati come messaggio di registro di commit non modificato. Questa opzione ti consente di andare oltre
modificare il messaggio preso da queste fonti.

--nessuna modifica
Usa il messaggio di commit selezionato senza avviare un editor. Ad esempio, git commit
--amend --no-edit corregge un commit senza cambiarne il messaggio di commit.

--modifica
Sostituisci la punta del ramo corrente creando un nuovo commit. L'albero registrato è
preparato come al solito (incluso l'effetto delle opzioni -i e -o ed esplicito
pathpec) e il messaggio del commit originale viene utilizzato come punto di partenza,
invece di un messaggio vuoto, quando non viene specificato nessun altro messaggio dalla riga di comando
tramite opzioni come -m, -F, -c, ecc. Il nuovo commit ha gli stessi genitori e autore di
quello corrente (l'opzione --reset-author può annullarlo).

È un equivalente approssimativo per:

$ git reset --soft HEAD^
$ ... fai qualcos'altro per trovare l'albero giusto ...
$ git commit -c TESTA_ORIG

ma può essere utilizzato per modificare un commit di unione.

Dovresti comprendere le implicazioni della riscrittura della cronologia se modifichi un commit che
è già stato pubblicato. (Vedi la sezione "RECUPERO DAL REBASE A MONTE" in idiota-
rebase(1).)

--no-post-riscrittura
Bypassare l'hook post-riscrittura.

-i, --include
Prima di eseguire un commit sui contenuti organizzati fino a quel momento, metti in scena i contenuti dei percorsi
dato anche dalla riga di comando. Questo di solito non è quello che vuoi a meno che tu non lo sia
concludere una fusione conflittuale.

-o, --solo
Effettua un commit prendendo il contenuto dell'albero di lavoro aggiornato dei percorsi specificati su
la riga di comando, ignorando qualsiasi contenuto che è stato messo in scena per altri percorsi.
Questa è la modalità di funzionamento predefinita di git commettere se vengono forniti percorsi sul
riga di comando, nel qual caso questa opzione può essere omessa. Se questa opzione è specificata
insieme --modifica, quindi non è necessario specificare percorsi, che possono essere utilizzati per modificare
l'ultimo commit senza commettere modifiche che sono già state messe in scena.

-u[ ], --untracked-files[= ]
Mostra i file non tracciati.

Il parametro mode è opzionale (predefinito su contro tutti i), e viene utilizzato per specificare il trattamento
di file non tracciati; quando -u non viene utilizzato, il valore predefinito è normale, ovvero mostra non tracciato
file e directory.

Le opzioni possibili sono:

· no - Non mostrare file non tracciati

· normale - Mostra file e directory non tracciati

· contro tutti i - Mostra anche i singoli file nelle directory non tracciate.

L'impostazione predefinita può essere modificata utilizzando la configurazione status.showUntrackedFiles
variabile documentata in git-config(1).

-v, --verboso
Mostra la differenza unificata tra il commit HEAD e ciò che sarebbe commesso in fondo a
il modello del messaggio di commit per aiutare l'utente a descrivere il commit ricordando cosa
modifiche che il commit ha. Nota che questo output diff non ha le sue linee prefissate
con #. Questa differenza non farà parte del messaggio di commit.

Se specificato due volte, mostra inoltre la differenza unificata tra ciò che sarebbe commesso
e i file dell'albero di lavoro, ovvero le modifiche non pianificate ai file tracciati.

-q, --silenzioso
Sopprimi il messaggio di riepilogo del commit.

--funzionamento a secco
Non creare un commit, ma mostra un elenco di percorsi che devono essere impegnati, percorsi con
modifiche locali che non verranno salvate e percorsi non tracciati.

--stato
Includi l'output di stato git(1) nel modello del messaggio di commit quando si utilizza an
editor per preparare il messaggio di commit. L'impostazione predefinita è attivata, ma può essere utilizzata per eseguire l'override
variabile di configurazione commit.status.

--nessuno Stato
Non includere l'output di stato git(1) nel modello del messaggio di commit quando si utilizza
un editor per preparare il messaggio di commit predefinito.

-S[ ], --gpg-segno[= ]
Commit firmati GPG. L'argomento keyid è facoltativo e di default è il committer
identità; se specificato, deve essere attaccato all'opzione senza spazio.

--no-segno-gpg
Countermand commit.gpgSign variabile di configurazione che è impostata per forzare ogni singolo
impegnarsi a firmare.

--
Non interpretare altri argomenti come opzioni.

...
Quando i file vengono forniti sulla riga di comando, il comando esegue il commit del contenuto del
file denominati, senza registrare le modifiche già effettuate. Il contenuto di questi file
sono anche messe in scena per il prossimo commit in aggiunta a quelle che sono state messe in scena in precedenza.

DATA FORMATI

Le variabili di ambiente GIT_AUTHOR_DATE, GIT_COMMITTER_DATE e l'opzione --date
supportano i seguenti formati di data:

Formato interno Git
è , dove è il numero di
secondi dall'epoca di UNIX. è un offset positivo o negativo
dall'UTC. Ad esempio CET (che è 2 ore prima dell'UTC) è +0200.

RFC 2822
Il formato email standard come descritto da RFC 2822, ad esempio Thu, 07 Apr 2005
22:13:13+0200.

ISO 8601
Ora e data specificate dallo standard ISO 8601, ad esempio 2005-04-07T22:13:13. Il
il parser accetta anche uno spazio invece del carattere T.

Note:
Inoltre, la parte della data è accettata nei seguenti formati: AAAA.MM.GG,
MM/GG/AAAA e GG.MM.AAAA.

ESEMPI

Quando si registra il proprio lavoro, i contenuti dei file modificati nel proprio albero di lavoro sono
memorizzato temporaneamente in un'area di sosta chiamata "indice" con git aggiungere. Un file può essere
tornato indietro, solo nell'indice ma non nell'albero di lavoro, a quello dell'ultimo commit
con git reset HEAD -- , che di fatto ritorna git aggiungere e previene i cambiamenti
a questo file dalla partecipazione al commit successivo. Dopo aver costruito lo stato per essere
commit incrementale con questi comandi, git commit (senza alcun parametro del percorso)
viene utilizzato per registrare ciò che è stato messo in scena finora. Questa è la forma più elementare del comando.
Un esempio:

$ modifica ciao.c
$ git rm arrivederci.c
$ git add ciao.c
$gitcommit

Invece di mettere in scena i file dopo ogni singola modifica, puoi dire a git commit di notare
le modifiche ai file il cui contenuto è tracciato nel tuo albero di lavoro e fai
git add e git rm corrispondenti per te. Cioè, questo esempio fa lo stesso del
esempio precedente se non ci sono altri cambiamenti nel tuo albero di lavoro:

$ modifica ciao.c
$ rm arrivederci.c
$ git commit -a

Il comando git commit -a guarda prima il tuo albero di lavoro, nota che hai modificato
hello.c e rimosso arrivederci.c, ed esegue il necessario git add e git rm per te.

Dopo aver messo in scena le modifiche a molti file, è possibile modificare l'ordine in cui vengono registrate le modifiche,
dando i nomi di percorso a git commit. Quando vengono dati i nomi di percorso, il comando esegue un commit
che registra solo le modifiche apportate ai percorsi denominati:

$ modifica ciao.c ciao.h
$ git add ciao.c ciao.h
$ modifica Makefile
$ git commit Makefile

Questo crea un commit che registra la modifica su Makefile. I cambiamenti messi in scena per
hello.c e hello.h non sono inclusi nel commit risultante. Tuttavia, i loro cambiamenti sono
non perduti: sono ancora messi in scena e semplicemente trattenuti. Dopo la sequenza di cui sopra, se tu
fare:

$gitcommit

questo secondo commit registrerebbe le modifiche a hello.c e hello.h come previsto.

Dopo una fusione (avviata da git unire or git tirare) si ferma a causa di conflitti, in modo pulito
i percorsi uniti sono già organizzati per essere impegnati per te e i percorsi in conflitto lo sono
lasciato allo stato non fuso. Dovresti prima controllare con quali percorsi sono in conflitto git
status e dopo averli corretti manualmente nel tuo albero di lavoro, avresti messo in scena il risultato come
al solito con git aggiungere:

$ git stato | grep non fuso
non fuso: ciao.c
$ modifica ciao.c
$ git add ciao.c

Dopo aver risolto i conflitti e messo in scena il risultato, git ls-files -u smetteva di menzionare
il percorso conflittuale. Quando hai finito, esegui git commit per registrare finalmente l'unione:

$gitcommit

Come nel caso per registrare le proprie modifiche, è possibile utilizzare l'opzione -a per salvare la digitazione. Uno
la differenza è che durante una risoluzione di unione, non puoi usare git commit con i nomi di percorso per
alterare l'ordine in cui vengono salvate le modifiche, perché l'unione dovrebbe essere registrata come a
singolo impegno. In effetti, il comando si rifiuta di essere eseguito quando viene fornito un nome di percorso (ma vedi -i
opzione).

DISCUSSIONE

Sebbene non sia necessario, è una buona idea iniziare il messaggio di commit con un singolo breve
(meno di 50 caratteri) riga che riassume la modifica, seguita da una riga vuota e poi a
descrizione più approfondita. Il testo fino alla prima riga vuota in un messaggio di commit è
trattato come titolo di commit e quel titolo viene utilizzato in tutto Git. Per esempio, idiota-
formato-patch(1) trasforma un commit in e-mail e utilizza il titolo nella riga dell'oggetto e
il resto del commit nel corpo.

Git è in una certa misura indipendente dalla codifica dei caratteri.

· I contenuti degli oggetti BLOB sono sequenze di byte non interpretate. Non c'è
codifica della traduzione a livello di base.

· I nomi dei percorsi sono codificati nel modulo C di normalizzazione UTF-8. Questo vale per gli oggetti albero,
il file indice, i nomi di riferimento e i nomi di percorso negli argomenti della riga di comando,
variabili d'ambiente e file di configurazione (.git/config (vedi git-config(1)), gitignora(5)
gitattributi(5) e gitmodules(5)).

Nota che Git a livello di base tratta i nomi di percorso semplicemente come sequenze di non-NUL
byte, non ci sono conversioni di codifica del nome del percorso (tranne su Mac e Windows).
Pertanto, l'utilizzo di nomi di percorso non ASCII funzionerà principalmente anche su piattaforme e file
sistemi che utilizzano codifiche ASCII estese legacy. Tuttavia, i repository creati su
tali sistemi non funzioneranno correttamente su sistemi basati su UTF-8 (es. Linux, Mac, Windows)
e viceversa. Inoltre, molti strumenti basati su Git assumono semplicemente che i nomi dei percorsi siano
UTF-8 e non riuscirà a visualizzare correttamente altre codifiche.

· I messaggi di registro di commit sono tipicamente codificati in UTF-8, ma altre codifiche ASCII estese
sono anche supportati. Ciò include ISO-8859-x, CP125x e molti altri, ma non
Codifiche multibyte UTF-16/32, EBCDIC e CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx
ecc).

Sebbene incoraggiamo che i messaggi di log di commit siano codificati in UTF-8, sia il core che
Git Porcelain è progettato per non forzare UTF-8 sui progetti. Se tutti i partecipanti di a
particolare progetto trova più conveniente utilizzare le codifiche legacy, Git non lo vieta
esso. Tuttavia, ci sono alcune cose da tenere a mente.

1. git commettere ed git albero di commit emette un avviso se il messaggio di log di commit gli viene fornito
non sembra una stringa UTF-8 valida, a meno che tu non dica esplicitamente che il tuo progetto usa a
codifica legacy. Il modo per dirlo è avere i18n.commitencoding in .git/config
file, in questo modo:

[i18n]
codifica commit = ISO-8859-1

Commit oggetti creati con l'impostazione precedente registra il valore di i18n.commitencoding
nella sua intestazione di codifica. Questo per aiutare altre persone che li guarderanno in seguito. Mancanza di
questa intestazione implica che il messaggio del registro di commit è codificato in UTF-8.

2. git ceppo, git mostrare attraverso le sue creazioni, git colpa e gli amici guardano l'intestazione di codifica di un commit
oggetto e prova a ricodificare il messaggio di registro in UTF-8 se non diversamente specificato. Voi
può specificare la codifica di output desiderata con i18n.logoutputencoding in .git/config
file, in questo modo:

[i18n]
codifica output log = ISO-8859-1

Se non hai questa variabile di configurazione, il valore di i18n.commitencoding è
usato invece.

Nota che abbiamo deliberatamente scelto di non ricodificare il messaggio di log del commit quando un commit è
fatto per forzare UTF-8 a livello di oggetto commit, perché la ricodifica in UTF-8 non lo è
necessariamente un'operazione reversibile.

AMBIENTE E CONFIGURAZIONE VARIABILI

L'editor utilizzato per modificare il messaggio del log di commit sarà scelto da GIT_EDITOR
variabile d'ambiente, la variabile di configurazione core.editor, l'ambiente VISUAL
variabile o la variabile di ambiente EDITOR (in questo ordine). Vedere git-var(1) per i dettagli.

GANCI

Questo comando può eseguire hook commit-msg, prepare-commit-msg, pre-commit e post-commit.
See githooks(5) per maggiori informazioni.

Usa git-commit online usando i servizi onworks.net