[ Web Proxy ]
URL:
Viewing: https://git-scm.com/docs/git-commit/sv [Back]  [Original]
Git - git-commit Documentation
Git [Git]
Type / to search entire site:
dark-mode.svg [dark-mode.svg]
Svenska Topics Latest version git-commit last updated in 2.55.0

NAMN

git-commit - Registrera ndringar i kodfrrdet

SYNOPSIS

git commit [-a | --interactive | --patch] [-s] [-v] [-u[<lge>]] [--amend]
           [--dry-run] <incheckning>]
           [-F <fil> | -m <medd>] [--reset-author] [--allow-empty]
           [--allow-empty-message] [--no-verify] [-e] [--author=<frfattare>]
           [--date=<datum>] [--cleanup=<lge>] [--[no-]status]
           [-i | -o] [--pathspec-from-file=<fil> [--pathspec-file-nul]]
           [(--trailer <symbol>[(=|:)<vrde>])…​] [-S[<nyckel-id>]]
           [--] [<skvg>…​]

BESKRIVNING

Skapa en ny incheckning som innehller det aktuella innehllet 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 fr att peka p den (svida ingen gren r associerad med arbetstrd, i vilket fall HEAD "kopplas frn" enligt beskrivningen i git-checkout[1]).

Innehllet som ska checkas in kan anges p flera stt:

  1. genom att anvnda git-add[1] fr att stegvis "lgga till" ndringar i indexet innan man anvnder commit-kommandot (Obs: ven modifierade filer mste "lggas till");

  2. genom att anvnda git-rm[1] fr att ta bort filer frn arbetstrdet och indexet, innan commit-kommandot anvnds;

  3. genom att lista filer som argument till commit-kommandot (utan --interactive eller --patch), i vilket fall incheckningen ignorerar ndringar som kats i indexet och i stllet registrerar det aktuella innehllet i de listade filerna (som Git redan mste knna till);

  4. genom att anvnda -a med commit-kommandot fr att automatiskt "lgga till" ndringar frn alla knda filer (d.v.s. filer som redan finns i indexet) och automatiskt "rm" filer i indexet som tagits bort frn arbetstrdet, och drefter utfra sjlva incheckningen;

  5. genom att anvnda vxlarna --interactive eller --patch med kommandot commit fr att en efter en bestmma vilka filer eller stycken som ska ing i incheckningen utver innehllet i indexet, innan operationen slutfrs. Se avsnittet “Interaktivt lge” i git-add[1] fr att lra dig hur man anvnder dessa lgen.

Alternativet --dry-run kan anvndas fr att f en sammanfattning av vad som ingr i ngot av ovanstende fr nsta incheckning genom att ange samma uppsttning parametrar (alternativ och skvgar).

Om du gr en incheckning och direkt drefter upptcker ett misstag kan du terhmta dig med git reset.

ALTERNATIV

-a
--all

Kar automatiskt filer som har ndrats eller tagits bort, men nya filer som du inte har talat om fr Git pverkas inte.

-p
--patch

Anvnd det interaktiva grnssnittet fr patchval fr att vlja vilka ndringar som ska checkas in. Se git-add[1] fr detaljer.

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

Generate diffs with <n> lines of context. The number of context lines defaults to diff.context or 3 if the configuration variable is unset. (-U without <n> is silently accepted as a synonym for -p due to a historical accident).

--inter-hunk-context=<n>

Visar sammanhanget mellan olika stycken, upp till det angivna <antal> rader, och sammanfogar drmed stycken som ligger nra varandra. Standardvrdet r diff.interHunkContext eller 0 om konfigurationsalternativet inte r instllt.

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

Ta ett befintligt <incheckning>-objekt och teranvnd loggmeddelandet och frfattarinformationen (inklusive tidsstmpeln) nr du skapar incheckningen.

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

Som -C, men med -c startas redigeraren s att anvndaren kan redigera incheckningsmeddelandet vidare.

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

