git-commit - Online in de cloud

PROGRAMMA:

NAAM

git-commit - Registreer wijzigingen in de repository

KORTE INHOUD

git plegen [-een | --interactief | --patch] [-s] [-v] [-u ] [--wijzigen]
[--droogdraaien] [(-c | -C | --fixup | --squash) ]
[-F | -M ] [--reset-auteur] [--toestaan-leeg]
[--lege-bericht toestaan] [--geen-verifiëren] [-e] [--auteur= ]
[--datum= ] [--opruimen= ] [--[geen status]
[-ik | -o] [-S[ ]] [--] [ ...]

PRODUCTBESCHRIJVING

Slaat de huidige inhoud van de index op in een nieuwe commit, samen met een logbericht van de
gebruiker die de wijzigingen beschrijft.

De toe te voegen inhoud kan op verschillende manieren worden gespecificeerd:

1. door te gebruiken git toevoegen om stapsgewijs wijzigingen aan de index toe te voegen voordat u de plegen
commando (Opmerking: zelfs gewijzigde bestanden moeten worden "toegevoegd");

2. door te gebruiken git rm om bestanden uit de werkboom en de index te verwijderen, opnieuw eerder
met de plegen opdracht;

3. door bestanden op te sommen als argumenten voor het plegen commando, in welk geval de commit dat zal doen
negeer wijzigingen in de index en registreer in plaats daarvan de huidige inhoud van de
vermelde bestanden (die al bekend moeten zijn bij Git);

4. door de schakelaar -a te gebruiken met de plegen opdracht om automatisch wijzigingen van iedereen toe te voegen
bekende bestanden (dwz alle bestanden die al in de index staan) en automatisch
"rm"-bestanden in de index die uit de werkboom zijn verwijderd, en voer vervolgens uit
de daadwerkelijke commit;

5. door gebruik te maken van de --interactive of --patch schakelaars met de plegen opdracht om er één te beslissen
door welke bestanden of hunks deel moeten uitmaken van de commit, voordat de
operatie. Zie het gedeelte ‘Interactieve modus’ van git-toevoegen(1) leren werken
deze modi.

De --dry-run optie kan worden gebruikt om een ​​samenvatting te verkrijgen van wat er in een van de
hierboven voor de volgende commit door dezelfde set parameters (opties en paden) op te geven.

Als u een commit maakt en vervolgens onmiddellijk daarna een fout ontdekt, kunt u hiervan herstellen
het met git opnieuw in te stellen.

OPTIES

-a, --allemaal
Vertel de opdracht om automatisch bestanden te stagen die zijn gewijzigd en verwijderd, maar
nieuwe bestanden waar je Git niet over hebt verteld, worden niet beïnvloed.

-p, --patch
Gebruik de interactieve patchselectie-interface om te kiezen welke wijzigingen u wilt vastleggen. Zien
git-toevoegen(1) voor details.

-C , --reuse-bericht=
Neem een ​​bestaand commit-object en hergebruik het logbericht en het auteurschap
informatie (inclusief de tijdstempel) bij het maken van de commit.

-C , --reedit-bericht=
Like -C, maar met -c de editor wordt aangeroepen, zodat de gebruiker het bestand verder kan bewerken
bericht vastleggen.

--fixup=
Maak een commit-bericht voor gebruik met rebase --autosquash. Het commit-bericht zal dat doen
moet de onderwerpregel zijn van de opgegeven commit met het voorvoegsel "fixup!". Zien git-
opnieuw baseren(1) voor details.

--squash=
Maak een commit-bericht voor gebruik met rebase --autosquash. Het commit-bericht
onderwerpregel is afkomstig uit de opgegeven commit met het voorvoegsel "squash!". Kan zijn
gebruikt met extra commit-berichtopties (-m/-c/-C/-F). Zien git-rebase(1) voor
details.

--reset-auteur
Bij gebruik met -C/-c/--amend opties, of bij het committen na een conflict
cherry-pick, verklaar dat het auteurschap van de resulterende commit nu toebehoort aan de
dader. Hiermee wordt ook de tijdstempel van de auteur vernieuwd.

--kort
Wanneer u een proefbewerking uitvoert, geeft u de uitvoer in het korte formaat op. Zien git-status(1) voor
details. Impliceert: drooglopen.

--tak
Toon de filiaal- en trackinginformatie, zelfs in kort formaat.

--porselein
Geef bij een dry-run de uitvoer op in een porseleinklaar formaat. Zien git-status(1)
voor details. Impliceert: drooglopen.

--lang
Wanneer u een proefbewerking uitvoert, geeft u de uitvoer in een lang formaat. Impliceert: drooglopen.

-z, --nul
Wanneer u een korte of porseleinen statusuitvoer weergeeft, beëindig dan de vermeldingen in de statusuitvoer
met NUL, in plaats van LF. Als er geen formaat wordt opgegeven, impliceert dit het uitvoerformaat --porcelain.

-F , --bestand=
Neem het commit-bericht uit het opgegeven bestand. Gebruik - om het bericht van de te lezen
standaard invoer.

--auteur=
Overschrijf de auteur van de commit. Geef een expliciete auteur op met behulp van de standaard AU Thor
<[e-mail beveiligd]> formaat. Anders wordt verondersteld een patroon te zijn en wordt gebruikt
om naar een bestaande commit van die auteur te zoeken (dat wil zeggen rev-list --all -i
--auteur= ); de auteur van de commit wordt dan gekopieerd van de eerste gevonden commit.

--datum=
Overschrijf de auteursdatum die in de commit wordt gebruikt.

-M , --bericht=
Gebruik het gegeven als het commit-bericht. Als er meerdere -m opties worden gegeven, worden hun
waarden worden aaneengeschakeld als afzonderlijke alinea's.

-T , --sjabloon=
Wanneer u het commit-bericht bewerkt, start u de editor met de inhoud van het opgegeven bestand.
De configuratievariabele commit.template wordt vaak gebruikt om deze optie te geven
impliciet aan de opdracht. Dit mechanisme kan gebruikt worden door projecten die willen begeleiden
deelnemers met enkele tips over wat ze in welke volgorde in het bericht moeten schrijven. Als de
Als de gebruiker de editor verlaat zonder het bericht te bewerken, wordt de commit afgebroken. Dit heeft nr
effect wanneer een bericht op een andere manier wordt gegeven, bijvoorbeeld met de opties -m of -F.

-s, --aftekening
Voeg de regel Afgetekend door de committer toe aan het einde van het commit-logboekbericht. De
De betekenis van een signoff hangt af van het project, maar certificeert doorgaans die committer
heeft de rechten om dit werk onder dezelfde licentie in te dienen en gaat akkoord met een ontwikkelaar
Certificaat van oorsprong (zie http://developercertificate.org/ voor meer informatie).

-n, --no-verifieer
Deze optie omzeilt de pre-commit en commit-msg hooks. Zie ook githaken(5).

--toestaan-leeg
Normaal gesproken is het opnemen van een commit die exact dezelfde boom heeft als de enige ouder-commit a
fout, en het commando verhindert dat je een dergelijke commit maakt. Deze optie omzeilt
de veiligheid, en is voornamelijk bedoeld voor gebruik door buitenlandse SCM-interfacescripts.

--allow-leeg-bericht
Net als --allow-empty is dit commando voornamelijk bedoeld voor gebruik door buitenlandse SCM-interfacescripts.
Hiermee kun je een commit maken met een leeg commit-bericht zonder gebruik te maken van loodgieterswerk
commando's zoals git-commit-boom(1).

--opruimen=
Deze optie bepaalt hoe het opgegeven commit-bericht eerder moet worden opgeschoond
plegen. De kan strip, witruimte, woordelijk, schaar of standaard zijn.

strip
Strip voor- en achterliggende lege regels, achterliggende witruimte, commentaar en
opeenvolgende lege regels samenvouwen.

witte ruimte
Hetzelfde als strip, behalve dat #commentaar niet wordt verwijderd.

woordelijk
Verander het bericht helemaal niet.

schaar
Hetzelfde als witruimte, behalve dat alles vanaf (en inclusief) de regel "#
----------------------- >8 ----------------------- " wordt afgekapt als het bericht
moet worden bewerkt. "#" kan worden aangepast met core.commentChar.

verzuim
Hetzelfde als strip als het bericht moet worden bewerkt. Anders witruimte.

De standaardwaarde kan worden gewijzigd door de commit.cleanup configuratievariabele (zie git-
config(1)).

-e, --edit
Het bericht uit het bestand met -F, de opdrachtregel met -m en uit het commit-object met
-C worden meestal ongewijzigd gebruikt als het commit-logboekbericht. Met deze optie kunt u verder
bewerk het bericht uit deze bronnen.

--wijzigen niet toegestaan
Gebruik het geselecteerde commit-bericht zonder een editor te starten. Bijvoorbeeld git commit
--amend --no-edit wijzigt een commit zonder het commit-bericht te wijzigen.

--wijzigen
Vervang de tip van de huidige vertakking door een nieuwe commit te maken. De geregistreerde boom is
zoals gebruikelijk voorbereid (inclusief het effect van de -i en -o opties en expliciet
pathspec), en het bericht van de originele commit wordt gebruikt als uitgangspunt,
in plaats van een leeg bericht, wanneer er geen ander bericht is opgegeven vanaf de opdrachtregel
via opties zoals -m, -F, -c, etc. De nieuwe commit heeft dezelfde ouders en auteur als
de huidige (de optie --reset-author kan dit ongedaan maken).

Het is een ruw equivalent voor:

$ git reset --soft HEAD^
$ ...doe iets anders om tot de juiste boom te komen...
$ git vastleggen -c ORIG_HEAD

maar kan worden gebruikt om een ​​merge commit te wijzigen.

Je moet de implicaties begrijpen van het herschrijven van de geschiedenis als je een commit wijzigt
is al gepubliceerd. (Zie het gedeelte "HERSTELLEN VAN BOVENSTE REBASE" in git-
opnieuw baseren(1).)

--geen post-herschrijven
Omzeil de post-rewrite hook.

-ik, --opnemen
Voordat u een commit maakt van de geënsceneerde inhoud tot nu toe, staget u de inhoud van paden
ook op de opdrachtregel gegeven. Dit is meestal niet wat je wilt, tenzij je dat wel bent
het sluiten van een conflicterende fusie.

-o, --alleen
Maak een commit door de bijgewerkte werkboominhoud te nemen van de paden die zijn opgegeven op
de opdrachtregel, waarbij de inhoud die voor andere paden is geënsceneerd, wordt genegeerd.
Dit is de standaard werkingsmodus van git plegen als er paden worden gegeven op de
opdrachtregel, in welk geval deze optie kan worden weggelaten. Als deze optie is opgegeven
met --wijzigen, dan hoeven er geen paden te worden opgegeven die kunnen worden gebruikt om te wijzigen
de laatste commit zonder wijzigingen vast te leggen die al zijn gefaseerd.

-u[ ], --untracked-bestanden[= ]
Toon niet-bijgehouden bestanden.

De modusparameter is optioneel (standaard ingesteld op allen), en wordt gebruikt om de afhandeling te specificeren
van niet-bijgehouden bestanden; als -u niet wordt gebruikt, is dit de standaardwaarde een, dwz niet-bijgehouden tonen
bestanden en mappen.

De mogelijke opties zijn:

· geen - Toon geen niet-bijgehouden bestanden

· een - Toont niet-bijgehouden bestanden en mappen

· allen - Toont ook individuele bestanden in niet-bijgehouden mappen.

De standaard kan worden gewijzigd met behulp van de status.showUntrackedFiles-configuratie
variabele gedocumenteerd in git-config(1).

-v, --uitgebreid
Toon uniforme verschillen tussen de HEAD-commit en wat er onderaan zou worden vastgelegd
de commit-berichtsjabloon om de gebruiker te helpen de commit te beschrijven door eraan te herinneren wat
wijzigingen die de commit heeft. Merk op dat deze diff-uitvoer de regels niet vooraf heeft
Met #. Deze diff zal geen deel uitmaken van het commit-bericht.

Indien twee keer gespecificeerd, toon dan bovendien het uniforme verschil tussen wat vastgelegd zou worden
en de werkboombestanden, dwz de niet-gefaseerde wijzigingen in bijgehouden bestanden.

-q, --stil
Onderdruk het commit-samenvattingsbericht.

--oefening
Maak geen commit aan, maar toon een lijst met paden die moeten worden vastgelegd, paden waarmee
lokale wijzigingen die niet worden vastgelegd en paden die niet worden bijgehouden.

--toestand
Voeg de uitvoer van toe git-status(1) in de commit-berichtsjabloon bij gebruik van een
editor om het commit-bericht voor te bereiden. Standaard ingesteld op aan, maar kan worden gebruikt om te overschrijven
configuratievariabele commit.status.

--geen status
Neem niet de uitvoer van op git-status(1) in de commit-berichtsjabloon bij gebruik
een editor om het standaard commit-bericht voor te bereiden.

-S[ ], --gpg-teken[= ]
GPG-teken legt vast. Het keyid-argument is optioneel en is standaard ingesteld op de committer
identiteit; indien opgegeven, moet het zonder spatie bij de optie worden geplakt.

--geen-gpg-teken
Countermand commit.gpgSign configuratievariabele die is ingesteld om alles af te dwingen
toezegging om te worden ondertekend.

--
Interpreteer geen argumenten meer als opties.

...
Wanneer bestanden op de opdrachtregel worden opgegeven, wordt de inhoud van het
benoemde bestanden, zonder de reeds doorgevoerde wijzigingen vast te leggen. De inhoud van deze bestanden
worden ook geënsceneerd voor de volgende commit, bovenop wat eerder is geënsceneerd.

DATUM FORMATS

De omgevingsvariabelen GIT_AUTHOR_DATE, GIT_COMMITTER_DATE en de optie --date
ondersteunen de volgende datumformaten:

Git intern formaat
Het is , waar is het aantal
seconden sinds het UNIX-tijdperk. is een positieve of negatieve offset
van UTC. Bijvoorbeeld CET (wat 2 uur later is dan UTC) is +0200.

RFC 2822
Het standaard e-mailformaat zoals beschreven door RFC 2822, bijvoorbeeld do 07 apr 2005
22:13:13 +0200.

ISO 8601
Tijd en datum gespecificeerd door de ISO 8601-norm, bijvoorbeeld 2005-04-07T22:13:13. De
parser accepteert ook een spatie in plaats van het T-teken.

Note
Bovendien wordt het datumgedeelte geaccepteerd in de volgende formaten: JJJJ.MM.DD,
MM/DD/JJJJ en DD.MM.JJJJ.

Voorbeelden

Wanneer u uw eigen werk opneemt, wordt de inhoud van gewijzigde bestanden in uw werkboom weergegeven
tijdelijk opgeslagen in een verzamelgebied genaamd de "index" met git toevoegen. Een bestand kan zijn
teruggekeerd, alleen in de index maar niet in de werkboom, naar die van de laatste commit
met git-reset HEAD -- , die effectief terugkeert git toevoegen en verhindert de veranderingen
om dit bestand te verwijderen van deelname aan de volgende commit. Na het opbouwen van de toekomstige staat
stapsgewijs gecommit met deze commando's, git commit (zonder enige padnaamparameter)
wordt gebruikt om vast te leggen wat er tot nu toe is opgevoerd. Dit is de meest basale vorm van het commando.
Een voorbeeld:

$ bewerk hallo.c
$ git rm tot ziens.c
$ git voeg hallo.c toe
$ git vastleggen

In plaats van bestanden na elke individuele wijziging te stagen, kun je git commit vertellen dat hij dit moet opmerken
de wijzigingen in de bestanden waarvan de inhoud wordt bijgehouden in uw werkboom en doen
overeenkomstige git add en git rm voor jou. Dat wil zeggen, dit voorbeeld doet hetzelfde als de
eerder voorbeeld als er geen andere verandering in uw werkboom is:

$ bewerk hallo.c
$ rm tot ziens.c
$ git vastleggen -a

Het commando git commit -a kijkt eerst naar je werkboom en merkt dat je wijzigingen hebt aangebracht
hello.c en afscheid.c verwijderd, en voert de noodzakelijke git add en git rm voor je uit.

Nadat u wijzigingen in veel bestanden hebt aangebracht, kunt u de volgorde wijzigen waarin de wijzigingen worden vastgelegd.
door padnamen op te geven aan git commit. Wanneer padnamen worden opgegeven, voert de opdracht een commit uit
dat alleen de wijzigingen registreert die zijn aangebracht in de benoemde paden:

$ bewerk hallo.c hallo.h
$ git voeg hallo.c hallo.h toe
$ bewerk Makefile
$ git commit Makefile

Dit maakt een commit die de wijziging in Makefile registreert. De veranderingen die voor
hello.c en hello.h zijn niet opgenomen in de resulterende commit. Hun veranderingen zijn dat echter wel
niet verloren – ze worden nog steeds geënsceneerd en slechts tegengehouden. Na de bovenstaande reeks, als je
do:

$ git vastleggen

deze tweede commit zou zoals verwacht de wijzigingen in hello.c en hello.h vastleggen.

Na een fusie (geïnitieerd door git samensmelten or git trek) stopt vanwege conflicten, netjes
samengevoegde paden zijn al geënsceneerd om voor u te worden vastgelegd, en paden die conflicteren zijn dat ook
in ongefuseerde staat achtergelaten. U moet eerst controleren met welke paden conflicterend is git
toestand en nadat je ze handmatig in je werkboom hebt opgelost, zou je het resultaat in scène zetten als
gebruikelijk bij git toevoegen:

$ git-status | grep niet samengevoegd
niet samengevoegd: hallo.c
$ bewerk hallo.c
$ git voeg hallo.c toe

Na het oplossen van conflicten en het klaarzetten van het resultaat, stopte git ls-files -u met vermelden
het conflicterende pad. Als je klaar bent, voer je git commit uit om eindelijk de merge vast te leggen:

$ git vastleggen

Net als bij het vastleggen van uw eigen wijzigingen, kunt u de optie -a gebruiken om het typen op te slaan. Een
Het verschil is dat je tijdens een merge-resolutie git commit niet kunt gebruiken met padnamen naar
wijzig de volgorde waarin de wijzigingen worden vastgelegd, omdat de samenvoeging moet worden geregistreerd als a
enkele toezegging. In feite weigert het commando uit te voeren wanneer het padnamen krijgt (maar zie -i
keuze).

DISCUSSIE

Hoewel dit niet vereist is, is het een goed idee om het commit-bericht te beginnen met een enkele short
(minder dan 50 tekens) regel die de wijziging samenvat, gevolgd door een lege regel en vervolgens a
uitgebreidere beschrijving. De tekst tot aan de eerste lege regel in een commit-bericht is
behandeld als de commit-titel, en die titel wordt overal in Git gebruikt. Bijvoorbeeld, git-
formaat-patch(1) verandert een commit in een e-mail en gebruikt de titel op de onderwerpregel en
de rest van de commit in het lichaam.

Git is tot op zekere hoogte karaktercodering agnostisch.

· De inhoud van de blobobjecten bestaat uit niet-geïnterpreteerde reeksen bytes. Er is geen
het coderen van vertalingen op het kernniveau.

· Padnamen zijn gecodeerd in UTF-8-normalisatievorm C. Dit geldt voor boomobjecten,
het indexbestand, ref-namen, evenals padnamen in opdrachtregelargumenten,
omgevingsvariabelen en configuratiebestanden (.git/config (zie git-config(1)), negeren(5)
gitattributen(5) en gitmodules(5)).

Merk op dat Git op het kernniveau padnamen eenvoudigweg behandelt als reeksen van niet-NUL
bytes, zijn er geen padnaamcoderingsconversies (behalve op Mac en Windows).
Daarom zal het gebruik van niet-ASCII-padnamen meestal zelfs op platforms en bestanden werken
systemen die oudere uitgebreide ASCII-coderingen gebruiken. Repository's die zijn gemaakt op
dergelijke systemen zullen niet goed werken op UTF-8-gebaseerde systemen (bijv. Linux, Mac, Windows)
en vice versa. Bovendien gaan veel op Git gebaseerde tools er eenvoudigweg van uit dat padnamen
UTF-8 en zal andere coderingen niet correct weergeven.

· Commit-logboekberichten worden doorgaans gecodeerd in UTF-8, maar ook in andere uitgebreide ASCII-coderingen
worden ook ondersteund. Dit omvat ISO-8859-x, CP125x en vele andere, maar niet
UTF-16/32, EBCDIC en CJK multi-byte-coderingen (GBK, Shift-JIS, Big5, EUC-x, CP9xx
enzovoort).

Hoewel we aanmoedigen dat de commit-logberichten worden gecodeerd in UTF-8, zijn zowel de kern- als de
Git Porcelain is ontworpen om UTF-8 niet op projecten te forceren. Als alle deelnemers van a
Een bepaald project vindt het handiger om oudere coderingen te gebruiken, maar Git verbiedt dit niet
Het. Er zijn echter een paar dingen waarmee u rekening moet houden.

1. git plegen en git commit-boom geeft een waarschuwing af als het commit-logboekbericht eraan wordt gegeven
ziet er niet uit als een geldige UTF-8-tekenreeks, tenzij u expliciet zegt dat uw project een
verouderde codering. De manier om dit te zeggen is door i18n.commitencoding in .git/config te hebben
bestand, zoals dit:

[i18n]
commitencodering = ISO-8859-1

Commit-objecten die met de bovenstaande instelling zijn gemaakt, registreren de waarde van i18n.commitencoding
in de coderingsheader. Dit is om andere mensen te helpen die er later naar kijken. Gebrek aan
deze header impliceert dat het commit-logboekbericht is gecodeerd in UTF-8.

2. git inloggen, git tonen, git schuld en vrienden kijken naar de coderingsheader van een commit
object en probeer het logbericht opnieuw te coderen in UTF-8, tenzij anders aangegeven. Jij
kan de gewenste uitvoercodering specificeren met i18n.logoutputencoding in .git/config
bestand, zoals dit:

[i18n]
logo-uitvoercodering = ISO-8859-1

Als u deze configuratievariabele niet heeft, is de waarde van i18n.commitencoding
in plaats daarvan gebruikt.

Merk op dat we er bewust voor hebben gekozen om het commit-logboekbericht niet opnieuw te coderen wanneer er een commit plaatsvindt
gemaakt om UTF-8 op commit-objectniveau te forceren, omdat hercodering naar UTF-8 niet mogelijk is
noodzakelijkerwijs een omkeerbare operatie.

MILIEU EN CONFIGURATIE VARIABELEN

De editor die gebruikt wordt om het commit log bericht te bewerken zal gekozen worden uit de GIT_EDITOR
omgevingsvariabele, de core.editor configuratievariabele, de VISUAL-omgeving
variabele, of de omgevingsvariabele EDITOR (in die volgorde). Zien git-var(1) voor details.

HOOKS

Dit commando kan commit-msg, prepare-commit-msg, pre-commit en post-commit hooks uitvoeren.
Bekijk githaken(5) voor meer informatie.

Gebruik git-commit online met behulp van onworks.net-services