git-commit(1)

Från Wiki.linux.se -Linux wikipedia på Svenska.
Hoppa till navigering Hoppa till sök

git-commit(1)

NAMN

git-commit - registrera ändringar i förrådet

SYNOPSIS

git commit [-a | --interactive | --patch] [-s] [-v] [-u[<läge>]] [--amend]
           [--dry-run] [(-c | -C | --squash) <incheckning> | --fixup [(amend|reword):]<incheckning>]
           [-F <fil> | -m <meddelande>] [--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 <nyckel>[(=|:)<värde>])...] [-S[<nyckel-id>]]
           [--] [<sökvägsmönster>...]

BESKRIVNING

Skapa en ny incheckning som innehåller det aktuella innehållet i indexet och det angivna loggmeddelandet som beskriver ändringarna. Den nya incheckningen blir ett direkt barn till HEAD, vanligtvis spetsen på den aktuella grenen, och grenen uppdateras så att den pekar på den nya incheckningen. Om ingen gren är kopplad till arbetskatalogen är HEAD i stället ”frikopplad”, vilket beskrivs 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 kommandot commit används. Observera att även ändrade filer måste ”läggas till”.
  2. Genom att använda git-rm(1) för att ta bort filer från arbetskatalogen och indexet innan kommandot commit används.
  3. Genom att ange filer som argument till kommandot commit utan växlarna --interactive eller --patch. Då ignoreras ändringar som redan är staged i indexet, och i stället registreras det aktuella innehållet i de angivna filerna, som redan måste vara kända av Git.
  4. Genom att använda växeln -a med kommandot commit för att automatiskt lägga till ändringar från alla kända filer, det vill säga filer som redan finns i indexet, samt automatiskt ta bort filer ur indexet som har tagits bort från arbetskatalogen, och därefter utföra själva incheckningen.
  5. Genom att använda växlarna --interactive eller --patch med kommandot commit för att välja fil för fil eller hunk för hunk vad som ska ingå i incheckningen, utöver innehållet i indexet, innan operationen avslutas. Se avsnittet ”Interactive Mode” i git-add(1) för hur dessa lägen används.

Växeln --dry-run kan användas för att få en sammanfattning av vad som skulle ingå i nästa incheckning med samma uppsättning parametrar, det vill säga alternativ och sökvägar.

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

ALTERNATIV

-a, --all

Lägg automatiskt till filer som har ändrats och tagits bort. Nya filer som du ännu 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>

Generera diffar med n rader sammanhang. Antalet sammanhangsrader är som standard diff.context eller 3 om konfigurationsvariabeln inte är satt. Av historiska skäl accepteras -U utan n tyst som en synonym för -p.

--inter-hunk-context=<n>

Visa sammanhang mellan diff-hunkar, upp till angivet antal rader, och slå därmed ihop hunkar som ligger nära varandra. Standard är diff.interHunkContext eller 0 om konfigurationsalternativet inte är satt.

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

Ta ett befintligt incheckningsobjekt och återanvänd loggmeddelandet och författarinformationen, inklusive tidsstämpeln, när den nya incheckningen skapas.

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

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

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

Skapa en ny incheckning som ”fixar” incheckning när den används tillsammans med git rebase --autosquash. En vanlig --fixup=<incheckning> skapar en ”fixup!”-incheckning som ändrar innehållet i incheckning men lämnar dess loggmeddelande oförändrat. --fixup=amend:<incheckning> liknar detta, men skapar en ”amend!”-incheckning som även 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 inte gör några ändringar i innehållet i incheckning.
Incheckningen som skapas av vanlig --fixup=<incheckning> får en titel som består av ”fixup!” följt av titeln på incheckning, och känns igen särskilt av git rebase --autosquash. Alternativet -m kan användas för att komplettera loggmeddelandet i den skapade incheckningen, men den extra kommentaren kastas bort när ”fixup!”-incheckningen slås ihop med incheckning av git rebase --autosquash.
Incheckningen som skapas av --fixup=amend:<incheckning> liknar detta, men dess titel får i stället prefixet ”amend!”. Loggmeddelandet från incheckning kopieras in i loggmeddelandet för ”amend!”-incheckningen och öppnas i en editor så att det kan förbättras. När git rebase --autosquash slår ihop ”amend!”-incheckningen med incheckning ersätts loggmeddelandet för incheckning av det förbättrade loggmeddelandet från ”amend!”-incheckningen. Det är ett fel om loggmeddelandet för ”amend!”-incheckningen är tomt, om inte --allow-empty-message anges.
--fixup=reword:<incheckning> är en kortform för --fixup=amend:<incheckning> --only. Den skapar en ”amend!”-incheckning med enbart ett loggmeddelande och ignorerar ändringar som har staged i indexet. När den slås ihop av git rebase --autosquash ersätter den loggmeddelandet för incheckning utan att göra några andra ändringar.
Varken ”fixup!”- eller ”amend!”-incheckningar ändrar författarskapet för incheckning när de 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. Titeln i incheckningsmeddelandet tas från den angivna incheckningen med prefixet ”squash! ”. Kan användas med ytterligare alternativ för incheckningsmeddelanden, till exempel -m, -c, -C eller -F. Se git-rebase(1) för detaljer.

