git-commit - Online în cloud

PROGRAM:

NUME

git-commit - Înregistrează modificările în depozit

REZUMAT

merge comite [-a | --interactiv | --patch] [-s] [-v] [-u ] [--amenda]
[--dry-run] [(-c | -C | --fixup | --squash) ]
[-F | -m ] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author= ]
[--data= ] [--curățare= ] [--[fara status]
[-i | -o] [-S[ ]] [--] [ ...]

DESCRIERE

Stochează conținutul curent al indexului într-un nou commit împreună cu un mesaj de jurnal de la
utilizator care descrie modificările.

Conținutul de adăugat poate fi specificat în mai multe moduri:

1. prin folosirea merge adăuga pentru a „adăuga” în mod incremental modificări la index înainte de a utiliza comite
comanda (Notă: chiar și fișierele modificate trebuie „adăugate”);

2. prin folosirea merge rm pentru a elimina fișierele din arborele de lucru și din index, din nou înainte
folosind comite comanda;

3. prin listarea fișierelor ca argumente pentru comite comanda, caz în care commit va
ignora modificările introduse în index și, în schimb, înregistrează conținutul curent al
fișierele listate (care trebuie deja cunoscute de Git);

4. folosind comutatorul -a cu comite comandă pentru a „adăuga” automat modificările din toate
fișierele cunoscute (adică toate fișierele care sunt deja listate în index) și automat
„rm” fișiere din index care au fost eliminate din arborele de lucru și apoi executați
comiterea efectivă;

5. folosind comutatoarele --interactive sau --patch cu comite comanda pentru a decide una
de unul care fișierele sau părțile ar trebui să facă parte din comitere, înainte de finalizarea
Operațiune. Consultați secțiunea „Modul interactiv” din git-add(1) să învețe cum să opereze
aceste moduri.

Opțiunea --dry-run poate fi folosită pentru a obține un rezumat a ceea ce este inclus de oricare dintre
de mai sus pentru următoarea comitere dând același set de parametri (opțiuni și căi).

Dacă faceți un commit și apoi găsiți o greșeală imediat după aceea, vă puteți recupera
cu merge reseta.

OPŢIUNI

-a, --toate
Spuneți comenzii să pună în aplicare automat fișierele care au fost modificate și șterse, dar
fișierele noi despre care nu ați spus lui Git nu sunt afectate.

-p, --patch
Utilizați interfața interactivă de selecție a corecțiilor pentru a alege ce modificări să comite. Vedea
git-add(1) pentru detalii.

-C , --reuse-message=
Luați un obiect de comitere existent și reutilizați mesajul de jurnal și calitatea de autor
informații (inclusiv marcajul de timp) la crearea comenzii.

-c , --reedit-message=
Aprecieri -C, dar cu -c editorul este invocat, astfel încât utilizatorul să poată edita în continuare
mesaj de comitere.

--fixup=
Construiți un mesaj de confirmare pentru utilizare cu rebase --autosquash. Mesajul de confirmare va fi
să fie linia de subiect din comiterea specificată cu prefixul „fixup!”. Vedea git-
depășește(1) pentru detalii.

--dovleac=
Construiți un mesaj de confirmare pentru utilizare cu rebase --autosquash. Mesajul de confirmare
linia de subiect este preluată din comiterea specificată cu prefixul „squash!”. Poate fi
utilizat cu opțiuni suplimentare pentru mesaje de comitere (-m/-c/-C/-F). Vedea git-rebase(1) pentru
Detalii.

--resetare-autor
Când este utilizat cu opțiunile -C/-c/--amend sau când se comite după un conflict
cherry-pick, declară că autoritatea comite-ului rezultat aparține acum
comisor. Acest lucru reînnoiește și marca temporală a autorului.

--mic de statura
Când faceți o rulare uscată, dați rezultatul în format scurt. Vedea git-status(1) pentru
Detalii. Implică --run-secat.

--ramură
Afișați informațiile despre ramură și urmărire chiar și în format scurt.

--porţelan
Când faceți o rulare uscată, dați rezultatul într-un format gata pentru porțelan. Vedea git-status(1)
pentru detalii. Implică --run-secat.

--lung
Când faceți o rulare uscată, dați rezultatul într-un format lung. Implică --run-secat.

-z, --null
Când afișați ieșirea de stare scurtă sau de porțelan, terminați intrările din ieșirea de stare
cu NUL, în loc de LF. Dacă nu este dat niciun format, implică formatul de ieșire --porțelan.

-F , --file=
Luați mesajul de confirmare din fișierul dat. Utilizare - pentru a citi mesajul de la
intrare standard.

--autor=
Ignorați autorul comiterii. Specificați un autor explicit folosind standardul AU Thor
<[e-mail protejat]> format. In caz contrar se presupune a fi un model și este utilizat
pentru a căuta o comitere existentă de către autorul respectiv (adică rev-list --all -i
--autor= ); autorul comiterii este apoi copiat din prima astfel de comitere găsită.

--data=
Înlocuiți data autorului utilizată în commit.

-m , --message=
Folosiți ceea ce este dat ca mesaj de confirmare. Dacă sunt date mai multe opțiuni -m, acestea
valorile sunt concatenate ca paragrafe separate.

-t , --template=
Când editați mesajul de confirmare, porniți editorul cu conținutul din fișierul dat.
Variabila de configurare commit.template este adesea folosită pentru a oferi această opțiune
implicit la comanda. Acest mecanism poate fi folosit de proiectele care doresc să ghideze
participanții cu câteva indicii despre ce să scrie în mesaj în ce ordine. Dacă
utilizatorul iese din editor fără a edita mesajul, commit-ul este anulat. Aceasta nu are
efect atunci când un mesaj este transmis prin alte mijloace, de exemplu cu opțiunile -m sau -F.

-s, --signoff
Adăugați linia semnată de către committer la sfârșitul mesajului de jurnal de comitere. The
semnificația semnării depinde de proiect, dar de obicei certifică acel committer
are dreptul de a trimite această lucrare sub aceeași licență și este de acord cu un Dezvoltator
Certificatul de origine (vezi http://developercertificate.org/ pentru mai multe informatii).

-n, --no-verify
Această opțiune ocolește cârligele pre-commit și commit-msg. Vezi si githooks(5).

--permite-gol
De obicei, înregistrarea unui commit care are exact același arbore ca și singurul său părinte commit este a
greșeală, iar comanda vă împiedică să faceți o astfel de comitere. Această opțiune ocolește
siguranța și este destinat în primul rând scripturilor de interfață SCM străine.

--allow-empty-message
La fel ca --allow-empty, această comandă este utilizată în primul rând de scripturile de interfață SCM străine.
Vă permite să creați un commit cu un mesaj de comit gol fără a utiliza instalațiile sanitare
comenzi ca git-commit-tree(1).

--curățare=
Această opțiune determină modul în care mesajul de comitere furnizat ar trebui să fie curățat înainte
comiterea. The poate fi bandă, spații albe, verbatim, foarfece sau implicit.

strip
Eliminați liniile goale de început și de sfârșit, spații albe în urmă, comentarii și
restrânge linii goale consecutive.

spatiu alb
La fel ca strip, cu excepția faptului că #commentary nu este eliminat.

textual
Nu schimba deloc mesajul.

foarfecă
La fel ca și spațiile albe, cu excepția faptului că totul de la (și inclusiv) linia „#
------------------------ >8 ------------------------ " este trunchiat dacă mesajul
urmează a fi editat. „#” poate fi personalizat cu core.commentChar.

lipsă
La fel ca strip dacă mesajul urmează să fie editat. În caz contrar, spații albe.

Valoarea implicită poate fi modificată de comite.curățare variabila de configurare (vezi git-
config(1)).

-e, --editați
Mesajul preluat din fișierul cu -F, linia de comandă cu -m și din obiectul commit cu
-C sunt de obicei folosite ca mesaj de jurnal de comitere nemodificat. Această opțiune vă permite mai departe
editați mesajul preluat din aceste surse.

--nu-editare
Utilizați mesajul de confirmare selectat fără a lansa un editor. De exemplu, git commit
--amend --no-edit modifică un commit fără a-i schimba mesajul de commit.

--amenda
Înlocuiți vârful ramurii curente prin crearea unui nou commit. Arborele înregistrat este
pregătit ca de obicei (inclusiv efectul opțiunilor -i și -o și explicit
pathspec), iar mesajul din commit-ul original este folosit ca punct de plecare,
în loc de un mesaj gol, când nu este specificat niciun alt mesaj din linia de comandă
prin opțiuni precum -m, -F, -c etc. Noul commit are aceiași părinți și aceiași autor ca
cea actuală (opțiunea --reset-author poate contramanda acest lucru).

Este un echivalent aproximativ pentru:

$ git reset --soft HEAD^
$ ... fă altceva pentru a găsi arborele potrivit...
$ git commit -c ORIG_HEAD

dar poate fi folosit pentru a modifica o comitere de îmbinare.

Ar trebui să înțelegeți implicațiile rescrierii istoriei dacă modificați un commit care
a fost deja publicat. (Consultați secțiunea „RECUPERARE DE LA REBAZA ÎN Amonte” în git-
depășește(1).)

--no-post-rewrite
Ocoliți cârligul de post-rescriere.

-eu includ
Înainte de a face un commit din conținutul înscenizat până acum, puneți în scenă conținutul căilor
dat și pe linia de comandă. De obicei, acest lucru nu este ceea ce îți dorești decât dacă ești
încheierea unei fuziuni conflictuale.

-o, --doar
Efectuați un commit luând conținutul actualizat al arborelui de lucru al căilor specificate pe
linia de comandă, ignorând orice conținut care a fost pus în scenă pentru alte căi.
Acesta este modul implicit de operare al merge comite dacă sunt date căi pe
linie de comandă, caz în care această opțiune poate fi omisă. Dacă se specifică această opțiune
Împreună cu --amenda, atunci nu trebuie specificate căi, care pot fi folosite pentru a modifica
ultima comitere fără comiterea modificărilor care au fost deja puse în scenă.

-u[ ], --untracked-files[= ]
Afișați fișierele neurmărite.

Parametrul mod este opțional (implicit la toate), și este folosit pentru a specifica manipularea
a fișierelor neurmărite; când -u nu este folosit, implicit este normală., adică arată neurmărită
fișiere și directoare.

Opțiunile posibile sunt:

· Nu. - Nu afișați fișiere neurmărite

· normală. - Afișează fișiere și directoare neurmărite

· toate - Afișează, de asemenea, fișiere individuale în directoare neurmărite.

Valoarea implicită poate fi modificată utilizând configurația status.showUntrackedFiles
variabilă documentată în git-config(1).

-v, --verbos
Afișați diferența unificată între comiterea HEAD și ceea ce ar fi comis în partea de jos
șablonul de mesaj de comit pentru a ajuta utilizatorul să descrie commit-ul amintindu-i ce
modificările pe care le are commit-ul. Rețineți că această ieșire de diferență nu are liniile sale prefixate
cu #. Această diferență nu va face parte din mesajul de confirmare.

Dacă este specificat de două ori, afișați în plus diferența unificată între ceea ce ar fi comis
și fișierele din arborele de lucru, adică modificările neetape ale fișierelor urmărite.

-q, --liniște
Suprimați mesajul rezumat de comitere.

--funcție uscată
Nu creați un commit, ci afișați o listă de căi care urmează să fie comite, căi cu
modificări locale care vor fi lăsate neangajate și căi care nu sunt urmărite.

--stare
Includeți ieșirea din git-status(1) în șablonul de mesaj de confirmare când utilizați un
editor pentru a pregăti mesajul de confirmare. Este activat implicit, dar poate fi folosit pentru a înlocui
variabila de configurare commit.status.

--fara status
Nu includeți ieșirea de git-status(1) în șablonul de mesaj de confirmare când se utilizează
un editor pentru a pregăti mesajul implicit de confirmare.

-S[ ], --gpg-sign[= ]
Semnul GPG se comite. Argumentul keyid este opțional și este implicit la committer
identitate; dacă este specificat, trebuie să fie lipit de opțiunea fără spațiu.

--no-gpg-sign
Variabila de configurare Countermand commit.gpgSign care este setată să forțeze fiecare
se angajează să fie semnat.

--
Nu mai interpretați argumentele ca opțiuni.

...
Când fișierele sunt date pe linia de comandă, comanda comite conținutul fișierului
fișiere denumite, fără a înregistra modificările deja efectuate. Conținutul acestor fișiere
sunt, de asemenea, puse în scenă pentru următorul comit, pe lângă ceea ce au fost puse în scenă înainte.

DATA FORMATE

Variabilele de mediu GIT_AUTHOR_DATE, GIT_COMMITTER_DATE și opțiunea --date
acceptă următoarele formate de dată:

Format intern Git
Este , Unde este numărul de
secunde de la epoca UNIX. este o compensare pozitivă sau negativă
din UTC. De exemplu, CET (care este cu 2 ore înainte de UTC) este +0200.

RFC 2822
Formatul standard de e-mail, așa cum este descris de RFC 2822, de exemplu joi, 07 aprilie 2005
22:13:13 +0200.

ISO 8601
Ora și data specificate de standardul ISO 8601, de exemplu 2005-04-07T22:13:13. The
analizatorul acceptă și un spațiu în loc de caracterul T.

notițe
În plus, partea dată este acceptată în următoarele formate: AAAA.LL.ZZ,
LL/ZZ/AAAA și ZZ.LL.AAAA.

EXEMPLE

Când vă înregistrați propria lucrare, conținutul fișierelor modificate din arborele dvs. de lucru este
stocat temporar într-o zonă de pregătire numită „index” cu merge adăuga. Un dosar poate fi
a revenit înapoi, doar în index dar nu și în arborele de lucru, la cel al ultimului comit
cu git reset HEAD -- , care se revine efectiv merge adăuga și previne modificările
la acest fișier de la participarea la următoarea comitere. După construirea statului de a fi
comise incremental cu aceste comenzi, git commit (fără niciun parametru de cale)
este folosit pentru a înregistra ceea ce a fost pus în scenă până acum. Aceasta este cea mai de bază formă a comenzii.
Un exemplu:

$ editați hello.c
$ git rm la revedere.c
$ git add hello.c
$ git commit

În loc să puneți fișiere în scenă după fiecare modificare individuală, îi puteți spune lui git commit să observe
modificările la fișierele al căror conținut este urmărit în arborele dvs. de lucru și fac
git add și git rm corespunzătoare pentru tine. Adică, acest exemplu face la fel ca și
exemplu anterior dacă nu există nicio altă modificare în arborele dvs. de lucru:

$ editați hello.c
$ rm la revedere.c
$ git commit -a

Comanda git commit -a se uită mai întâi la arborele dvs. de lucru, observă că ați modificat
hello.c și a eliminat goodbye.c și efectuează git add și git rm necesare pentru tine.

După efectuarea modificărilor multor fișiere, puteți modifica ordinea în care sunt înregistrate modificările,
dând nume de căi la git commit. Când sunt date nume de căi, comanda face o comitere
care înregistrează doar modificările aduse căilor denumite:

$ editați hello.c hello.h
$ git add hello.c hello.h
$ editați Makefile
$ git commit Makefile

Aceasta face un commit care înregistrează modificarea la Makefile. Schimbările puse în scenă pentru
hello.c și hello.h nu sunt incluse în commit-ul rezultat. Cu toate acestea, modificările lor sunt
nu sunt pierdute - sunt încă puse în scenă și doar reținute. După secvența de mai sus, dacă tu
do:

$ git commit

această a doua comitere ar înregistra modificările la hello.c și hello.h așa cum era de așteptat.

După o fuziune (inițiată de merge îmbina or merge trage) se oprește din cauza conflictelor, curat
căile îmbinate sunt deja puse în scenă pentru a fi angajate pentru tine, iar căile aflate în conflict sunt
lăsat în stare necontopită. Mai întâi ar trebui să verificați cu ce căi sunt în conflict merge
Starea și după ce le-ați fixat manual în arborele dvs. de lucru, veți pune în scenă rezultatul ca
de obicei cu merge adăuga:

$ git status | grep dezintegrat
necontopite: salut.c
$ editați hello.c
$ git add hello.c

După rezolvarea conflictelor și punerea în scenă a rezultatului, git ls-files -u nu mai menționează
calea conflictuală. Când ați terminat, rulați git commit pentru a înregistra în sfârșit îmbinarea:

$ git commit

Ca și în cazul pentru a vă înregistra propriile modificări, puteți utiliza opțiunea -a pentru a salva tastarea. unu
diferența este că, în timpul unei rezoluții de îmbinare, nu puteți utiliza git commit cu căile pentru
modificați ordinea în care sunt efectuate modificări, deoarece fuziunea ar trebui înregistrată ca a
comitere unică. De fapt, comanda refuză să ruleze atunci când sunt date nume de căi (dar vezi -i
opțiune).

DISCUŢIE

Deși nu este necesar, este o idee bună să începeți mesajul de confirmare cu un singur scurt scurt
(mai puțin de 50 de caractere) linie care rezumă modificarea, urmată de o linie goală și apoi a
descriere mai amănunțită. Textul până la prima linie goală dintr-un mesaj de confirmare este
tratat ca titlu de confirmare, iar acel titlu este folosit pe tot parcursul Git. De exemplu, git-
format-patch(1) transformă un commit în e-mail și folosește titlul din linia Subiect și
restul comite în corp.

Git este într-o oarecare măsură codificarea caracterelor agnostic.

· Conținutul obiectelor blob sunt secvențe neinterpretate de octeți. Nu este
codificarea traducerii la nivel de bază.

· Numele căilor sunt codificate în forma de normalizare UTF-8 C. Acest lucru se aplică obiectelor arborescente,
fișierul index, numele referințelor, precum și numele căilor în argumentele liniei de comandă,
variabilele de mediu și fișierele de configurare (.git/config (vezi git-config(1)), gitignore(5),
gitattributes(5) și gitmodules(5)).

Rețineți că Git la nivelul de bază tratează numele căilor pur și simplu ca secvențe de non-NUL
octeți, nu există conversii de codificare a numelui căii (cu excepția Mac și Windows).
Prin urmare, utilizarea numelor de căi non-ASCII va funcționa în cea mai mare parte chiar și pe platforme și fișiere
sisteme care utilizează codificări ASCII extinse vechi. Cu toate acestea, depozitele create pe
astfel de sisteme nu vor funcționa corect pe sisteme bazate pe UTF-8 (de exemplu, Linux, Mac, Windows)
si invers. În plus, multe instrumente bazate pe Git presupun pur și simplu că sunt numele de căi
UTF-8 și nu va afișa corect alte codificări.

· Mesajele de jurnal de comitere sunt de obicei codificate în UTF-8, dar alte codificări ASCII extinse
sunt de asemenea suportate. Aceasta include ISO-8859-x, CP125x și multe altele, dar nu
Codări multi-octeți UTF-16/32, EBCDIC și CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx
etc.).

Deși încurajăm ca mesajele de jurnal de comitere să fie codificate în UTF-8, atât nucleul, cât și
Git Porcelain sunt concepute pentru a nu forța UTF-8 pe proiecte. Dacă toți participanții a
un anumit proiect consideră că este mai convenabil să folosească codificări vechi, Git nu interzice
aceasta. Cu toate acestea, există câteva lucruri de reținut.

1. merge comite și merge commit-tree emite un avertisment dacă mesajul de jurnal de comitere care i-a fost dat
nu arată ca un șir UTF-8 valid, cu excepția cazului în care spuneți în mod explicit că proiectul dvs. folosește a
codificare moștenită. Modul de a spune acest lucru este să aveți i18n.commitencoding în .git/config
fișier, așa:

[i18n]
commitencoding = ISO-8859-1

Obiectele Commit create cu setarea de mai sus înregistrează valoarea i18n.commitencoding
în antetul său de codificare. Acest lucru este pentru a ajuta alți oameni care se uită la ele mai târziu. Lipsă
acest antet implică faptul că mesajul de jurnal de comitere este codificat în UTF-8.

2. merge log, merge Arăta, merge vină iar prietenii se uită la antetul de codificare al unui commit
obiect și încercați să recodificați mesajul de jurnal în UTF-8, dacă nu se specifică altfel. Tu
poate specifica codificarea de ieșire dorită cu i18n.logoutputencoding în .git/config
fișier, așa:

[i18n]
codificare logoutput = ISO-8859-1

Dacă nu aveți această variabilă de configurare, valoarea i18n.commitencoding este
folosit în schimb.

Rețineți că am ales în mod deliberat să nu recodificăm mesajul de jurnal de comitere atunci când o comitere este
făcut pentru a forța UTF-8 la nivelul obiectului de comitere, deoarece recodificarea la UTF-8 nu este
neapărat o operaţie reversibilă.

MEDIUL AND CONFIGURARE VARIABILE

Editorul folosit pentru a edita mesajul de jurnal de comitere va fi ales din GIT_EDITOR
variabila de mediu, variabila de configurare core.editor, mediul VISUAL
sau variabila de mediu EDITOR (în această ordine). Vedea git-var(1) pentru detalii.

Cârlige

Această comandă poate rula hook-uri commit-msg, prepare-commit-msg, pre-commit și post-commit.
Vedea githooks(5) pentru mai multe informații.

Utilizați git-commit online folosind serviciile onworks.net