Skapa en ny incheckning som "fixar upp" <incheckning> nr den tillmpas med git rebase --autosquash. Vanlig --fixup=<incheckning> skapar en "fixup!"-incheckning som ndrar innehllet i <incheckningen> men lmnar dess loggmeddelande orrt. --fixup=amend:<incheckning> r liknande men skapar en "amend!"-incheckning som ocks erstter loggmeddelandet fr <incheckning> med loggmeddelandet frn "amend!"-incheckningen. --fixup=reword:<incheckning> skapar en "amend!"-incheckning som erstter loggmeddelandet fr <incheckning> med sitt eget loggmeddelande men gr inga ndringar i innehllet i <incheckning>.

Den incheckning som skapas av --fixup=<incheckning> har en titel som bestr av "fixup!" fljt av titeln <incheckning>, och knns igen srskilt av git rebase --autosquash. Alternativet -m kan anvndas fr att komplettera loggmeddelandet fr den skapade incheckningen, men den ytterligare kommentaren frsvinner nr "fixup!"-incheckningen klms in i <incheckning> av git rebase --autosquash.

Den incheckning som skapas av --fixup=amend:<incheckning> liknar den ovan, men dess titel har i stllet prefixet "amend!". Loggmeddelandet fr <incheckning> kopieras till loggmeddelandet fr "amend!"-incheckningen och ppnas i en redigerare s att det kan frfinas. Nr git rebase --autosquash slr ihop "amend!"-incheckningen med <incheckning> erstts loggmeddelandet fr <incheckning> av det frfinade loggmeddelandet frn "amend!"-incheckningen. Det r ett fel om "amend!"-incheckningens loggmeddelande r tomt, om inte --allow-empty-message anges.

--fixup=reword:<incheckning> r en frkortning fr --fixup=amend:<incheckning> --only. Den skapar en "amend!"-incheckning med endast ett loggmeddelande (ignorerar eventuella ndringar som kats i indexet). Nr den komprimeras av git rebase --autosquash erstter den loggmeddelandet fr <incheckning> utan att gra ngra andra ndringar.

Varken "fixup!" eller "amend!" bekrftar ndring av frfattarskap fr <incheckning> nr det tillmpas av git rebase --autosquash. Se git-rebase[1] fr detaljer.

--squash=<incheckning>

Konstruera ett incheckningsmeddelande fr anvndning med git rebase --autosquash. Rubriken fr incheckningsmeddelandet hmtas frn den angivna incheckningen med prefixet "squash! ". Kan anvndas med ytterligare alternativ fr incheckningsmeddelande (-m/-c/-C/-F). Se git-rebase[1] fr detaljer.

--reset-author

Nr det anvnds med -C/-c/--amend-flaggor, eller vid incheckning efter ett motstridigt urval av attribut, deklareras att frfattarskapet till den resulterande incheckningen nu tillhr incheckaren. Detta frnyar ocks frfattartidsstmpeln.

--short

Nr du gr en testkrning, ange utdata i short-format. Se git-status[1] fr detaljer. Implicerar --dry-run.

--branch

Visa gren- och sprningsinformation ven i kortformat. Se git-status[1] fr mer information.

--porcelain

Nr du gr en torrkrning, ge utdata i ett porcelain-anpassat format. Se git-status[1] fr detaljer. Implicerar --dry-run.

--long

Nr du gr en testkrning, ange utdata i lngt format. Detta r standardutdata fr git-status[1]. Implicerar --dry-run.

-z
--null

Nr short- eller porcelain-utdata frn git-status[1] visas, skriv ut filnamnet ordagrant och avsluta posterna med NUL, i stllet fr LF. Om inget format anges innebr detta utdataformatet --porcelain. Utan -z-alternativet citeras filnamn med "ovanliga" tecken enligt beskrivningen fr konfigurationsvariabeln core.quotePath (se git-config[1]).

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

Hmta incheckningsmeddelandet frn <fil>. Anvnd - fr att lsa meddelandet frn standardindata.

--author=<frfattare>

