Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
-
2.54.0
2026-04-20
-
2.53.0
2026-02-02
- 2.51.1 → 2.52.0 no changes
-
2.51.0
2025-08-18
- 2.48.1 → 2.50.1 no changes
-
2.48.0
2025-01-10
- 2.46.1 → 2.47.3 no changes
-
2.46.0
2024-07-29
- 2.44.1 → 2.45.4 no changes
-
2.44.0
2024-02-23
- 2.43.2 → 2.43.7 no changes
-
2.43.1
2024-02-09
-
2.43.0
2023-11-20
- 2.39.1 → 2.42.4 no changes
-
2.39.0
2022-12-12
- 2.36.1 → 2.38.5 no changes
-
2.36.0
2022-04-18
- 2.33.1 → 2.35.8 no changes
-
2.33.0
2021-08-16
- 2.30.1 → 2.32.7 no changes
-
2.30.0
2020-12-27
- 2.23.1 → 2.29.3 no changes
-
2.23.0
2019-08-16
- 2.22.1 → 2.22.5 no changes
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 no changes
-
2.21.0
2019-02-24
- 2.19.1 → 2.20.5 no changes
-
2.19.0
2018-09-10
- 2.18.1 → 2.18.5 no changes
-
2.18.0
2018-06-21
- 2.15.4 → 2.17.6 no changes
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
-
2.12.5
2017-09-22
- 2.9.5 → 2.11.4 no changes
-
2.8.6
2017-07-30
-
2.7.6
2017-07-30
-
2.6.7
2017-05-05
- 2.5.6 no changes
-
2.4.12
2017-05-05
- 2.3.10 no changes
-
2.2.3
2015-09-04
- 2.1.4 no changes
-
2.0.5
2014-12-17
BESKRIVNING
- alternativ objektdatabas
-
Via alternativmekanismen kan ett kodförråd ärva en del av sin objektdatabas från en annan objektdatabas, vilket kallas ett "alternativ".
- bart kodförråd
-
Ett "bart kodförråd" är normalt en lämpligt namngiven katalog med suffixet
.gitsom inte har någon lokalt utcheckad kopia av filerna under revisionskontroll. Det vill säga: alla Git-administrations- och kontrollfiler som normalt finns i den dolda underkatalogen.gitfinns i stället direkt i katalogenrepository.git, och inga andra filer finns eller är utcheckade. Utgivare av publika kodförråd tillhandahåller vanligtvis sådana bara kodförråd. - blob objekt
-
Otypat objekt, t.ex. innehållet i en fil.
- gren
-
En "gren" är en utvecklingslinje. Den senaste incheckning på en gren kallas för toppen av den grenen. Grenens topp refereras av en gren huvud, som rör sig framåt allt eftersom ytterligare utveckling görs på grenen. Ett enda Git-kodförråd kan spåra ett godtyckligt antal grenar, men ditt arbetsträd är associerat med bara en av dem (den "nuvarande" eller "utcheckade" grenen), och HEAD pekar på den grenen.
- cache
-
Föråldrad för: index.
- kedja
-
En lista med objekt, där varje objekt i listan innehåller en referens till dess efterföljare (till exempel kan efterföljaren till en incheckning vara en av dess föräldrar).
- ändringsset
-
BitKeeper/cvsps använder termen "incheckning". Eftersom Git inte lagrar ändringar, utan tillstånd, är det egentligen inte meningsfullt att använda termen "ändringsuppsättningar" med Git.
- utcheckning
-
Åtgärden att uppdatera hela eller delar av arbetsträd med ett trädobjekt eller blob från objektdatabas, och uppdatera index och HEAD om hela arbetsträdet har pekats mot en ny gren.
- cherry-picking
-
I SCM-jargong betyder "cherry pick" att välja en delmängd ändringar ur en serie ändringar (vanligtvis incheckningar) och registrera dem som en ny serie ändringar ovanpå en annan kodbas. I Git utförs detta med kommandot "git cherry-pick" för att extrahera ändringen som introducerats av en befintlig incheckning och registrera den på toppen av den aktuella grenen som en ny incheckning.
- ren
-
Ett arbetsträd är rent om det motsvarar revision som refereras av det aktuella head. Se även "smutsig".
- incheckning
-
Som substantiv: En enskild punkt i Git-historiken; hela projektets historik representeras som en uppsättning sammanhängande incheckning. Ordet "incheckning" används ofta av Git på samma ställen som andra revisionskontrollsystem använder orden "revision" eller "version". Används även som en förkortning för incheckning objekt.
- incheckning-grafkoncept, representationer och användning
-
En synonym för strukturen DAG som bildas av incheckningar i objektdatabasen, refererad av gren toppen, med hjälp av deras kedja av länkade incheckningar. Denna struktur är den definitiva incheckningsgrafen. Grafen kan representeras på andra sätt, t.ex. "commit-graph"-filen.
- incheckningsgraffil
-
Filen "commit-graph" (normalt med bindestreck) är en kompletterande representation av incheckningsgraf som accelererar grafvandringar i incheckningshistoriken. Filen "commit-graph" lagras antingen i katalogen .git/objects/info eller i info-katalogen i en alternativ objektdatabas.
- inchecknings objekt
-
Ett objekt som innehåller information om en specifik revision, såsom föräldrar, incheckare, författtare, datum och trädobjekt> som motsvarar den översta <<def_directory,katalog för den lagrade revisionen.
- incheckningslik (även commit-ish)
-
Ett incheckningsobjekt eller ett objekt som rekursivt kan avreferera till ett incheckningsobjekt. Följande är alla incheckningslika: ett incheckningsobjekt, ett taggobjekt som pekar på ett incheckningsobjekt, ett taggobjekt som pekar på ett taggobjekt som pekar på ett incheckningsobjekt, etc.
- core Git
-
Grundläggande datastrukturer och verktyg i Git. Erbjuder endast begränsade verktyg för källkodshantering.
- DAG
-
Riktad acyklisk graf. incheckningsobjekten bildar en riktad acyklisk graf, eftersom de har föräldrar (riktade), och grafen för incheckningsobjekt är acyklisk (det finns ingen kedja som börjar och slutar med samma objekt).
- dinglande objekt
-
Ett onåbart objekt som inte är nåbart ens från andra oåtkomliga objekt; ett dinglande objekt har inga referenser till sig från någon referens eller objekt i kodförråd.
- avreferera
-
Att hänvisa till en symbolisk ref: åtgärden att komma åt referens som pekas på av en symbolisk referens. Rekursiv avreferering innebär att upprepa den ovannämnda processen på den resulterande referensen tills en icke-symbolisk referens hittas.
Refererar till ett tag-objekt: åtgärden att komma åt objekt som en tagg pekar på. Taggar avrefereras rekursivt genom att upprepa operationen på resultatobjektet tills resultatet har antingen en angiven objekt-typ (där så är tillämpligt) eller någon annan objekttyp än "tag". En synonym för "rekursiv avreferering" i samband med taggar är "skala".
Refererar till ett incheckningsobjekt: åtgärden att komma åt incheckningens trädobjekt. Incheckningar kan inte avrefereras rekursivt.
Om inget annat anges är "avreferering", så som det används i Git-kommandon eller protokoll, underförstått rekursiv.
- frikopplad HEAD
-
Normalt lagrar HEAD namnet på en grenen, och kommandon som arbetar på historiken som HEAD representerar arbetar på historiken som leder till toppen av grenen som HEAD pekar på. Git tillåter dig dock också att checka ut en godtycklig incheckning som inte nödvändigtvis är toppen av någon specifik gren. HEAD-kommandot i ett sådant tillstånd kallas "frånkopplat".
Observera att kommandon som använder historiken för den aktuella grenen (t.ex.
gitcommitför att bygga en ny historik ovanpå den) fortfarande fungerar medan HEAD är frånkopplad. De uppdaterar HEAD så att den pekar på toppen av den uppdaterade historiken utan att påverka någon gren. Kommandon som uppdaterar eller frågar efter information om den aktuella grenen (t.ex.gitbranch--set-upstream-tosom anger vilken fjärrspårad gren den aktuella grenen integrerar med) fungerar uppenbarligen inte, eftersom det inte finns någon (riktig) aktuell gren att fråga om i detta tillstånd. - katalog
-
Listan du får med "ls" :-)
- smutsig
-
Ett arbetsträd sägs vara "smutsigt" om det innehåller modifieringar som inte har incheckats till det aktuella grenen.
- ond sammanslagning
-
En ond sammanslagning är en sammanslagning som introducerar ändringar som inte visas i någon förälder.
- snabbspola
-
En snabbspolning är en särskild typ av sammanfogning där du har en revision och "sammanfogar" ändringar från en annan gren som råkar vara en efterföljare till din egen. I ett sådant fall skapas ingen ny sammanfogning incheckning; i stället uppdateras grenen så att den pekar på samma revision som grenen du sammanfogar. Detta sker ofta på en fjärrspårad gren i ett fjärr-kodförråd.
- hämta
-
Att hämta en gren innebär att hämta grenens huvudref från ett fjärr-kodförråd, ta reda på vilka objekt som saknas i den lokala objektdatabasen och hämta dem också. Se även git-fetch[1].
- filsystem
-
Linus Torvalds designade ursprungligen Git som ett filsystem för användarrymden, d.v.s. infrastrukturen för att lagra filer och kataloger. Det säkerställde effektivitet och hastighen för Git.
- Git arkiv
-
Synonym för kodförråd (för ärkepersoner).
- gitfil
-
En vanlig fil
.gitvid roten av ett arbetsträd som pekar på katalogen som är det verkliga kodförrådet. För korrekt användning, se git-worktree[1] eller git-submodule[1]. För syntax, se gitrepository-layout[5]. - Ympningar
-
Ympningar gör det möjligt att sammanfoga två annars olika utvecklingslinjer genom att registrera falsk anfaderinformation för incheckningar. På så sätt kan du få Git att låtsas att uppsättningen föräldrar som en incheckning har skiljer sig från vad som registrerades när incheckningen skapades. Konfigureras via filen
.git/info/grafts.Observera att ympnings-mekanismen är föråldrad och kan leda till problem med att överföra objekt mellan arkiv; se git-replace[1] för ett mer flexibelt och robust system som gör samma sak.
- hash
-
I Gits kontext, synonym för objektnamn.
- huvud
-
En namngiven referens till incheckning i toppen av en gren. Heads lagras i en fil i katalogen
$GIT_DIR/refs/heads/, förutom när packade referenser används. (Se git-pack-refs[1].) - HEAD
-
Den aktuella grenen. Mer detaljerat: Ditt arbetsträd härleds normalt från trädets tillstånd som HEAD refererar till. HEAD är en referens till en av heads i ditt kodförråd, förutom när du använder en frikopplad HEAD, i vilket fall den direkt refererar till en godtycklig incheckning.
- huvud ref
-
En synonym för huvud.
- krok
-
Under normal körning av flera Git-kommandon görs anrop till valfria skript som låter en utvecklare lägga till funktionalitet eller kontroller. Vanligtvis gör krokar det möjligt att förkontrollera och vid behov avbryta ett kommando, samt att skicka en notis efter att operationen är klar. Krokskripten finns i katalogen
$GIT_DIR/hooks/och aktiveras genom att suffixet.sampletas bort från filnamnet. I äldre versioner av Git behövde de göras körbara. - index
-
En samling filer med statistikinformation, vars innehåll lagras som objekt. Indexet är en lagrad version av ditt arbetsträd. Sanningen att säga kan det också innehålla en andra, och till och med en tredje version av ett arbetsträd, som används vid sammanslagning.
- index post
-
Informationen om en viss fil, lagrad i index. En indexpost kan vara osammanslagen om en sammanslagning har påbörjats men ännu inte avslutats (d.v.s. om indexet innehåller flera versioner av den filen).
- master
-
Standardutvecklingen gren. När du skapar en Git kodförråd skapas en gren med namnet "master" som blir den aktiva grenen. I de flesta fall innehåller denna den lokala utvecklingen, men det är helt enligt konvention och inte obligatoriskt.
- sammanslagning
-
Som verb: Att ta in innehållet från en annan gren (möjligen från ett externt kodförråd) i den aktuella grenen. När den sammanfogade grenen kommer från ett annat kodförråd görs detta genom att först hämta fjärrgrenen och därefter sammanfoga resultatet med den aktuella grenen. Kombinationen av hämtnings- och sammanfogningsoperationer kallas hämtning. Sammanfogning utförs av en automatisk process som identifierar ändringar sedan grenarna divergerade och tillämpar dem tillsammans. När ändringar står i konflikt kan manuell hantering krävas för att slutföra sammanfogningen.
Som substantiv: om det inte är en snabbspolning resulterar en lyckad sammanslagning i en ny incheckning som representerar sammanslagningsresultatet och som har topparna på de sammanslagna grenarna som föräldrar. Denna incheckning kallas en "merge commit" eller helt enkelt en "merge".
- objekt
-
Lagringsenheten i Git. Den identifieras unikt av SHA-1 för dess innehåll. Följaktligen kan ett objekt inte ändras.
- objektdatabas
-
Lagrar en uppsättning "objekt", och ett enskilt objekt identifieras med dess objektnamn. Objekten finns vanligtvis i
$GIT_DIR/objects/. - objekt identifierare, objekt ID, oid
-
Synonymer för objektnamn.
- objektnamn
-
Den unika identifieraren för ett objekt. Objektnamnet representeras vanligtvis av en hexadecimal sträng på 40 tecken. Även i dagligt tal kallad SHA-1.
- objekttyp
-
En av identifierarna "incheckning", "träd", "tag" eller "blob" som beskriver typen av ett objekt.
- bläckfisk
- föräldralös
-
Handlingen att gå över till en gren som ännu inte finns (d.v.s. en ofödd gren). Efter en sådan operation blir den första skapade incheckningen en incheckning utan förälder, vilket startar en ny historik.
- ursprung (origin)
-
Standardprojektet uppströms kodförråd. De flesta projekt har minst ett uppströmsprojekt som de spårar. Som standard används origin för detta ändamål. Nya uppströmsuppdateringar hämtas till fjärrspårade grenar med namnet origin/name-of-upstream-branch, vilket du kan se med hjälp av
gitbranch-r. - överlägg
-
Uppdatera och lägg bara till filer i arbetskatalogen, men ta inte bort dem, ungefär som när
cp-Ruppdaterar innehållet i målkatalogen. Detta är standardläget i en utcheckning när filer checkas ut från index eller en trädliknande referens. I kontrast tar no-overlay-läget även bort spårade filer som saknas i källan, ungefär somrsync--delete. - pack
-
En uppsättning objekt som har komprimerats till en fil (för att spara utrymme eller för att överföra dem effektivt).
- pack index
-
Listan med identifierare och annan information om objekten i ett pack, för att underlätta effektiv åtkomst till innehållet i ett pack.
- sökvägsmönster
-
Mönster som används för att begränsa sökvägar i Git-kommandon.
Sökvägsmönster används på kommandoraden för "git ls-files", "git ls-tree", "git add", "git grep", "git diff", "git checkout" och många andra kommandon för att begränsa operationernas omfattning till en delmängd av trädet eller arbetsträd. Se dokumentationen för varje kommando för att se om sökvägarna är relativa till den aktuella katalogen eller toppnivån. Syntaxen för sökvägsmönster är följande:
-
varje sökväg matchar sig själv
-
Sökvägsmönstern fram till sista snedstrecket representerar ett katalogprefix. Omfattningen av den sökvägsmönstret är begränsad till det underträdet.
-
resten av sökvägsmönstret är ett mönster för resten av sökvägsnamnet. Sökvägar relativa till katalogprefixet matchas mot det mönstret med hjälp av fnmatch(3); i synnerhet matchar * och ? kan katalogavgränsare.
Till exempel, kommer Documentation/*.jpg att matcha alla .jpg-filer i underträdet Dokumentation, inklusive Documentation/kapitel_1/figur_1.jpg.
En sökvägsmönster som börjar med ett kolon
:har en speciell betydelse. I den korta formen följs det inledande kolonet:av noll eller fler "uttrycks signatur"-bokstäver (som valfritt avslutas med ett annat kolon:), och resten är mönstret som matchar sökvägen. Den "magiska signaturen" består av ASCII-symboler som varken är alfanumeriska, glob-, regex-specialtecken eller kolon. Det valfria kolonet som avslutar den "uttrycks signaturen" kan utelämnas om mönstret börjar med ett tecken som inte tillhör symboluppsättningen "uttrycks signatur" och inte är ett kolon.I den långa formen följs det inledande kolonet
:av en öppen parentes (, en kommaseparerad lista med noll eller fler "uttrycks ord" och en avslutande parentes ), och resten är mönstret som ska matchas mot sökvägen.En sökvägsmönster med endast ett kolon betyder "det finns ingen sökvägsmönster". Denna form bör inte kombineras med andra sökvägsmönster.
- top
-
Det utrycks-ordet
top(utryck signatur:/) gör att mönstret matchar från roten av arbetsträdet, även när du kör kommandot inifrån en underkatalog. - bokstavlig
-
Jokertecken i mönstret, såsom
*eller ?, behandlas som teckenlekter. - icase
-
Skiftlägeskänslig matchning.
- glob
-
Git behandlar mönstret som en skal-glob lämplig för konsumtion av fnmatch(3) med flaggan FNM_PATHNAME: jokertecken i mönstret kommer inte att matcha en / i sökvägen. Till exempel matchar "Documentation/*.html" "Documentation/git.html" men inte "Documentation/ppc/ppc.html" eller "tools/perf/Documentation/perf.html".
Två asterisker i rad ("
**") i mönster som matchar det fullständiga sökvägsnamnet kan ha en speciell betydelse:-
Ett inledande "
**" följt av ett snedstreck betyder matchning i alla kataloger. Till exempel matchar "**/foo" filen eller katalogen "foo" var som helst. "**/foo/bar" matchar filen eller katalogen "bar" var som helst som ligger direkt under katalogen "foo". -
Ett efterföljande "
/**" matchar allt inuti. Till exempel matchar "abc/**" alla filer i katalogen "abc", relativt till platsen för.gitignore-filen, med oändligt djup. -
Ett snedstreck följt av två asterisker i rad, sedan ett snedstreck, matchar noll eller fler kataloger. Till exempel matchar "
a/**/b" "a/b", "a/x/b", "a/x/y/b" och så vidare. -
Andra efterföljande asterisker anses ogiltiga.
Glob-uttryck är oförenlig med bokstavliga uttryck.
-
- attr
-
Efter
attr:kommer en mellanslagsseparerad lista med "attributkrav", som alla måste vara uppfyllda för att sökvägen ska betraktas som en matchning; detta är utöver den vanliga icke-uttrycks sökvägsmönster-mönster-matchningen. Se gitattributes[5].Varje attributkrav för sökvägen har en av dessa former:
-
"
ATTR" kräver att attributetATTRär angivet. -
"
-ATTR" kräver att attributetATTRinte är angivet. -
"
ATTR=VALUE" kräver att attributetATTRsätts till strängenVALUE. -
"
!ATTR" kräver att attributetATTRinte är specificerat.Observera att vid matchning mot ett trädobjekt hämtas attribut fortfarande från arbetsträdet, inte från det givna trädobjektet.
-
- uteslut
-
Efter att en sökväg matchar en icke-exkluderad sökvägsmönster, kommer den att köras genom alla exkluderade sökvägsmönster(uttrycks -signatur:
!eller dess synonym^). Om den matchar, ignoreras sökvägen. När det inte finns någon icke-exkluderad sökvägsmönster, tillämpas exkluderingen på resultatmängden som om den anropades utan någon sökvägsmönster.
-
- förälder
-
Ett incheckningsobjekt innehåller en (möjligen tom) lista över den/de logiska föregångaren/föregångarna i utvecklingslinjen, d.v.s. dess föräldrar.
- peel (skala)
-
Åtgärden att rekursivt avreferera ett tag-objekt.
- hacka
-
Termen hacka hänvisar till ett alternativ till diffcore-rutinerna som hjälper till att välja ändringar som lägger till eller tar bort en given textsträng. Med alternativet
--pickaxe-allkan det användas för att visa hela ändringsset som införde eller tog bort, till exempel, en viss textrad. Se git-diff[1]. - rörmokeri
-
Sött namn för kärnan av Git.
- porslin
-
Smeknamn för program och programpaket som bygger på core Git och ger högnivååtkomst till core Git. Högnivåkommandon exponerar mer av ett SCM-gränssnitt än lågnivåkommandon.
- per-arbetsträdsreferens
-
Referenser som är per-arbetsträd, snarare än globala. Detta är för närvarande endast HEAD och alla referenser som börjar med
refs/bisect/, men kan senare inkludera andra ovanliga referenser. - pseudoref
-
En referens som har annan semantik än vanliga referenser. Dessa referenser kan läsas via vanliga Git-kommandon, men kan inte skrivas till med kommandon som git-update-ref[1].
Följande pseudorefs är kända för Git:
-
FETCH_HEADskrivs av git-fetch[1] eller git-pull[1]. Det kan referera till flera objekt-ID:n. Varje objekt-ID är annoterat med metadata som anger var det hämtades ifrån och dess hämtningsstatus. -
MERGE_HEADskrivs av git-merge[1] när det gäller att lösa sammanslagningskonflikter. Den innehåller alla incheckning-ID:n som sammanfogas.
-
- dra in ("hämta")
-
Att dra in ("hämta") en gren innebär att hämta den och sammanslå den. Se även git-pull[1].
- sänd ("skicka")
-
Att skicka en gren innebär att hämta grenens huvudref från ett fjärr-kodförråd, avgöra om den är en förfader till grenens lokala huvudreferens och, om så är fallet, lägga till alla objekt som är nåbara från den lokala huvudreferensen men saknas i fjärrkodförrådet till fjärrens objektdatabas, samt uppdatera fjärrens huvudreferens. Om fjärrens huvud inte är en förfader till det lokala huvudvärdet misslyckas skickningen.
- nåbar
-
Alla förfäder till en given incheckning sägs vara "nåbara" från den incheckningen. Mer generellt är en objekt nåbar från en annan om vi kan nå den från den andra via en kedja som följer tags till vad de än taggar, incheckningar till deras föräldrar eller träd, och träd till de träd eller blobs som de innehåller.
- nåbarhetsbitmappar
-
Nåbarhetsbitmappar lagrar information om nåbarhet för en vald uppsättning incheckningar i en packfil, eller ett multipackindex (MIDX), för att snabba upp objektsökningen. Bitmapparna lagras i en ".bitmap"-fil. Ett arkiv får ha högst en bitmappsfil i bruk. Bitmappsfilen kan tillhöra antingen ett paket eller arkivets multipackindex (om det finns).
- ombasering ("rebase")
-
För att återanvända en serie ändringar från en gren till en annan bas, och återställa huvudet för den grenen till resultatet.
- ref
-
Ett namn som pekar på en objektnamn eller en annan referens (den senare kallas en symbolisk ref). För enkelhetens skull kan en referens ibland förkortas när den används som ett argument till ett Git-kommando; se gitrevisions[7] för mer information. Referenser lagras i kodförråd.
Ref-namnrymden är hierarkisk. Ref-namn måste antingen börja med
refs/eller finnas i roten av hierarkin. För de senare måste deras namn följa dessa regler:-
Namnet består endast av versaler eller understreck.
-
Namnet slutar med "
_HEAD" eller är lika med "HEAD".Det finns några oregelbundna referenser i hierarkin som inte överensstämmer med dessa regler. Följande lista är uttömmande och kommer inte att utökas i framtiden:
-
AUTO_MERGE -
BISECT_EXPECTED_REV -
NOTES_MERGE_PARTIAL -
NOTES_MERGE_REF -
MERGE_AUTOSTASHOlika underhierarkier används för olika ändamål. Till exempel används hierarkin
refs/heads/för att representera lokala grenar medan hierarkinrefs/tags/används för att representera lokala taggar.
-
- reflogg
-
En reflogg visar den lokala "historiken" för en referens. Med andra ord kan den berätta vad den tredje senaste revisionen i detta kodförråd var, och vad det aktuella läget var i detta kodförråd, igår klockan 21:14. Se git-reflog[1] för mer information.
- referensspecifikation
-
En "refspec" används av hämta ("hämta") och sänd ("skicka") för att beskriva mappningen mellan fjärren ref och lokal referens. Se git-fetch[1] eller git-push[1] för detaljer.
- fjärrkodförråd
-
Ett kodförråd som används för att spåra samma projekt men finns någon annanstans. För att kommunicera med fjärr, se hämta eller sänd.
- fjärrspårad gren
-
En ref som används för att följa ändringar från ett annat kodförråd. Den ser vanligtvis ut som refs/remotes/foo/bar (vilket betyder att den spårar en gren med namnet bar i en fjärr med namnet foo) och matchar högersidan av en konfigurerad refspec för hämtning. En fjärrspårad gren bör inte innehålla direkta ändringar eller lokala incheckningar.
- kodförråd
-
En samling referenser tillsammans med en objektdatabas som innehåller alla objekt som är nåbara från referenserna, eventuellt kompletterad med metadata från en eller flera porcelain-kommandon. Ett kodförråd kan dela objektdatabas med andra kodförråd via alternativmekanismen.
- resolve
-
Åtgärden att manuellt fixa det som en misslyckad automatisk sammanslagning lämnade efter sig.
- revision
-
Synonym för incheckning (substantivet).
- återspolning ("rewind")
-
Att kasta bort en del av utvecklingen, d.v.s. att tilldela huvud till en tidigare revision.
- SCM
-
Källkodshantering (verktyg).
- SHA-1
-
"Säker hashalgoritm 1"; en kryptografisk hashfunktion. I Git-sammanhang används den som en synonym för objektnamn.
- ytlig klon
-
Mestadels en synonym till ytligt kodförråd men frasen gör det mer explicit att den skapades genom att köra kommandot
gitclone--depth=.... - ytligt kodförråd
-
Ett ytligt kodförråd har en ofullständig historik varav en del incheckning har föräldrar bränts bort (med andra ord, Git får höra att låtsas att dessa incheckningar inte har föräldrarna, trots att de är registrerade i incheckning objekt). Detta är ibland användbart när man bara är intresserad av ett projekts aktuella historik trots att den verkliga historiken som registrerats uppströms är mycket större. Ett ytligt kodförråd skapas genom att ge
--depth-alternativet till git-clone[1], och dess historik kan senare fördjupas med git-fetch[1]. - gömma post
-
En object som används för att tillfälligt lagra innehållet i en smutsig arbetskatalog och indexet för framtida återanvändning.
- undermodul ("submodule")
-
Ett kodförråd som lagrar historiken för ett separat projekt inuti ett annat kodförråd (det senare kallas superproject).
- superproject
-
Ett kodförråd som refererar till kodförråd för andra projekt i sin arbetsträd som undermoduler. Superprojektet känner till namnen på (men innehåller inte kopior av) incheckningsobjekt för de ingående undermodulerna.
- symref
-
Symbolisk referens: i stället för att innehålla själva SHA-1-id:t är den på formatet ref: refs/some/thing och när den refereras avrefereras den till denna referens. HEAD är ett utmärkt exempel på en symref. Symboliska referenser manipuleras med kommandot git-symbolic-ref[1].
- tag
-
En ref under namnrymden
refs/tags/som pekar på ett objekt av en godtycklig typ (vanligtvis pekar en tagg på antingen ett tag eller ett incheckningsobjekt). Till skillnad från en huvud uppdateras inte en tagg avcommit-kommandot. En Git-tagg har ingenting att göra med en Lisp-tagg (som skulle kallas en objekttyp i Gits kontext). En tagg används oftast för att markera en viss punkt i commit-anor kedja. - tag objekt
-
Ett objekt som innehåller ett ref som pekar på ett annat objekt, vilket kan innehålla ett meddelande precis som ett incheckningsobjekt. Det kan också innehålla en (PGP) signatur, i vilket fall det kallas ett "signerat taggobjekt".
- ämnes-gren
-
En vanlig Git gren som används av en utvecklare för att identifiera en konceptuell utvecklingslinje. Eftersom grenar är mycket enkla och billiga är det ofta önskvärt att ha flera små grenar som var och en innehåller mycket väldefinierade koncept eller små stegvisa men relaterade förändringar.
- slutrader
-
Nyckel-värde-metadata. Slutrader finns valfritt i slutet av ett incheckningsmeddelande. Kan kallas "fötter" ("footers") eller "taggar" (tags) i andra gemenskaper. Se git-interpret-trailers[1].
- träd
-
Antingen ett arbetsträd, eller ett trädobjekt tillsammans med det beroende blob och trädobjekten (d.v.s. en lagrad representation av ett arbetsträd).
- trädobjekt
-
Ett objekt som innehåller en lista med filnamn och lägen tillsammans med referenser till tillhörande blob- och/eller trädobjekt. Ett träd motsvarar ett katalog.
- trädlikt (även treeish)
-
Ett trädobjekt eller ett objekt som rekursivt kan avrefereras till ett trädobjekt. Att avreferera ett incheckningsobjekt ger trädobjektet som motsvarar revisionens översta katalog. Följande är alla trädliknande: ett incheckningsliknande, ett trädobjekt, ett taggobjekt som pekar på ett trädobjekt, ett taggobjekt som pekar på ett taggobjekt som pekar på ett trädobjekt, osv.
- ofött
-
HEAD kan peka på en gren som ännu inte existerar och som inte har någon incheckning på ännu, och en sådan gren kallas en ofödd gren. Det vanligaste sättet användare stöter på en ofödd gren är genom att skapa ett nytt kodförråd utan att klona någon annanstans. HEAD skulle peka på main-grenen (eller master-grenen, beroende på din konfiguration) som ännu inte har skapats. Vissa operationer kan också ge dig en ofödd gren med deras orphan (föräldralös) alternativ.
- unmerged index
-
En index som innehåller ej sammanslagna index-poster.
- oåtkomligt objekt
-
Ett objekt som inte är nåbart från en gren, tag eller någon annan referens.
- uppströms-gren
-
Standard gren som sammanslå med grenen i fråga (eller som grenen i fråga baseras på). Den konfigureras via branch.<namn>.remote och branch.<namn>.merge. Om uppströmsgrenen av A är origin/B säger vi ibland att "A spårar origin/B".
- arbetsträd
-
Trädet med faktiska utcheckade filer. Arbetskatalogen innehåller normalt innehållet i incheckningskatalogen för HEAD, plus eventuella lokala ändringar som du har gjort men ännu inte checkat in.
- arbetsträd
-
Ett kodförråd kan ha noll (d.v.s. ett bart kodförråd) eller ett eller flera arbetsträd kopplade till sig. Ett "arbetsträd" består av ett "working tree" och metadata för kodförrådet, där det mesta delas med andra arbetsträd i samma kodförråd, medan en del underhålls separat per arbetsträd (t.ex. index, HEAD och pseudoreferenser som MERGE_HEAD, referenser per arbetsträd och konfigurationsfil per arbetsträd).
GIT
En del av git[1]-sviten