--reset-author

När detta används med alternativen -C, -c eller --amend, eller vid incheckning efter en konfliktfylld cherry-pick, anges att författarskapet för den resulterande incheckningen nu tillhör den som gör incheckningen. Detta förnyar även författarens tidsstämpel.

--short

Vid torrkörning ges utdata i kortformat. 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 detaljer.

--porcelain

Vid torrkörning ges utdata i ett format lämpligt för skript. Se git-status(1) för detaljer. Implicerar --dry-run.

--long

Vid torrkörning ges utdata i långformat. Detta är standardutdata från git-status(1). Implicerar --dry-run.

-z, --null

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

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

Ta incheckningsmeddelandet från fil. Använd - för att läsa meddelandet från standard in.

--author=<författare>

Åsidosätt incheckningens författare. Ange en uttrycklig författare med standardformatet A U Thor <author@example.com>. Annars antas författare vara ett mönster som används för att söka efter en befintlig incheckning av den författaren, det vill säga git rev-list --all -i --author=<författare>. Författaren kopieras då från den första sådan incheckningen som hittas.

--date=<datum>

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

-m <meddelande>, --message=<meddelande>

Använd meddelande som incheckningsmeddelande. Om flera -m-alternativ anges sammanfogas deras värden som separata stycken.
Alternativet -m är ömsesidigt uteslutande med -c, -C och -F.

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

När incheckningsmeddelandet redigeras startas editorn med innehållet från fil. Konfigurationsvariabeln commit.template används ofta för att ange detta alternativ implicit. Mekanismen kan användas av projekt som vill ge deltagare vägledning om vad som ska skrivas i meddelandet och i vilken ordning. Om användaren avslutar editorn utan att redigera meddelandet avbryts incheckningen. Detta har ingen effekt när ett meddelande anges på annat sätt, till exempel med -m eller -F.

-s, --signoff, --no-signoff

Lägg till en Signed-off-by-trailer av den som gör incheckningen i slutet av incheckningens loggmeddelande. Betydelsen av en signoff beror på projektet där incheckningen görs. Den kan exempelvis intyga att incheckaren har rätt att skicka in arbetet enligt projektets licens eller godkänner vissa bidragsvillkor, såsom ett Developer Certificate of Origin. Se https://developercertificate.org för den variant som används av Linuxkärnan och Git-projekten. Läs projektets dokumentation eller fråga projektledningen för att förstå hur signoffs används i det aktuella projektet.
Alternativet --no-signoff kan användas för att upphäva ett tidigare --signoff på kommandoraden.
Git har inte, och kommer inte att ha, någon konfigurationsvariabel som aktiverar kommandoradsalternativet --signoff som standard. Se posten commit.signoff i gitfaq(7) för mer information.

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

Ange ett par (nyckel, värde) som ska användas som trailer. Exempelvis kan git commit --trailer "Signed-off-by:C O Mitter <committer@example.com>" --trailer "Helped-by:C O Mitter <committer@example.com>" lägga till trailerna Signed-off-by och Helped-by i incheckningsmeddelandet. Konfigurationsvariablerna trailer.* i git-interpret-trailers(1) kan användas för att definiera om duplicerade trailers ska utelämnas, var i trailerblocket varje trailer ska placeras och andra detaljer.

-n, --verify, --no-verify

Gå förbi hookarna pre-commit och commit-msg. Se även githooks(5).

--allow-empty

Normalt är det ett misstag att registrera en incheckning som har exakt samma träd som sin enda förälder, och kommandot förhindrar därför detta. Detta alternativ går förbi skyddet och är främst avsett för gränssnittsskript mot andra versionshanteringssystem.