sidostt incheckningsfrfattaren. Ange en explicit frfattare med standardformatet A U Thor <frfattare@example.com>. Annars antas <frfattare> vara ett mnster och anvnds fr att ska efter en befintlig incheckning av den frfattaren (d.v.s. git rev-list --all -i --author=<frfattare>); incheckningsfrfattaren kopieras sedan frn den frsta hittade incheckningen.

--date=<datum>

sidostt frfattardatumet som anvndes i incheckningen.

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

Anvnd <medd> som incheckningsmeddelande. Om flera -m-alternativ anges, sammanfogas deras vrden som separata stycken.

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

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

Nr du redigerar incheckningsmeddelandet, starta redigeraren med innehllet i <fil>. Konfigurationsvariabeln commit.template anvnds ofta fr att ge denna mjlighet implicit till kommandot. Denna mekanism kan anvndas av projekt som vill vgleda deltagarna med ngra tips om vad de ska skriva i meddelandet och i vilken ordning. Om anvndaren avslutar redigeraren utan att redigera meddelandet avbryts incheckningen. Detta har ingen effekt nr ett meddelande ges p annat stt, t.ex. med alternativen -m eller -F.

-s
--signoff
--no-signoff

Lgg till en Signed-off-by i slutet av incheckningsloggmeddelandet. Betydelsen av en signering beror p det projekt som bidrag lmnas till. Det kan till exempel intyga att incheckaren har rtt att skicka in arbetet under projektets licens eller godknner ngon bidragsgivares representation, till exempel ett Developer Certificate of Origin. (Se https://developercertificate.org fr det som anvnds av Linuxkrnan och Git-projekten.) Konsultera dokumentationen eller ledningen fr det aktuella projektet fr att frst hur signering anvnds dr.

Alternativet --no-signoff kan anvndas fr att upphva ett tidigare --signoff-alternativ p kommandoraden.

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

--trailer <token>[(=|:)<vrde>]

Ange ett (<token>, <vrde>)-par som ska anvndas 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 lgga till slutraden Signed-off-by och slutraden Helped-by i incheckningsmeddelandet.) Konfigurationsvariablerna trailer.* (git-interpret-trailers[1]) kan anvndas fr att definiera om en duplicerad trailer utelmnas, 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 trd som dess enda verordnade incheckning, och kommandot hindrar dig frn att gra en sdan incheckning. Det hr alternativet kringgr skerheten och anvnds frmst av frmmande SCM-grnssnittsskript.

--allow-empty-message

Skapa en commit med ett tomt incheckningsmeddelande utan att anvnda lgnivkommandon som git-commit-tree[1]. Precis som --allow-empty r detta kommando frmst avsett fr anvndning av frmmande SCM-grnssnittsskript.

--cleanup=<lge>

Bestm 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 efterfljande tomma rader, efterfljande blanksteg, kommentarer och dlj p varandra fljande tomma rader.

whitespace

Samma som strip frutom att #kommentarer inte tas bort.

verbatim

ndra inte meddelandet alls.

scissors

Samma som blanktecken frutom att allt frn (och inklusive) raden nedanfr avkortas om meddelandet ska redigeras. "#" kan anpassas med core.commentChar.

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

Samma som strip om meddelandet ska redigeras. Annars whitespace.

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

-e
--edit

Lt anvndaren ytterligare redigera meddelandet som tagits frn <fil> med -F <fil>, kommandoraden med -m <meddelande> och frn <incheckning> med -C <incheckning>.

--no-edit

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

--amend

Erstt toppen av den aktuella grenen genom att skapa en ny incheckning. Det inspelade trdet frbereds som vanligt (inklusive effekten av alternativen -i och -o samt ett explicit skvgsmnster), och meddelandet frn den ursprungliga incheckningen anvnds som utgngspunkt, i stllet fr ett tomt meddelande, nr inget annat meddelande anges frn kommandoraden via alternativ som -m, -F, -c, etc. Den nya incheckningen har samma frldrar och frfattare som den aktuella (alternativet --reset-author kan motverka detta).

