Per-Arne's Git Good!Ordliste
Begrepene kurset bruker, i den rekkefølgen kurset innfører dem. Git-navnet står i parentes der kurset bruker et norsk ord. Kommandoer står i kommandoreferansen.
| Begrep | Betydning | Innført i |
|---|---|---|
| repository | Databasen med hele historikken, alle objekter og refs, i mappen .git, som regel sammen med en arbeidsmappe. Et bare repository har ingen arbeidsmappe. |
Hva er Git? Snapshots og din første commit |
| commit | Et lagret øyeblikksbilde av prosjektet med forfatter, tidspunkt, melding og forelder. En commit endres aldri; å «endre» en commit betyr å lage en ny. | Hva er Git? Snapshots og din første commit |
| snapshot (øyeblikksbilde) | Den fullstendige tilstanden til alle sporede filer i en commit, ikke bare forskjellen fra forrige. Uendrede filer lagres ikke på nytt, men gjenbrukes. | Hva er Git? Snapshots og din første commit |
| forelder (parent) | Commiten en commit bygger på. Den første commiten har ingen, en vanlig commit har én og en merge-commit to eller flere. Kjeden av foreldre er historikken. HEAD~1 og HEAD^ er første forelder til HEAD. |
Hva er Git? Snapshots og din første commit |
| arbeidsmappen (working tree) | Filene du ser og redigerer på disk. Endringer her blir ikke en del av historikken før de er staget og committet. | Tre områder: arbeidsmappen, staging-området og HEAD |
| staging-området (index) | Utkastet til neste commit: den versjonen av hver sporet fil som neste commit vil lagre. git add kopierer filens nåværende versjon hit; senere endringer må stages på nytt. |
Tre områder: arbeidsmappen, staging-området og HEAD |
| sporet / usporet fil (tracked / untracked) | En sporet fil finnes i staging-området, og dermed i neste commit. En usporet fil finnes bare i arbeidsmappen; Git har ingen kopi av det den inneholder nå, før du kjører git add. |
Tre områder: arbeidsmappen, staging-området og HEAD |
| HEAD | Det du står på: som regel en peker til gjeldende branch, som igjen peker på en commit. Neste commit får HEAD-commiten som forelder. | Tre områder: arbeidsmappen, staging-området og HEAD |
| .gitignore | En fil med mønstre for usporede filer Git skal overse, som byggfiler, logger og filer med hemmeligheter, før de noen gang er committet. Den påvirker ikke filer som allerede er sporet, og fjerner ingenting som allerede er committet. | Gode commits: små, bevisste og godt beskrevne |
| commit-ID (hash) | Navnet på en commit: en hash (som standard 40 heksadesimale tegn, ofte vist forkortet) beregnet av snapshot, foreldre, forfatter, tidspunkt og melding. Endres noe av dette, blir det en annen commit med ny ID. | Les historikken: log, show og objektene bak |
| branch | Et flyttbart navn som peker på én commit, ikke en kopi av filene. Når du committer på branchen, flytter den seg til den nye commiten. | Brancher og HEAD: pekere, ikke kopier |
| detached HEAD | HEAD peker direkte på en commit i stedet for på en branch, for eksempel etter git switch --detach. Commits du lager her, har ingen branch; gi dem en med git switch -c før du bytter bort. |
Brancher og HEAD: pekere, ikke kopier |
| merge | Å integrere en annen branch i den du står på med git merge. Resultatet er en fast-forward eller en ny merge-commit. |
Fast-forward: når merge bare flytter en peker |
| fast-forward | En merge der branchen du står på, er forfar til den andre, så Git bare flytter pekeren fram. Ingen ny commit lages. --no-ff tvinger fram en merge-commit. |
Fast-forward: når merge bare flytter en peker |
| merge-commit | En commit med mer enn én forelder, vanligvis to, som forener to utviklingslinjer. Når HEAD er en merge-commit, er HEAD^1 commiten du stod på og HEAD^2 tuppen du merget inn. |
Treveis merge: når begge linjene har flyttet seg |
| merge-base (merge base) | Den beste felles forfaren til to commits, vanligvis der linjene skilte lag. En treveis merge sammenligner begge sider med den. Finnes med git merge-base. |
Treveis merge: når begge linjene har flyttet seg |
| konflikt (conflict) | Git stopper fordi den ikke kan forene de to sidene selv, typisk fordi begge har endret de samme eller tilstøtende linjene siden merge-basen. Du bestemmer innholdet, fjerner markørene, kjører git add og fullfører, eller avbryter med git merge --abort. |
Konflikter uten panikk |
| tag (lightweight / annotated) | Et fast navn på én commit, typisk en utgivelse; den flytter seg ikke når du committer. En lightweight tag er bare navnet. En annotated tag (git tag -a) er et eget objekt med hvem som tagget, dato og melding, og passer for utgivelser. |
Tagger: faste navn på viktige versjoner |
| remote | Et annet repository, vanligvis med beslektet historikk, som du henter fra og publiserer til. Lagres som et kortnavn med en adresse; se dem med git remote -v. |
Remotes og clone: tre ting som heter main |
| origin | Navnet git clone gir remoten du klonet fra. Et lokalt kallenavn for adressen, ikke selve serveren. |
Remotes og clone: tre ting som heter main |
| clone | git clone kopierer et repository med hele historikken, kaller kilden origin, lager remote-tracking-brancher og sjekker ut standardbranchen. |
Remotes og clone: tre ting som heter main |
| remote-tracking-branch (remote-tracking ref) | Ditt lokale minne om hvor en branch i remoten stod sist du var i kontakt med den, for eksempel origin/main. Den flyttes av fetch, pull og push, aldri av at andre pusher, og du committer ikke på den. |
Remotes og clone: tre ting som heter main |
| upstream | Branchen en lokal branch følger, som regel en remote-tracking-branch, for eksempel origin/main for main. git pull og git push bruker den som standard, og git status teller foran og bak mot den. Settes med git push -u eller git branch -u. |
Remotes og clone: tre ting som heter main |
| fetch | git fetch laster ned nye commits fra remoten og flytter remote-tracking-branchene. Branchene dine, staging-området og arbeidsmappen står urørt. |
Fetch, pull og push: hold deg i takt med teamet |
| pull | git pull er fetch og deretter integrasjon av upstream i branchen du står på: med merge (--no-rebase), rebase (--rebase) eller bare fast-forward (--ff-only). |
Fetch, pull og push: hold deg i takt med teamet |
| push | git push sender commits til remoten og flytter branchen der. Godtas bare som fast-forward; ellers avvises den, og du må hente og integrere først. Tvungen push overskriver andres commits. |
Fetch, pull og push: hold deg i takt med teamet |
--force-with-lease |
Et valg til git push som bare overskriver remote-branchen hvis den fortsatt står der remote-tracking-branchen din sier. Etter en fetch stemmer den likevel, så den passer bare for din egen omskrevne branch, aldri for en delt. |
Fetch, pull og push: hold deg i takt med teamet |
| pull request | En funksjon i en hostingtjeneste som GitHub, ikke i Git: en forespørsel om review og merge av en publisert branch inn i en annen. GitLab kaller det merge request. | Teamarbeid: feature-brancher, pull requests og avtaler |
| restore | git restore FIL kopierer filen fra staging-området til arbeidsmappen. Med --staged kopieres HEAD-versjonen til staging-området, og med --source en versjon fra en annen commit. Ingen branch flyttes. |
Angre i filene: git restore |
reset (--soft / --mixed / --hard) |
git reset COMMIT flytter branchen du står på til en annen commit. --soft beholder staging-området og arbeidsmappen, --mixed (standard) tilbakestiller staging-området, og --hard tilbakestiller også arbeidsmappen og kaster ucommittede endringer i sporede filer. |
Flytt branchen tilbake: git reset |
| revert | git revert COMMIT lager en ny commit som opphever endringen i en tidligere commit. Ingen historikk skrives om, så den passer på delt historikk. |
Angre delt historikk: git revert |
| rebase | git rebase spiller commitene dine av på nytt oppå en ny base. Kopiene får nye ID-er, og branchen peker ikke lenger på originalene. Bare for commits ingen andre har. |
Rebase: spill arbeidet av på en ny base |
| ORIG_HEAD | En ref som reset, merge og rebase setter til der HEAD stod før operasjonen. git diff ORIG_HEAD HEAD viser hva operasjonen endret, og git reset --hard ORIG_HEAD flytter branchen tilbake dit, men kaster ucommittede endringer. |
Rebase: spill arbeidet av på en ny base |
| interaktiv rebase (interactive rebase) | git rebase -i lar deg redigere planen før commitene spilles av: endre rekkefølge, reword, squash, fixup eller drop. Brukes til å rydde privat historikk før du deler den. |
Interaktiv rebase: rydd før du deler |
| reflog | En lokal logg over hvor HEAD og hver branch har pekt, for eksempel HEAD@{1}. Med den finner du commits som ingen branch lenger peker på. Oppføringene utløper (som standard etter 30 eller 90 dager) og følger ikke med i clone eller push, så reflogen er ingen backup. |
Reflog: redd arbeid som ser tapt ut |
| stash | En lokal hylle der git stash push legger ucommittede endringer i sporede filer til side, så de sporede filene blir like siste commit; usporede filer bare med -u. git stash pop legger dem inn igjen og fjerner oppføringen hvis det gikk uten konflikt, git stash apply beholder den. |
Stash: legg uferdig arbeid til side |
| cherry-pick | git cherry-pick COMMIT kopierer endringen fra én commit over på branchen du står på, som en ny commit med ny ID. -x skriver den opprinnelige ID-en inn i meldingen. |
Cherry-pick: kopier én commit |
| bisect | git bisect binærsøker mellom en kjent god og en kjent dårlig commit for å finne den første dårlige, enten ved at du svarer good eller bad, eller automatisk med git bisect run. |
Feiljakt: log -S, blame og bisect |
| blame | git blame FIL viser for hver linje hvilken commit som sist endret den, med forfatter og dato. Svaret sier hvor linjen sist ble endret, ikke hvem som har skylden for en feil. |
Feiljakt: log -S, blame og bisect |
| worktree | En ekstra arbeidsmappe knyttet til det samme repositoryet (git worktree add), slik at to brancher kan være sjekket ut samtidig. Git nekter å sjekke ut den samme branchen i to worktrees. |
Worktrees og større prosjekter |
| hook | Et skript Git kjører ved en hendelse, for eksempel pre-commit eller pre-push. Hooks ligger lokalt i .git/hooks, blir ikke klonet og kan hoppes over, så regler teamet må kunne stole på, håndheves på serveren. |
Worktrees og større prosjekter |