--allow-empty-message

Skapa en incheckning med tomt incheckningsmeddelande utan att använda plumbing-kommandon som git-commit-tree(1). Liksom --allow-empty är detta främst avsett för gränssnittsskript mot andra versionshanteringssystem.

--cleanup=<läge>

Bestäm hur det angivna incheckningsmeddelandet ska städas innan incheckningen görs. Läge kan vara strip, whitespace, verbatim, scissors eller default.
strip
Ta bort inledande och avslutande tomma rader, avslutande blanktecken och kommentarer samt slå ihop flera tomma rader i följd.
whitespace
Samma som strip, utom att kommentarer med # inte tas bort.
verbatim
Ändra inte meddelandet alls.
scissors
Samma som whitespace, förutom att allt från och med raden nedan trunkeras om meddelandet ska redigeras. Tecknet ”#” 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 redigera meddelandet ytterligare när det hämtats från fil med -F <fil>, från kommandoraden med -m <meddelande> eller från incheckning med -C <incheckning>.

--no-edit

Använd det valda incheckningsmeddelandet utan att starta en editor. Exempelvis ändrar git commit --amend --no-edit den senaste incheckningen utan att ändra dess incheckningsmeddelande.

--amend

Ersätt spetsen på den aktuella grenen genom att skapa en ny incheckning. Det registrerade trädet förbereds som vanligt, inklusive effekten av alternativen -i och -o och uttryckliga 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 via alternativ som -m, -F, -c och så vidare. Den nya incheckningen har samma föräldrar och författare som den aktuella, men --reset-author kan åsidosätta 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 även användas för att ändra en merge-incheckning.
Du bör förstå konsekvenserna av att skriva om historik om du ändrar en incheckning som redan har publicerats. Se avsnittet ”RECOVERING FROM UPSTREAM REBASE” i git-rebase(1).

--no-post-rewrite

Gå förbi hooken post-rewrite.

-i, --include

Innan en incheckning görs av hittills staged innehåll, stage:a även innehållet i sökvägarna som anges på kommandoraden. Detta är normalt inte vad du vill, förutom när du avslutar en konfliktfylld merge.

-o, --only

Gör en incheckning genom att ta det uppdaterade innehållet i arbetskatalogen för de sökvägar som anges på kommandoraden och ignorera innehåll som staged för andra sökvägar. Detta är standardläget för git commit om sökvägar anges på kommandoraden, och då kan detta alternativ utelämnas. Om alternativet anges tillsammans med --amend behöver inga sökvägar anges, vilket kan användas för att ändra den senaste incheckningen utan att checka in ändringar som redan är staged. Om det används tillsammans med --allow-empty krävs inte heller sökvägar, och en tom incheckning skapas.

--pathspec-from-file=<fil>

Skicka sökvägsmönster i fil i stället för som kommandoradsargument. Om fil är exakt - används standard in. Sökvägsmönster separeras med LF eller CR/LF. Sökvägsmönster kan citeras enligt beskrivningen av konfigurationsvariabeln core.quotePath i git-config(1). Se även --pathspec-file-nul och det globala alternativet --literal-pathspecs.

--pathspec-file-nul

Endast meningsfullt tillsammans med --pathspec-from-file. Sökvägsmönster separeras med NUL och alla andra tecken tas bokstavligt, inklusive radbrytningar och citationstecken.

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

Visa ospårade filer.
Parametern läge är valfri och är som standard all. Den används för att ange hur ospårade filer ska hanteras. När -u inte används är standardvärdet normal, det vill säga att ospårade filer och kataloger visas.
Möjliga värden är:
no
Visa inga ospårade filer.
normal
Visa ospårade filer och kataloger.
all
Visa även enskilda filer i ospårade kataloger.
Alla vanliga stavningar av det booleska värdet true tolkas som normal och false som no. Standardvärdet kan ändras med konfigurationsvariabeln status.showUntrackedFiles som dokumenteras i git-config(1).

-v, --verbose

Visa en unified diff mellan HEAD-incheckningen och det som skulle checkas in längst ned i mallen för incheckningsmeddelandet, så att användaren lättare kan beskriva incheckningen genom att påminnas om ändringarna. Observera att raderna i denna diff inte får prefixet #. Diffen blir inte en del av incheckningsmeddelandet. Se konfigurationsvariabeln commit.verbose i git-config(1).
Om alternativet anges två gånger visas dessutom en unified diff mellan det som skulle checkas in och filerna i arbetskatalogen, det vill säga ändringar i spårade filer som ännu inte staged.