Det motsvarar ungefr:

	$ git reset --soft HEAD^
	$ ... gr ngot annat fr att f fram rtt trd ...
	$ git commit -c ORIG_HEAD

men kan anvndas fr att ndra en sammanslagningsincheckning.

Du br frst konsekvenserna av att skriva om historiken om du ndrar en incheckning som redan har publicerats. (Se avsnittet "TERSTLLA FRN UPSTRMSREBASE" i git-rebase[1].)

--no-post-rewrite

Hoppa ver kroken post-rewrite.

-i
--include

Innan du gr en incheckning frn det hittills kaded innehllet, ka ven innehllet i de skvgar som anges p kommandoraden. Detta r vanligtvis inte vad du vill om du inte slutfr en konfliktfylld sammanslagning.

-o
--only

Gr en incheckning genom att hmta det uppdaterade innehllet i arbetstrdet fr de skvgar som anges p kommandoraden, utan att ta hnsyn till innehll som r kade fr andra skvgar. Detta r standardlget fr git commit om ngra skvgar anges p kommandoraden, i vilket fall detta alternativ kan utelmnas. Om detta alternativ anges tillsammans med --amend behver inga skvgar anges, vilka kan anvndas fr att ndra den senaste incheckningen utan att checka in ndringar som redan har kats. Om de anvnds tillsammans med --allow-empty krvs inte heller ngra skvgar, och en tom incheckning kommer att skapas.

--pathspec-from-file=<fil>

Skicka skvgsmnster i <fil> i stllet fr kommandoradsargument. Om <fil> r exakt - anvnds standardindata. Skvgsmnsterposter separeras med LF eller CR/LF. Skvgsmnsterposter kan citeras enligt beskrivningen fr 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. Skvgsmnsterposter separeras med tecknet NUL och alla andra tecken tolkas bokstavligt (inklusive radbrytningar och citattecken).

-u[<lge>]
--untracked-files[=<lge>]

Visa osprade filer.

Parametern <mode> r valfri (standardinstllningen r all) och anvnds fr att ange hanteringen av osprade filer; nr -u inte anvnds r standardinstllningen normal, d.v.s. visar osprade filer och kataloger.

De mjliga alternativen r:

no

Visa inga osprade filer

normal

Visar osprade filer och kataloger

all

Visar ven enskilda filer i osprade kataloger.

Alla vanliga stavningar fr det booleska vrdet true tas som normal och false som no. Standardvrdet kan ndras med hjlp 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 lngst ner i incheckningsmeddelandemallen fr att hjlpa anvndaren att beskriva incheckningen genom att pminna 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 gnger, visa dessutom den enhetliga skillnaden mellan vad som skulle checkas in och arbetstrdet, d.v.s. de okade ndringarna av sprade filer.

-q
--quiet

Undertryck sammanfattnings-meddelande fr incheckningen.

--dry-run

Skapa inte en incheckning, utan visa en lista ver skvgar som ska checkas in, skvgar med lokala ndringar som kommer att lmnas oincheckade och skvgar som inte spras.

--status

Inkludera utdata frn git-status[1] i incheckningsmeddelandemallen nr en redigerare anvnds fr att frbereda incheckningsmeddelandet. Standardinstllningen r p, men kan anvndas fr att sidostta konfigurationsvariabeln commit.status.

--no-status

Inkludera inte utdata frn git-status[1] i incheckningsmeddelandemallen nr du anvnder en redigerare fr att frbereda standardincheckningsmeddelandet.

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

GPG-signera incheckning. <nyckel-id> r valfri och anvnds som standard fr incheckare-identiteten; om den anges mste den fstas vid alternativet utan mellanslag. --no-gpg-sign r anvndbar fr att negligera bde konfigurationsvariabeln commit.gpgSign och den tidigare --gpg-sign.

--

Tolka inte fler argument som alternativ.

<skvgsmnster>...

