Svenska ▾ Topics ▾ Latest version ▾ git-commit last updated in 2.53.0

NAMN

git-commit - Registrera ändringar i kodförrådet

SYNOPSIS

git commit [-a | --interactive | --patch] [-s] [-v] [-u[<läge>]] [--amend]
           [--dry-run] <incheckning>_ | --fixup [(amend|reword):"><incheckning>]
           [-F <fil> | -m <medd>] [--reset-author] [--allow-empty]
           [--allow-empty-message] [--no-verify] [-e] [--author=<författare>]
           [--date=<datum>] [--cleanup=<läge>] [--[no-]status]
           [-i | -o] [--pathspec-from-file=<fil> [--pathspec-file-nul]]
           [(--trailer <symbol>[(=|:)<värde>])…​] [-S[<nyckel-id>]]
           [--] [<sökväg>…​]

BESKRIVNING

Skapa en ny incheckning som innehåller det aktuella innehållet i indexet och det givna loggmeddelandet som beskriver ändringarna. Den nya incheckningen är ett direkt barn till HEAD, vanligtvis toppen av den aktuella grenen, och grenen uppdateras för att peka på den (såvida ingen gren är associerad med arbetsträd, i vilket fall HEAD "kopplas från" enligt beskrivningen i git-checkout[1]).

Innehållet som ska checkas in kan anges på flera sätt:

  1. genom att använda git-add[1] för att stegvis "lägga till" ändringar i indexet innan man använder commit-kommandot (Obs: även modifierade filer måste "läggas till");

  2. genom att använda git-rm[1] för att ta bort filer från arbetsträdet och indexet, innan commit-kommandot används;

  3. genom att lista filer som argument till commit-kommandot (utan --interactive eller --patch), i vilket fall incheckningen ignorerar ändringar som köats i indexet och i stället registrerar det aktuella innehållet i de listade filerna (som Git redan måste känna till);

  4. genom att använda -a med commit-kommandot för att automatiskt "lägga till" ändringar från alla kända filer (d.v.s. filer som redan finns i indexet) och automatiskt "rm" filer i indexet som tagits bort från arbetsträdet, och därefter utföra själva incheckningen;

  5. genom att använda växlarna --interactive eller --patch med kommandot commit för att en efter en bestämma vilka filer eller stycken som ska ingå i incheckningen utöver innehållet i indexet, innan operationen slutförs. Se avsnittet “Interaktivt läge” i git-add[1] för att lära dig hur man använder dessa lägen.

Alternativet --dry-run kan användas för att få en sammanfattning av vad som ingår i något av ovanstående för nästa incheckning genom att ange samma uppsättning parametrar (alternativ och sökvägar).

Om du gör en incheckning och direkt därefter upptäcker ett misstag kan du återhämta dig med git reset.

ALTERNATIV

-a
--all

Köar automatiskt filer som har ändrats eller tagits bort, men nya filer som du inte har talat om för Git påverkas inte.

-p
--patch

Använd det interaktiva gränssnittet för patchval för att välja vilka ändringar som ska checkas in. Se git-add[1] för detaljer.

-U<n>
--unified=<n>

Generate diffs with <n> lines of context. Defaults to diff.context or 3 if the config option is unset.

--inter-hunk-context=<n>

Visar sammanhanget mellan olika stycken, upp till det angivna <antal> rader, och sammanfogar därmed stycken som ligger nära varandra. Standardvärdet är diff.interHunkContext eller 0 om konfigurationsalternativet inte är inställt.

-C <incheckning>
--reuse-message=<incheckning>

Ta ett befintligt <incheckning>-objekt och återanvänd loggmeddelandet och författarinformationen (inklusive tidsstämpeln) när du skapar incheckningen.

-c <incheckning>
--reedit-message=<incheckning>

Som -C, men med -c startas redigeraren så att användaren kan redigera incheckningsmeddelandet vidare.

--fixup=[(amend|reword):]<incheckning>

Skapa en ny incheckning som "fixar upp" <incheckning> när den tillämpas med git rebase --autosquash. Vanlig --fixup=<incheckning> skapar en "fixup!"-incheckning som ändrar innehållet i <incheckningen> men lämnar dess loggmeddelande orört. --fixup=amend:<incheckning> är liknande men skapar en "amend!"-incheckning som också ersätter loggmeddelandet för <incheckning> med loggmeddelandet från "amend!"-incheckningen. --fixup=reword:<incheckning> skapar en "amend!"-incheckning som ersätter loggmeddelandet för <incheckning> med sitt eget loggmeddelande men gör inga ändringar i innehållet i <incheckning>.

Den incheckning som skapas av --fixup=<incheckning> har en titel som består av "fixup!" följt av titeln <incheckning>, och känns igen särskilt av git rebase --autosquash. Alternativet -m kan användas för att komplettera loggmeddelandet för den skapade incheckningen, men den ytterligare kommentaren försvinner när "fixup!"-incheckningen kläms in i <incheckning> av git rebase --autosquash.

Den incheckning som skapas av --fixup=amend:<incheckning> liknar den ovan, men dess titel har i stället prefixet "amend!". Loggmeddelandet för <incheckning> kopieras till loggmeddelandet för "amend!"-incheckningen och öppnas i en redigerare så att det kan förfinas. När git rebase --autosquash slår ihop "amend!"-incheckningen med <incheckning> ersätts loggmeddelandet för <incheckning> av det förfinade loggmeddelandet från "amend!"-incheckningen. Det är ett fel om "amend!"-incheckningens loggmeddelande är tomt, om inte --allow-empty-message anges.

--fixup=reword:<incheckning> är en förkortning för --fixup=amend:<incheckning> --only. Den skapar en "amend!"-incheckning med endast ett loggmeddelande (ignorerar eventuella ändringar som köats i indexet). När den komprimeras av git rebase --autosquash ersätter den loggmeddelandet för <incheckning> utan att göra några andra ändringar.

Varken "fixup!" eller "amend!" bekräftar ändring av författarskap för <incheckning> när det tillämpas av git rebase --autosquash. Se git-rebase[1] för detaljer.

--squash=<incheckning>

Konstruera ett incheckningsmeddelande för användning med git rebase --autosquash. Rubriken för incheckningsmeddelandet hämtas från den angivna incheckningen med prefixet "squash! ". Kan användas med ytterligare alternativ för incheckningsmeddelande (-m/-c/-C/-F). Se git-rebase[1] för detaljer.

--reset-author

När det används med -C/-c/--amend-flaggor, eller vid incheckning efter ett motstridigt urval av attribut, deklareras att författarskapet till den resulterande incheckningen nu tillhör incheckaren. Detta förnyar också författartidsstämpeln.

--short

När du gör en testkörning, ange utdata i short-format. Se git-status[1] för detaljer. Implicerar --dry-run.

--branch

Visa gren- och spårningsinformation även i kortformat. Se git-status[1] för mer information.

--porcelain

När du gör en torrkörning, ge utdata i ett porcelain-anpassat format. Se git-status[1] för detaljer. Implicerar --dry-run.

--long

När du gör en testkörning, ange utdata i långt format. Detta är standardutdata för git-status[1]. Implicerar --dry-run.

-z
--null

När short- eller porcelain-utdata från git-status[1] visas, skriv ut filnamnet ordagrant och avsluta posterna med NUL, i stället för LF. Om inget format anges innebär detta utdataformatet --porcelain. Utan -z-alternativet citeras filnamn med "ovanliga" tecken enligt beskrivningen för konfigurationsvariabeln core.quotePath (se git-config[1]).

-F <fil>
--file=<fil>

Hämta incheckningsmeddelandet från <fil>. Använd - för att läsa meddelandet från standardindata.

--author=<författare>

Åsidosätt incheckningsförfattaren. Ange en explicit författare med standardformatet A U Thor <författare@example.com>. Annars antas <författare> vara ett mönster och används för att söka efter en befintlig incheckning av den författaren (d.v.s. git rev-list --all -i --author=<författare>); incheckningsförfattaren kopieras sedan från den första hittade incheckningen.

--date=<datum>

Åsidosätt författardatumet som användes i incheckningen.

-m <medd>
--message=<medd>

Använd <medd> som incheckningsmeddelande. Om flera -m-alternativ anges, sammanfogas deras värden som separata stycken.

Alternativet -m utesluter -c, -C och -F.

-t <fil>
--template=<fil>

När du redigerar incheckningsmeddelandet, starta redigeraren med innehållet i <fil>. Konfigurationsvariabeln commit.template används ofta för att ge denna möjlighet implicit till kommandot. Denna mekanism kan användas av projekt som vill vägleda deltagarna med några tips om vad de ska skriva i meddelandet och i vilken ordning. Om användaren avslutar redigeraren utan att redigera meddelandet avbryts incheckningen. Detta har ingen effekt när ett meddelande ges på annat sätt, t.ex. med alternativen -m eller -F.

-s
--signoff
--no-signoff

Lägg till en `Signed-off-by`släprad av incheckaren i slutet av inchecknings-loggmeddelandet. Betydelsen av en signering beror på det projekt du checka-in till. Det kan till exempel intyga att incheckaren har rätt att skicka in arbetet under projektets licens eller godkänner någon bidragsgivares representation, till exempel ett Developer Certificate of Origin. (Se https://un5j2j18xhuv3q2cxb95nbb49yug.julianrbryant.com för det som används av Linuxkärnan och Git-projekten.) Konsultera dokumentationen eller ledningen för projektet du bidrar till för att förstå hur signeringarna används i det projektet.

Alternativet --no-signoff kan användas för att upphäva ett tidigare --signoff-alternativ på kommandoraden.

Git har inte (och kommer inte ha) en konfigurationsvariabel för att aktivera kommandoradsalternativet --signoff som standard; se commit.signoff-posten i gitfaq[7] för mer information.

--trailer <token>[(=|:)<värde>]

Ange ett (<token>, <värde>)-par som ska användas som en slutrad. (t.ex. git commit --trailer "Signed-off-by:C O Mitter \ <committer@example.com>" --trailer "Helped-by:C O Mitter \ <committer@example.com>" kommer att lägga till slutraden Signed-off-by och slutraden Helped-by i incheckningsmeddelandet.) Konfigurationsvariablerna trailer.* (git-interpret-trailers[1]) kan användas för att definiera om en duplicerad trailer utelämnas, var i slutradsserien varje trailer ska visas och andra detaljer.

-n
--verify
--no-verify

Hoppa över krokarna pre-commit och commit-msg. Se även githooks[5].

--allow-empty

Vanligtvis är det ett misstag att registrera en incheckning som har exakt samma träd som dess enda överordnade incheckning, och kommandot hindrar dig från att göra en sådan incheckning. Det här alternativet kringgår säkerheten och används främst av främmande SCM-gränssnittsskript.

--allow-empty-message

Skapa en commit med ett tomt incheckningsmeddelande utan att använda lågnivåkommandon som git-commit-tree[1]. Precis som --allow-empty är detta kommando främst avsett för användning av främmande SCM-gränssnittsskript.

--cleanup=<läge>

Bestäm hur det angivna incheckningsmeddelandet ska rensas upp innan det checkas in. <mode> kan vara strip, whitespace, verbatim, scissors eller default.

strip

Ta bort inledande och efterföljande tomma rader, efterföljande blanksteg, kommentarer och dölj på varandra följande tomma rader.

whitespace

Samma som strip förutom att #kommentarer inte tas bort.

verbatim

Ändra inte meddelandet alls.

scissors

Samma som blanktecken förutom att allt från (och inklusive) raden nedanför avkortas om meddelandet ska redigeras. "#" kan anpassas med core.commentChar.

# ------------------------ >8 ------------------------
default

Samma som strip om meddelandet ska redigeras. Annars whitespace.

Standardvärdet kan ändras med konfigurationsvariabeln commit.cleanup (se git-config[1]).

-e
--edit

Låt användaren ytterligare redigera meddelandet som tagits från <fil> med -F <fil>, kommandoraden med -m <meddelande> och från <incheckning> med -C <incheckning>.

--no-edit

Använd det valda incheckningsmeddelandet utan att starta en redigerare. Till exempel ändrar git commit --amend --no-edit en incheckning utan att ändra dess incheckningsmeddelande.

--amend

Ersätt toppen av den aktuella grenen genom att skapa en ny incheckning. Det inspelade trädet förbereds som vanligt (inklusive effekten av alternativen -i och -o samt ett explicit sökvägsmönster), och meddelandet från den ursprungliga incheckningen används som utgångspunkt, i stället för ett tomt meddelande, när inget annat meddelande anges från kommandoraden via alternativ som -m, -F, -c, etc. Den nya incheckningen har samma föräldrar och författare som den aktuella (alternativet --reset-author kan motverka detta).

Det motsvarar ungefär:

	$ git reset --soft HEAD^
	$ ... gör något annat för att få fram rätt träd ...
	$ git commit -c ORIG_HEAD

men kan användas för att ändra en sammanslagningsincheckning.

Du bör förstå konsekvenserna av att skriva om historiken om du ändrar en incheckning som redan har publicerats. (Se avsnittet "ÅTERSTÄLLA FRÅN UPSTRÖMSREBASE" i git-rebase[1].)

--no-post-rewrite

Hoppa över kroken post-rewrite.

-i
--include

Innan du gör en incheckning från det hittills köaded innehållet, köa även innehållet i de sökvägar som anges på kommandoraden. Detta är vanligtvis inte vad du vill om du inte slutför en konfliktfylld sammanslagning.

-o
--only

Gör en incheckning genom att hämta det uppdaterade innehållet i arbetsträdet för de sökvägar som anges på kommandoraden, utan att ta hänsyn till innehåll som är köade för andra sökvägar. Detta är standardläget för git commit om några sökvägar anges på kommandoraden, i vilket fall detta alternativ kan utelämnas. Om detta alternativ anges tillsammans med --amend behöver inga sökvägar anges, vilka kan användas för att ändra den senaste incheckningen utan att checka in ändringar som redan har köats. Om de används tillsammans med --allow-empty krävs inte heller några sökvägar, och en tom incheckning kommer att skapas.

--pathspec-from-file=<fil>

Skicka sökvägsmönster i <fil> i stället för kommandoradsargument. Om <fil> är exakt - används standardindata. Sökvägsmönsterposter separeras med LF eller CR/LF. Sökvägsmönsterposter kan citeras enligt beskrivningen för konfigurationsvariabeln core.quotePath (se git-config[1]). Se även --pathspec-file-nul och globala --literal-pathspecs.

--pathspec-file-nul

Endast meningsfullt med --pathspec-from-file. Sökvägsmönsterposter separeras med tecknet NUL och alla andra tecken tolkas bokstavligt (inklusive radbrytningar och citattecken).

-u[<läge>]
--untracked-files[=<läge>]

Visa ospårade filer.

Parametern <mode> är valfri (standardinställningen är all) och används för att ange hanteringen av ospårade filer; när -u inte används är standardinställningen normal, d.v.s. visar ospårade filer och kataloger.

De möjliga alternativen är:

no

Visa inga ospårade filer

normal

Visar ospårade filer och kataloger

all

Visar även enskilda filer i ospårade kataloger.

Alla vanliga stavningar för det booleska värdet true tas som normal och false som no. Standardvärdet kan ändras med hjälp av konfigurationsvariabeln status.showUntrackedFiles som dokumenteras i git-config[1].

-v
--verbose

Visa en enhetlig skillnad mellan HEAD-incheckning och vad som skulle checkas in längst ner i incheckningsmeddelandemallen för att hjälpa användaren att beskriva incheckningen genom att påminna om vilka ändringar incheckningen har. Observera att denna diff-utdata inte har sina rader prefixerade med #. Denna skillnad kommer inte att vara en del av incheckningsmeddelandet. Se konfigurationsvariabeln commit.verbose i git-config[1].

Om det anges två gånger, visa dessutom den enhetliga skillnaden mellan vad som skulle checkas in och arbetsträdet, d.v.s. de oköade ändringarna av spårade filer.

-q
--quiet

Undertryck sammanfattnings-meddelande för incheckningen.

--dry-run

Skapa inte en incheckning, utan visa en lista över sökvägar som ska checkas in, sökvägar med lokala ändringar som kommer att lämnas oincheckade och sökvägar som inte spåras.

--status

Inkludera utdata från git-status[1] i incheckningsmeddelandemallen när en redigerare används för att förbereda incheckningsmeddelandet. Standardinställningen är på, men kan användas för att åsidosätta konfigurationsvariabeln commit.status.

--no-status

Inkludera inte utdata från git-status[1] i incheckningsmeddelandemallen när du använder en redigerare för att förbereda standardincheckningsmeddelandet.

-S[<nyckel-id>]
--gpg-sign[=<nyckel-id>]
--no-gpg-sign

GPG-signera incheckning. <nyckel-id> är valfri och används som standard för incheckare-identiteten; om den anges måste den fästas vid alternativet utan mellanslag. --no-gpg-sign är användbar för att negligera både konfigurationsvariabeln commit.gpgSign och den tidigare --gpg-sign.

--

Tolka inte fler argument som alternativ.

<sökvägsmönster>...

När <sökvägsmönster> anges på kommandoraden, checka in innehållet i filerna som matchar sökvägsmönster utan att registrera de ändringar som redan lagts till i indexet. Innehållet i dessa filer köas också för nästa incheckning utöver vad som har köats tidigare.

För mer information, se posten sökvägsmönster i gitglossary[7].

EXEMPEL

När du checkar in ditt eget arbete lagras innehållet i modifierade filer i arbetsträdet tillfälligt i en köyta som kallas "index" med git add. En fil kan återställas, endast i indexet men inte i arbetsträdet, till läget i den senaste incheckningen med git restore --staged <fil>, vilket i praktiken ångrar git add och förhindrar att ändringarna i filen tas med i nästa incheckning. Efter att tillståndet som ska checkas in stegvis har byggts upp med dessa kommandon används git commit (utan någon sökvägsparameter) för att registrera det som hittills har köats. Detta är den mest grundläggande formen av kommandot. Ett exempel:

$ edit hej.c
$ git rm adjö.c
$ git add hej.c
$ git commit

I stället för att köa filer efter varje enskild ändring kan du ange att git commit ska notera ändringarna i de filer vars innehåll spåras i ditt arbetsträd och göra motsvarande git add och git rm åt dig. Det vill säga, det här exemplet gör samma sak som det tidigare exemplet om det inte finns någon annan ändring i ditt arbetsträd:

$ edit hej.c
$ rm adjö.c
$ git commit -a

Kommandot git commit -a tittar först på ditt arbetsträd, ser att du har ändrat hello.c och tagit bort goodbye.c, och utför nödvändiga git add och git rm åt dig.

Efter att ha köat ändringar i många filer kan du ändra ordningen som ändringarna registreras i genom att ge sökvägar till git commit. När sökvägar anges gör kommandot en incheckning som bara registrerar de ändringar som gjorts i de namngivna sökvägarna:

$ edit hej.c hej.h
$ git add hej.c hej.h
$ edit Makefile
$ git commit Makefile

Det här skapar en incheckning som registrerar modifieringen till Makefile. Ändringarna som köats för hej.c och hej.h inkluderas inte i den resulterande incheckningen. Deras ändringar går dock inte förlorade — de köas fortfarande och hålls bara tillbaka. Om du gör det efter ovanstående sekvens:

$ git commit

Denna andra incheckningen skulle registrera ändringarna av hej.c och hej.h som förväntat.

Efter att en sammanslagning (initierad av git merge eller git pull) har stoppats på grund av konflikter är rent sammanslagna sökvägar redan köade för incheckning, och sökvägar med konflikt lämnas ej sammanslagna. Du behöver först kontrollera vilka sökvägar som är i konflikt med git status och, efter att ha åtgärdat dem manuellt i arbetsträdet, köa resultatet som vanligt med git add:

$ git status | grep unmerged
unmerged: hej.c
$ edit hej.c
$ git add hej.c

Efter att konflikter har lösts och resultatet köats, kommer git ls-files -u att sluta nämna den konfliktfyllda sökvägen. När du är klar, kör git commit för att slutligen registrera sammanslagningen:

$ git commit

Precis som i fallet med att registrera dina egna ändringar kan du använda alternativet -a för att spara skrivning. En skillnad är att under en sammanslagningslösning kan du inte använda git commit med sökvägar för att ändra ordningen som ändringarna checkas in, eftersom sammanslagningen ska registreras som en enda incheckning. Kommandot vägrar faktiskt att köras när det ges sökvägar (men se alternativet -i).

INCHECKNINGS INFORMATION

Information om författare och incheckare hämtas från följande miljövariabler, om de är inställda:

  • GIT_AUTHOR_NAME

  • GIT_AUTHOR_EMAIL

  • GIT_AUTHOR_DATE

  • GIT_COMMITTER_NAME

  • GIT_COMMITTER_EMAIL

  • GIT_COMMITTER_DATE

(obs "<", ">" och "\n" är avskalade)

Författar- och incheckare-namnen är enligt konvention någon form av ett personnamn (det vill säga det namn som andra människor refererar till dig med), även om Git inte tillämpar eller kräver någon särskild form. Godtycklig Unicode kan användas, med förbehåll för de begränsningar som anges ovan. Detta namn har ingen effekt på autentisering; för detta, se variabeln credential.username i git-config[1].

Om (några av) dessa miljövariabler inte är angivna, hämtas informationen från konfigurationsalternativen user.name och user.email, eller, om de inte finns, miljövariabeln EMAIL, eller, om den inte är angiven, systemanvändarnamnet och värdnamnet som används för utgående e-post (hämtat från /etc/mailname och använder det fullständiga kvalificerade värdnamnet när den filen inte finns).

author.name och committer.name och deras motsvarande e-postalternativ åsidosätter user.name och user.email om de är inställda och åsidosätts själva av miljövariablerna.

Den typiska användningen är att bara ange variablerna user.name och user.email; de andra alternativen finns för mer komplexa användningsfall.

DATUMFORMAT

Miljövariablerna GIT_AUTHOR_DATE och GIT_COMMITTER_DATE stöder följande datumformat:

Git internt format

Det är <unix-timestamp> <time-zone-offset>, där <unix-timestamp> är antalet sekunder sedan UNIX-epoken. <time-zone-offset> är en positiv eller negativ förskjutning från UTC. Till exempel är CET (som är 1 timme före UTC) +0100.

RFC 2822

Standarddatumformatet som beskrivs av RFC 2822, till exempel Tor, 07 Apr 2005 22:13:13 +0200.

ISO 8601

Tid och datum som anges av ISO 8601-standarden, till exempel 2005-04-07T22:13:13. Parsern accepterar även ett mellanslag istället för tecknet T. Bråkdelar av en sekund kommer att ignoreras, till exempel 2005-04-07T22:13:13.019 kommer att behandlas som 2005-04-07T22:13:13.

Note
Dessutom accepteras datumdelen i följande format: ÅÅÅÅ.MM.DD, MM/DD/ÅÅÅÅ och DD.MM.ÅÅÅÅ.

Förutom att känna igen alla datumformat ovan, kommer alternativet --date också att försöka förstå andra, mer människocentrerade datumformat, såsom relativa datum som "yesterday" (igår) eller "yesterday" (förra fredagen vid middagstid).

DISKUSSION

Även om det inte är ett krav är det en bra idé att börja incheckningsmeddelandet med en enda kort rad (högst 50 tecken) som sammanfattar ändringen, följt av en tom rad och sedan en mer utförlig beskrivning. Texten fram till den första tomma raden i ett incheckningsmeddelande behandlas som incheckningstiteln, och den titeln används i hela Git. Till exempel, git-format-patch[1] omvandlar en commit till ett e-postmeddelande, och den använder titeln på ämnesraden och resten av incheckningsmeddelandet i brödtexten.

Git är till viss del teckenkodningsagnostisk.

  • Innehållet i blob-objekten är otolkade sekvenser av byte. Det finns ingen kodningsöversättning på kärnnivå.

  • Sökvägsnamn är kodade i UTF-8-normaliseringsform C. Detta gäller trädobjekt, indexfilen, referensnamn, såväl som sökvägsnamn i kommandoradsargument, miljövariabler och konfigurationsfiler (.git/config (se git-config[1]), gitignore[5], gitattributes[5] och gitmodules[5]).

    Observera att Git på kärnnivå behandlar sökvägsnamn helt enkelt som sekvenser av icke-NUL-byte, det finns inga konverteringar av sökvägskodning (förutom på Mac och Windows). Därför fungerar användning av sökvägsnamn som inte är ASCII-namn oftast även på plattformar och filsystem som använder äldre utökade ASCII-kodningar. Förvar som skapas på sådana system kommer dock inte att fungera korrekt på UTF-8-baserade system (t.ex. Linux, Mac, Windows) och vice versa. Dessutom antar många Git-baserade verktyg helt enkelt att sökvägsnamn är UTF-8 och kommer inte att kunna visa andra kodningar korrekt.

  • Meddelanden i commitloggar kodas vanligtvis i UTF-8, men andra utökade ASCII-kodningar stöds också. Detta inkluderar ISO-8859-x, CP125x och många andra, men inte UTF-16/32, EBCDIC och CJK multibyte-kodningar (GBK, Shift-JIS, Big5, EUC-x, CP9xx etc.).

Även om vi uppmuntrar att incheckningsloggmeddelanden kodas i UTF-8, är både kärnan och användarkommandona (porcelain) i Git utformade för att inte tvinga fram UTF-8 i projekt. Om alla deltagare i ett visst projekt tycker att det är bekvämare att använda äldre kodningar, förbjuder inte Git det. Det finns dock några saker att tänka på.

  1. git commit och git commit-tree utfärdar en varning om incheckningsloggmeddelandet som ges till det inte ser ut som en giltig UTF-8-sträng, såvida du inte uttryckligen anger att ditt projekt använder en äldre kodning. Sättet att säga detta är att ha i18n.commitEncoding i .git/config-filen, så här:

    [i18n]
    	commitEncoding = ISO-8859-1

    Incheckningsobjekt som skapats med ovanstående inställning registrerar värdet för i18n.commitEncoding i sin encoding-header. Detta är för att hjälpa andra som tittar på dem senare. Avsaknaden av denna header innebär att incheckningsloggmeddelandet är kodat i UTF-8.

  2. git log, git show, git blame och vänner tittar på encoding-headern för ett incheckningsobjekt och försöker koda om loggmeddelandet till UTF-8 om inget annat anges. Du kan ange önskad utdatakodning med i18n.logOutputEncoding i .git/config-filen, så här:

    [i18n]
    	logOutputEncoding = ISO-8859-1

    Om du inte har den här konfigurationsvariabeln används värdet för i18n.commitEncoding i stället.

Observera att vi medvetet valde att inte koda om incheckningsloggmeddelandet när en incheckning görs för att tvinga fram UTF-8 på incheckningsobjektnivå, eftersom omkodning till UTF-8 inte nödvändigtvis är en reversibel operation.

MILJÖ- OCH KONFIGURATIONSVARIABLER

Redigeraren som används för att redigera incheckningsloggmeddelandet kommer att väljas från miljövariabeln GIT_EDITOR, konfigurationsvariabeln core.editor, miljövariabeln VISUAL eller miljövariabeln EDITOR (i den ordningen). Se git-var[1] för mer information.

Allt ovanför den här raden i det här avsnittet finns inte med i dokumentationen för git-config[1]. Innehållet som följer är detsamma som det som finns där:

commit.cleanup

Den här inställningen åsidosätter standardinställningen för --cleanup-alternativet i git commit. Att ändra standardinställningen kan vara användbart när du alltid vill behålla rader som börjar med kommentartecknet (core.commentChar, standard #) i ditt loggmeddelande, i vilket fall du skulle göra git config commit.cleanup whitespace (observera att du själv måste ta bort hjälpraderna som börjar med kommentartecknet i incheckning-loggmallen om du gör detta).

commit.gpgSign

En boolesk kod som anger om alla incheckningar ska GPG-signeras. Användning av det här alternativet vid operationer som ombasering kan resultera i att ett stort antal incheckningar signeras. Det kan vara praktiskt att använda en agent för att undvika att skriva in din GPG-lösenfras flera gånger.

commit.status

Ett booleskt värde för att aktivera/inaktivera inkludering av statusinformation i inchecknings-meddelandemallen när en editor används för att förbereda inchecknings-meddelandet. Standardvärdet är true.

commit.template

Ange sökvägen till en fil som ska användas som mall för nya inchecknings-meddelanden.

commit.verbose

Ett booleskt värde eller ett heltal för att ange utförlighetsnivån med git commit.

KROKAR

Det här kommandot kan köra hakarna commit-msg, prepare-commit-msg, pre-commit, post-commit och post-rewrite. Se githooks[5] för mer information.

FILER

$GIT_DIR/COMMIT_EDITMSG

Den här filen innehåller incheckningsmeddelandet för en pågående incheckning. Om git commit avslutas på grund av ett fel innan en incheckning skapas, kommer alla incheckningsmeddelanden som har tillhandahållits av användaren (t.ex. i en redigeringssession) att finnas tillgängliga i den här filen, men kommer att skrivas över av nästa anrop av git commit.

GIT

En del av git[1]-sviten