-q, --quiet

Undertryck sammanfattningsmeddelandet för incheckningen.

--dry-run

Skapa ingen incheckning, men visa en lista över sökvägar som skulle checkas in, sökvägar med lokala ändringar som skulle lämnas utanför incheckningen och sökvägar som är ospårade.

--status

Ta med utdata från git-status(1) i mallen för incheckningsmeddelandet när en editor används för att förbereda meddelandet. Standard är på, men alternativet kan användas för att åsidosätta konfigurationsvariabeln commit.status.

--no-status

Ta inte med utdata från git-status(1) i mallen för incheckningsmeddelandet när en editor används för att förbereda standardmeddelandet.

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

GPG-signera incheckningar. Nyckel-id är valfritt och är som standard incheckarens identitet. Om det anges måste det sitta direkt ihop med alternativet utan mellanslag. --no-gpg-sign är användbart för att upphäva både konfigurationsvariabeln commit.gpgSign och tidigare --gpg-sign.

--

Tolka inga fler argument som alternativ.

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

När sökvägsmönster anges på kommandoraden checkas innehållet i de filer som matchar mönstret in, utan att registrera de ändringar som redan lagts till i indexet. Innehållet i dessa filer staged också för nästa incheckning ovanpå det som redan var staged.
För mer information, se posten pathspec i gitglossary(7).

EXEMPEL

När du registrerar ditt eget arbete lagras innehållet i ändrade filer i arbetskatalogen tillfälligt i en staging-yta som kallas ”index” med git add. En fil kan återställas, endast i indexet men inte i arbetskatalogen, till läget i den senaste incheckningen med git restore --staged <fil>. Det återställer i praktiken effekten av git add och hindrar ändringarna i filen från att delta i nästa incheckning. Efter att tillståndet som ska checkas in byggts upp stegvis med dessa kommandon används git commit utan några sökvägsparametrar för att registrera det som hittills staged. Detta är den mest grundläggande formen av kommandot. Exempel: 

$ edit hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit

I stället för att stage:a filer efter varje enskild ändring kan du be git commit att upptäcka ändringar i filer vars innehåll spåras i arbetskatalogen och utföra motsvarande git add och git rm åt dig. Det här exemplet gör alltså samma sak som föregående exempel, förutsatt att det inte finns någon annan ändring i arbetskatalogen: 

$ edit hello.c
$ rm goodbye.c
$ git commit -a

Kommandot git commit -a tittar först på arbetskatalogen, upptäcker att hello.c har ändrats och att goodbye.c har tagits bort, och utför nödvändiga git add och git rm åt dig.

Efter att ha stage:at ändringar i många filer kan du ändra i vilken ordning ändringarna registreras genom att ange sökvägar till git commit. När sökvägar anges skapar kommandot en incheckning som bara registrerar ändringarna i de namngivna sökvägarna: 

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

Detta skapar en incheckning som registrerar ändringen i Makefile. De staged ändringarna i hello.c och hello.h ingår inte i den resulterande incheckningen. Ändringarna går dock inte förlorade — de är fortfarande staged och hålls bara tillbaka. Efter sekvensen ovan skulle följande kommando: 

$ git commit

skapa en andra incheckning som registrerar ändringarna i hello.c och hello.h, som förväntat.

Efter en merge som startats av git merge eller git pull och stoppats på grund av konflikter är rent sammanslagna sökvägar redan staged för incheckning, medan sökvägar med konflikter lämnas i ett osammanslaget tillstånd. Du måste först kontrollera vilka sökvägar som har konflikter med git status, och efter att ha löst dem manuellt i arbetskatalogen stage:a resultatet som vanligt med git add: 

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

Efter att konflikterna lösts och resultatet staged ska git ls-files -u inte längre nämna den konfliktdrabbade sökvägen. När du är klar kör du git commit för att slutligen registrera sammanslagningen: 

$ git commit

Precis som när du registrerar egna ändringar kan du använda alternativet -a för att slippa skriva lika mycket. En skillnad är att du under lösning av en merge inte kan använda git commit med sökvägar för att ändra ordningen som ändringarna checkas in i, eftersom en merge ska registreras som en enda incheckning. Kommandot vägrar faktiskt att köras när det får sökvägar, men se alternativet -i.

INCHECKNINGSINFORMATION