Nr <skvgsmnster> anges p kommandoraden, checka in innehllet i filerna som matchar skvgsmnster utan att registrera de ndringar som redan lagts till i indexet. Innehllet i dessa filer kas ocks fr nsta incheckning utver vad som har kats tidigare.

Fr mer information, se posten skvgsmnster i gitglossary[7].

EXEMPEL

Nr du checkar in ditt eget arbete lagras innehllet i modifierade filer i arbetstrdet tillflligt i en kyta som kallas "index" med git add. En fil kan terstllas, endast i indexet men inte i arbetstrdet, till lget i den senaste incheckningen med git restore --staged <fil>, vilket i praktiken ngrar git add och frhindrar att ndringarna i filen tas med i nsta incheckning. Efter att tillstndet som ska checkas in stegvis har byggts upp med dessa kommandon anvnds git commit (utan ngon skvgsparameter) fr att registrera det som hittills har kats. Detta r den mest grundlggande formen av kommandot. Ett exempel:

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

I stllet fr att ka filer efter varje enskild ndring kan du ange att git commit ska notera ndringarna i de filer vars innehll spras i ditt arbetstrd och gra motsvarande git add och git rm t dig. Det vill sga, det hr exemplet gr samma sak som det tidigare exemplet om det inte finns ngon annan ndring i ditt arbetstrd:

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

Kommandot git commit -a tittar frst p ditt arbetstrd, ser att du har ndrat hello.c och tagit bort goodbye.c, och utfr ndvndiga git add och git rm t dig.

Efter att ha kat ndringar i mnga filer kan du ndra ordningen som ndringarna registreras i genom att ge skvgar till git commit. Nr skvgar anges gr kommandot en incheckning som bara registrerar de ndringar som gjorts i de namngivna skvgarna:

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

Det hr skapar en incheckning som registrerar modifieringen till Makefile. ndringarna som kats fr hej.c och hej.h inkluderas inte i den resulterande incheckningen. Deras ndringar gr dock inte frlorade — de kas fortfarande och hlls bara tillbaka. Om du gr det efter ovanstende sekvens:

$ git commit

Denna andra incheckningen skulle registrera ndringarna av hej.c och hej.h som frvntat.

Efter att en sammanslagning (initierad av git merge eller git pull) har stoppats p grund av konflikter r rent sammanslagna skvgar redan kade fr incheckning, och skvgar med konflikt lmnas ej sammanslagna. Du behver frst kontrollera vilka skvgar som r i konflikt med git status och, efter att ha tgrdat dem manuellt i arbetstrdet, ka resultatet som vanligt med git add:

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

Efter att konflikter har lsts och resultatet kats, kommer git ls-files -u att sluta nmna den konfliktfyllda skvgen. Nr du r klar, kr git commit fr att slutligen registrera sammanslagningen:

$ git commit

Precis som i fallet med att registrera dina egna ndringar kan du anvnda alternativet -a fr att spara skrivning. En skillnad r att under en sammanslagningslsning kan du inte anvnda git commit med skvgar fr att ndra ordningen som ndringarna checkas in, eftersom sammanslagningen ska registreras som en enda incheckning. Kommandot vgrar faktiskt att kras nr det ges skvgar (men se alternativet -i).

INCHECKNINGS INFORMATION

Information om frfattare och incheckare hmtas frn fljande miljvariabler, om de r instllda:

  • GIT_AUTHOR_NAME

  • GIT_AUTHOR_EMAIL

  • GIT_AUTHOR_DATE

  • GIT_COMMITTER_NAME

  • GIT_COMMITTER_EMAIL

  • GIT_COMMITTER_DATE

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

Frfattar- och incheckare-namnen r enligt konvention ngon form av ett personnamn (det vill sga det namn som andra mnniskor refererar till dig med), ven om Git inte tillmpar eller krver ngon srskild form. Godtycklig Unicode kan anvndas, med frbehll fr de begrnsningar som anges ovan. Detta namn har ingen effekt p autentisering; fr detta, se variabeln credential.username i git-config[1].

