Admin: Skapade sidan med '= git-commit(1) = == NAMN == git-commit - registrera ändringar i förrådet == SYNOPSIS ==
 git commit [-a | --interactive | --patch] [-s] [-v] [-u[]] [--amend]            [--dry-run] [(-c | -C | --squash)  | --fixup [(amend|reword):]]            [-F  | -m ] [--reset-author] [--allow-empty]            [--allow-empty-message] [--no-verify] [-e] [--author=]            [--date=] [--cleanup=
2026-05-27T09:32:05Z
Skapade sidan med '= git-commit(1) =  == NAMN ==  git-commit - registrera ändringar i förrådet  == SYNOPSIS ==  <pre> 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äg...'
Ny sida
= git-commit(1) =



== NAMN ==



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



== SYNOPSIS ==



<pre>

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>...]

</pre>



== 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:



# 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”.

# Genom att använda [[git-rm(1)]] för att ta bort filer från arbetskatalogen och indexet innan kommandot '''commit''' används.

# 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.

# 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.

# 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'''.

<pre>

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

</pre>



: '''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:



<pre>

$ git reset --soft HEAD^

$ ... gör något annat för att få fram rätt träd ...

$ git commit -c ORIG_HEAD

</pre>



: 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:



<pre>

$ edit hello.c

$ git rm goodbye.c

$ git add hello.c

$ git commit

</pre>



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:



<pre>

$ edit hello.c

$ rm goodbye.c

$ git commit -a

</pre>



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:



<pre>

$ edit hello.c hello.h

$ git add hello.c hello.h

$ edit Makefile

$ git commit Makefile

</pre>



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:



<pre>

$ git commit

</pre>



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''':



<pre>

$ git status | grep unmerged

unmerged: hello.c

$ edit hello.c

$ git add hello.c

</pre>



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:



<pre>

$ git commit

</pre>



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å.



# '''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''':

<pre>

[i18n]

        commitEncoding = ISO-8859-1

</pre>

: 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.



# '''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''':

<pre>

[i18n]

        logOutputEncoding = ISO-8859-1

</pre>

: 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/

<BR><BR>Tack till [https://datorhjalp.se/web/datorhjalp-hemma// Datorhjälp hemma] som har  sponsrat [https://www.linux.se Linux.se] med webbhotell.



[[Kategori:Linuxmanual grupp 1]]

[[Kategori:Linuxmanual]]
git-commit(1) - Versionshistorik