Information om författare och incheckare tas från följande miljövariabler, om de är satta:

  • GIT_AUTHOR_NAME
  • GIT_AUTHOR_EMAIL
  • GIT_AUTHOR_DATE
  • GIT_COMMITTER_NAME
  • GIT_COMMITTER_EMAIL
  • GIT_COMMITTER_DATE

Observera att ”<”, ”>” och radbrytningar tas bort.

Författarens och incheckarens namn är enligt konvention någon form av personnamn, alltså det namn som andra människor använder för att hänvisa till dig, även om Git inte upprätthåller eller kräver någon särskild form. Godtycklig Unicode kan användas, med de begränsningar som anges ovan. Namnet har ingen betydelse för autentisering; för det, se variabeln credential.username i git-config(1).

Om några av dessa miljövariabler inte är satta hämtas informationen från konfigurationsposterna user.name och user.email, eller, om de saknas, från miljövariabeln EMAIL, eller, om även den saknas, från systemets användarnamn och värdnamnet som används för utgående e-post. Värdnamnet tas från /etc/mailname och faller tillbaka till det fullt kvalificerade värdnamnet om filen inte finns.

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

Den typiska användningen är att bara sätta variablerna user.name och user.email. De andra alternativen finns för mer avancerade användningsfall.

DATUMFORMAT

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

Gits interna format

Formatet är <unix-tidsstämpel> <tidszonsförskjutning>, där unix-tidsstämpel är antalet sekunder sedan Unix-epoken. Tidszonsförskjutning är en positiv eller negativ förskjutning från UTC. Till exempel är CET, som ligger 1 timme före UTC, +0100.

RFC 2822

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

ISO 8601

Tid och datum enligt ISO 8601-standarden, till exempel 2005-04-07T22:13:13. Parsern accepterar även ett mellanslag i stället för tecknet T. Bråkdelar av en sekund ignoreras, till exempel behandlas 2005-04-07T22:13:13.019 som 2005-04-07T22:13:13.
Observera att datumdelen dessutom accepteras i följande format: YYYY.MM.DD, MM/DD/YYYY och DD.MM.YYYY.

Utöver att känna igen alla datumformat ovan försöker alternativet --date även tolka mer människocentrerade datumformat, såsom relativa datum som ”yesterday” eller ”last Friday at noon”.

DISKUSSION

Även om det inte är ett krav är det en god idé att börja incheckningsmeddelandet med en kort ensam rad, högst 50 tecken, som sammanfattar ändringen, följd av en tom rad och därefter en mer utförlig beskrivning. Texten fram till den första tomma raden i ett incheckningsmeddelande behandlas som incheckningens titel, och den titeln används i hela Git. Till exempel omvandlar git-format-patch(1) en incheckning till e-post, och använder titeln på ämnesraden och resten av incheckningen som meddelandets kropp.

Git är i viss utsträckning agnostiskt när det gäller teckenkodning.

  • Innehållet i blob-objekten är otolkade sekvenser av byte. Ingen kodningsöversättning sker på kärnnivå.
  • Sökvägsnamn kodas i UTF-8 normaliseringsform C. Detta gäller trädobjekt, indexfilen, ref-namn, samt sökvägar i kommandoradsargument, miljövariabler och konfigurationsfiler, såsom .git/config enligt 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 byte som inte är NUL. Det finns inga kodningskonverteringar av sökvägsnamn, utom på Mac och Windows. Därför fungerar användning av icke-ASCII-sökvägar oftast även på plattformar och filsystem som använder äldre utökade ASCII-kodningar. Däremot fungerar förråd skapade på sådana system inte nödvändigtvis korrekt på UTF-8-baserade system, exempelvis Linux, Mac och Windows, och omvänt. Dessutom antar många Git-baserade verktyg helt enkelt att sökvägsnamn är UTF-8 och kan misslyckas med att visa andra kodningar korrekt.

  • Incheckningsloggmeddelanden är normalt kodade i UTF-8, men andra utökade ASCII-kodningar stöds också. Detta omfattar ISO-8859-x, CP125x och många andra, men inte UTF-16/32, EBCDIC eller CJK-multibytekodningar som GBK, Shift-JIS, Big5, EUC-x och CP9xx.

