Setup and Config

• git
• config
• help
• bugreport
• Credential helpers

Getting and Creating Projects

• init
• clone

Basic Snapshotting

• add
• status
• diff
• commit
• notes
• restore
• reset
• rm
• mv

Branching and Merging

• branch
• checkout
• switch
• merge
• mergetool
• log
• stash
• tag
• worktree

Sharing and Updating Projects

• fetch
• pull
• push
• remote
• submodule

Inspection and Comparison

• show
• log
• diff
• difftool
• range-diff
• shortlog
• describe

Patching

• apply
• cherry-pick
• diff
• rebase
• revert

Debugging

• bisect
• blame
• grep

Email

• am
• apply
• imap-send
• format-patch
• send-email
• request-pull

External Systems

• svn
• fast-import

Server Admin

• daemon
• update-server-info

Guides

• gitattributes
• Command-line interface conventions
• Everyday Git
• Frequently Asked Questions (FAQ)
• Glossary
• Hooks
• gitignore
• gitmodules
• Revisions
• Submodules
• Tutorial
• Workflows
• All guides...

Administration

• clean
• gc
• fsck
• reflog
• filter-branch
• instaweb
• archive
• bundle

Plumbing Commands

• cat-file
• check-ignore
• checkout-index
• commit-tree
• count-objects
• diff-index
• for-each-ref
• hash-object
• ls-files
• ls-tree
• merge-base
• read-tree
• rev-list
• rev-parse
• show-ref
• symbolic-ref
• update-index
• update-ref
• verify-pack
• write-tree

git-commit-tree - Skapa ett nytt incheckningsobjekt

git commit-tree <träd> [(-p <förälder>)…​]
git commit-tree [(-p <parent>)…​] [-S[<keyid>]] [(-m <meddelande>)…​]
		 [(-F <fil>)…​] <träd>

Det är vanligtvis inte vad en slutanvändare vill köra direkt. Se git-commit[1] i stället.

Skapar ett nytt incheckningsobjekt baserat på det angivna trädobjektet och genererar det nya incheckningsobjekt- id:t vid stdout. Loggmeddelandet läses från standardindata, såvida inte alternativen -m eller -F anges.

Alternativen -m och -F kan anges hur många gånger som helst, i valfri ordning. Meddelandet i incheckningsloggen kommer att skrivas i den ordning alternativen anges.

Ett incheckningsobjekt kan ha ett valfritt antal föräldrar. Med exakt en förälder är det en vanlig incheckning. Att ha mer än en förälder gör incheckningen till en sammanslagning mellan flera historiklinjer. Initiala (rot-) incheckningar har inga föräldrar.

Medan ett träd representerar ett visst katalogtillstånd i en arbetskatalog, representerar en incheckning det tillståndet i "tid" och förklarar hur man kommer dit.

Normalt sett skulle en incheckning identifiera ett nytt "HEAD"-tillstånd, och även om Git inte bryr sig om var du sparar anteckningen om det tillståndet, tenderar vi i praktiken att bara skriva resultatet till filen som .git/HEAD pekar på, så att vi alltid kan se vad det senaste incheckade tillståndet var.

<träd>

Ett befintligt trädobjekt.

-p <förälder>

Varje -p anger id:t för ett överordnat incheckningsobjekt.

-m <meddelande>

Ett stycke i incheckningsloggmeddelandet. Detta kan ges mer än en gång och varje <meddelande> blir ett eget stycke.

-F <fil>

Läs incheckningsloggmeddelandet från den givna filen. Använd - för att läsa från standardindata. Detta kan anges mer än en gång och innehållet i varje fil blir ett eget stycke.

-S[<nyckeld>]

--gpg-sign[=<nyckelid>]

--no-gpg-sign

GPG-signera incheckningar. Argumentet keyid är valfritt och används som standard för committer-identiteten; om det anges måste det fästas vid alternativet utan mellanslag. --no-gpg-sign är användbart för att ångra ett --gpg-sign-alternativ som angetts tidigare på kommandoraden.

En incheckning inkapslar:

• alla överordnade objekt-id:n

• författarnamn, e-postadress och datum

• namn och e-postadress för incheckaren och incheckningstid.

En incheckningskommentar läses från stdin. Om en ändringsloggpost inte anges via omdirigering med "<", kommer git commit-tree bara att vänta på att en ska anges och avslutas med ^D.

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月07日T22:13:13. Parsern accepterar även ett mellanslag i stället för tecknet T. Bråkdelar av en sekund kommer att ignoreras, till exempel 2005年04月07日T22:13:13.019 kommer att behandlas som 2005年04月07日T22:13:13.

Note

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

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. Kodförråd 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.

/etc/mailname

git-write-tree[1] git-commit[1]

En del av git[1]-sviten