Om (ngra av) dessa miljvariabler inte r angivna, hmtas informationen frn konfigurationsalternativen user.name och user.email, eller, om de inte finns, miljvariabeln EMAIL, eller, om den inte r angiven, systemanvndarnamnet och vrdnamnet som anvnds fr utgende e-post (hmtat frn /etc/mailname och anvnder det fullstndiga kvalificerade vrdnamnet nr den filen inte finns).

author.name och committer.name och deras motsvarande e-postalternativ sidostter user.name och user.email om de r instllda och sidostts sjlva av miljvariablerna.

Den typiska anvndningen r att bara ange variablerna user.name och user.email; de andra alternativen finns fr mer komplexa anvndningsfall.

DATUMFORMAT

Miljvariablerna GIT_AUTHOR_DATE och GIT_COMMITTER_DATE stder fljande datumformat:

Git internt format

Det r <unix-timestamp> <time-zone-offset>, dr <unix-timestamp> r antalet sekunder sedan UNIX-epoken. <time-zone-offset> r en positiv eller negativ frskjutning frn UTC. Till exempel r CET (som r 1 timme fre 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 i stllet fr tecknet T. Brkdelar 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 fljande format: .MM.DD, MM/DD/ och DD.MM..

Frutom att knna igen alla datumformat ovan, kommer alternativet --date ocks att frska frst andra, mer mnniskocentrerade datumformat, ssom relativa datum som "yesterday" (igr) eller "yesterday" (frra fredagen vid middagstid).

DISKUSSION

ven om det inte r ett krav r det en bra id att brja incheckningsmeddelandet med en enda kort rad (hgst 50 tecken) som sammanfattar ndringen, fljt av en tom rad och sedan en mer utfrlig beskrivning. Texten fram till den frsta tomma raden i ett incheckningsmeddelande behandlas som incheckningstiteln, och den titeln anvnds i hela Git. Till exempel, git-format-patch[1] omvandlar en incheckning till ett e-postmeddelande, och den anvnder titeln p mnesraden och resten av incheckningsmeddelandet i brdtexten.

Git r till viss del teckenkodningsagnostisk.

  • Innehllet i blob-objekten r otolkade sekvenser av byte. Det finns ingen kodningsversttning p krnniv.

  • Skvgsnamn r kodade i UTF-8-normaliseringsform C. Detta gller trdobjekt, indexfilen, referensnamn, svl som skvgsnamn i kommandoradsargument, miljvariabler och konfigurationsfiler (.git/config (se git-config[1]), gitignore[5], gitattributes[5] och gitmodules[5]).

    Observera att Git p krnniv behandlar skvgsnamn helt enkelt som sekvenser av icke-NUL-byte, det finns inga konverteringar av skvgskodning (frutom p Mac och Windows). Drfr fungerar anvndning av skvgsnamn som inte r ASCII-namn oftast ven p plattformar och filsystem som anvnder ldre utkade ASCII-kodningar. Kodfrrd som skapas p sdana system kommer dock inte att fungera korrekt p UTF-8-baserade system (t.ex. Linux, Mac, Windows) och vice versa. Dessutom antar mnga Git-baserade verktyg helt enkelt att skvgsnamn r UTF-8 och kommer inte att kunna visa andra kodningar korrekt.

  • Meddelanden i commitloggar kodas vanligtvis i UTF-8, men andra utkade ASCII-kodningar stds ocks. Detta inkluderar ISO-8859-x, CP125x och mnga 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 bde krnan och anvndarkommandona (porcelain) i Git utformade fr att inte tvinga fram UTF-8 i projekt. Om alla deltagare i ett visst projekt tycker att det r bekvmare att anvnda ldre kodningar, frbjuder inte Git det. Det finns dock ngra saker att tnka p.

  1. git commit och git commit-tree utfrdar en varning om incheckningsloggmeddelandet som ges till det inte ser ut som en giltig UTF-8-strng, svida du inte uttryckligen anger att ditt projekt anvnder en ldre kodning. Sttet att sga detta r att ha i18n.commitEncoding i .git/config-filen, s hr:

    [i18n]
	commitEncoding = ISO-8859-1

    Incheckningsobjekt som skapats med ovanstende instllning registrerar vrdet fr i18n.commitEncoding i sin encoding-header. Detta r fr att hjlpa andra som tittar p dem senare. Avsaknaden av denna header innebr att incheckningsloggmeddelandet r kodat i UTF-8.

  2. git log, git show, git blame och vnner tittar p encoding-headern fr ett incheckningsobjekt och frsker koda om loggmeddelandet till UTF-8 om inget annat anges. Du kan ange nskad utdatakodning med i18n.logOutputEncoding i .git/config-filen, s hr:

    [i18n]
	logOutputEncoding = ISO-8859-1

    Om du inte har den hr konfigurationsvariabeln anvnds vrdet fr i18n.commitEncoding i stllet.

Observera att vi medvetet valde att inte koda om incheckningsloggmeddelandet nr en incheckning grs fr att tvinga fram UTF-8 p incheckningsobjektniv, eftersom omkodning till UTF-8 inte ndvndigtvis r en reversibel operation.

MILJ- OCH KONFIGURATIONSVARIABLER

Redigeraren som anvnds fr att redigera incheckningsloggmeddelandet kommer att vljas frn miljvariabeln GIT_EDITOR, konfigurationsvariabeln core.editor, miljvariabeln VISUAL eller miljvariabeln EDITOR (i den ordningen). Se git-var[1] fr mer information.

Allt ovanfr den hr raden i det hr avsnittet finns inte med i dokumentationen fr git-config[1]. Innehllet som fljer r detsamma som det som finns dr:

commit.cleanup

Den hr instllningen sidostter standardinstllningen fr --cleanup-alternativet i git commit. Att ndra standardinstllningen kan vara anvndbart nr du alltid vill behlla rader som brjar med kommentartecknet (core.commentChar, standard #) i ditt loggmeddelande, i vilket fall du skulle gra git config commit.cleanup whitespace (observera att du sjlv mste ta bort hjlpraderna som brjar med kommentartecknet i incheckning-loggmallen om du gr detta).

commit.gpgSign

En boolesk kod som anger om alla incheckningar ska GPG-signeras. Anvndning av det hr alternativet vid operationer som ombasering kan resultera i att ett stort antal incheckningar signeras. Det kan vara praktiskt att anvnda en agent fr att undvika att skriva in din GPG-lsenfras flera gnger.

commit.status

Ett booleskt vrde fr att aktivera/inaktivera inkludering av statusinformation i incheckningsmeddelandemallen nr en redigerare anvnds fr att frbereda incheckningsmeddelandet. Standardvrdet r true.

commit.template

Ange skvgen till en fil som ska anvndas som mall fr nya incheckningsmeddelanden.

commit.verbose

Ett booleskt vrde eller ett heltal fr att ange utfrlighetsnivn med git commit.

KROKAR

Det hr kommandot kan kra hakarna commit-msg, prepare-commit-msg, pre-commit, post-commit och post-rewrite. Se githooks[5] fr mer information.

FILER

$GIT_DIR/COMMIT_EDITMSG

Den hr filen innehller incheckningsmeddelandet fr en pgende incheckning. Om git commit avslutas p grund av ett fel innan en incheckning skapas, kommer alla incheckningsmeddelanden som har tillhandahllits av anvndaren (t.ex. i en redigeringssession) att finnas tillgngliga i den hr filen, men kommer att skrivas ver av nsta anrop av git commit.

SE VEN

git-add[1], git-rm[1], git-mv[1], git-merge[1], git-commit-tree[1]

GIT

En del av git[1]-sviten

About this site
Patches, suggestions, and comments are welcome.
Git is a member of Software Freedom Conservancy
Web Proxy Viewer  |  New URL  |  Original Page