Även om Git uppmuntrar att incheckningsloggmeddelanden kodas i UTF-8 är både kärnan och Gits Porcelain-kommandon utformade för att inte tvinga UTF-8 på projekt. Om alla deltagare i ett visst projekt tycker att det är mer praktiskt att använda äldre kodningar förbjuder Git inte detta. Det finns dock några saker att tänka på.

  1. git commit och git commit-tree varnar om det angivna incheckningsloggmeddelandet inte verkar vara en giltig UTF-8-sträng, om du inte uttryckligen anger att projektet använder en äldre kodning. Sätt detta i filen .git/config:
[i18n]
        commitEncoding = ISO-8859-1
Incheckningsobjekt som skapas med inställningen ovan registrerar värdet för i18n.commitEncoding i sin encoding-rubrik. Detta hjälper andra som senare tittar på dem. Om rubriken saknas innebär det att incheckningsloggmeddelandet är kodat i UTF-8.
  1. git log, git show, git blame och liknande kommandon tittar på encoding-rubriken i 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:
[i18n]
        logOutputEncoding = ISO-8859-1
Om du inte har denna konfigurationsvariabel används värdet för i18n.commitEncoding i stället.

Observera att Git medvetet inte kodar om incheckningsloggmeddelandet när en incheckning görs för att tvinga UTF-8 på incheckningsobjektsnivå, eftersom omkodning till UTF-8 inte nödvändigtvis är reversibel.

MILJÖ- OCH KONFIGURATIONSVARIABLER

Editorn som används för att redigera incheckningsloggmeddelandet väljs 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 detaljer.

Allt ovanför denna rad i detta avsnitt ingår inte från dokumentationen för git-config(1). Innehållet som följer är detsamma som finns där:

commit.cleanup

Denna inställning åsidosätter standardvärdet för alternativet --cleanup i git commit. Att ändra standardvärdet kan vara användbart när du alltid vill behålla rader som börjar med kommentartecknet, core.commentChar som standard är #, i ditt loggmeddelande. Då kan du köra git config commit.cleanup whitespace. Observera att du själv måste ta bort hjälpraderna som börjar med kommentartecknet i mallen för incheckningsloggmeddelandet om du gör detta.

commit.gpgSign

Ett booleskt värde som anger om alla incheckningar ska GPG-signeras. Att använda detta alternativ vid operationer som rebase kan leda till att ett stort antal incheckningar signeras. Det kan vara praktiskt att använda en agent för att undvika att skriva GPG-lösenfrasen flera gånger.

commit.status

Ett booleskt värde som aktiverar eller inaktiverar inkluderandet av statusinformation i mallen för incheckningsmeddelandet när en editor används för att förbereda meddelandet. Standard är true.

commit.template

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

commit.verbose

Ett booleskt värde eller heltal som anger detaljnivån för git commit.

HOOKAR

Detta kommando kan köra hookarna commit-msg, prepare-commit-msg, pre-commit, post-commit och post-rewrite. Se githooks(5) för mer information.

FILER

$GIT_DIR/COMMIT_EDITMSG

Denna fil innehåller incheckningsmeddelandet för en pågående incheckning. Om git commit avslutas på grund av ett fel innan en incheckning skapas, finns det incheckningsmeddelande som användaren har angivit, till exempel i en editorsession, tillgängligt i denna fil. Det skrivs dock över vid nästa körning av git commit.

SE ÄVEN

git-add(1), git-rm(1), git-mv(1), git-merge(1), git-commit-tree(1)

GIT

Del av git(1)-sviten.

KOLOFON

Denna sida är en del av projektet git (Git distributed version control system). Information om projektet finns på http://git-scm.com/. Om du har en felrapport för denna manualsida, se http://git-scm.com/community. Denna sida hämtades från projektets uppströms Git-förråd https://github.com/git/git.git den 2026-05-24. Vid den tidpunkten var datumet för den senaste hittade incheckningen i förrådet 2026-05-22. Om du upptäcker renderingsproblem i denna HTML-version av sidan, eller anser att det finns en bättre eller mer aktuell källa för sidan, eller har rättelser eller förbättringar till informationen i denna KOLOFON, som inte är en del av den ursprungliga manualsidan, skicka e-post till man-pages@man7.org.

Git 2.54.0.254.g6a4418 2026-05-22 GIT-COMMIT(1)

Sidslut

Orginalhemsidan på Engelska https://man7.org/linux/man-pages/man1/git-commit.1.html Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på https://www.linux.se/kontaka-linux-se/

Tack till Datorhjälp hemma som har sponsrat Linux.se med webbhotell.

Hämtad från "https://wiki.linux.se/index.php?title=git-commit(1)&oldid=9599"