Gå til indhold
atlas

Versionsstyring

Også kendt som: versionskontrol

Et system, der gemmer hver version af en samling filer, og hvem der ændrede hvad hvornår, så man kan sammenligne eller rulle tilbage.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

Et lager, der registrerer hver ændring i en samling filer som et nummereret eller navngivet trin med forfatter, tidspunkt og begrundelse, lader flere arbejde i hver sin gren og fletter arbejdet sammen igen.

Forklaret enkelt

Som den fulde liste over rettelser i et delt dokument, hvor man kan se alle tidligere udkast, hvem der skrev hver linje, og hente tirsdagens udgave frem med ét klik.

I praksis

En driftsmedarbejder i en pensionskasse ændrer en firewall-indstilling i en fil og beder en kollega gennemgå den, før den flettes ind; måneder senere kan pensionskassens IT-revisor se præcis, hvem der godkendte ændringen og hvorfor.

Hvorfor det betyder noget

Uden et pålideligt spor af ændringerne kan ingen bevise, hvad der kørte på et givet tidspunkt, eller hurtigt fortryde en dårlig ændring, og begge dele er grundkrav for sikkerhed og revision.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. Hold al kode, pipelinedefinitioner, infrastrukturkode og konfiguration i Git-repositories på en hostingplatform, jeres organisation har kontrol over, med en navngiven ejer for hvert repository.
  2. Kræv MFA eller hardwarenøgler for alle konti med skriveadgang, og giv kun skriveadgang til dem, der har brug for den.
  3. Beskyt hovedgrenen - kræv pull requests med gennemgang og grønne statustjek, og bloker force-push og sletning, også for administratorer.
  4. Tilføj en CODEOWNERS-fil, så ændringer i følsomme dele sendes til ansvarlige reviewere.
  5. Kræv signerede commits på beskyttede grene (SSH, OpenPGP eller Sigstores gitsign), og signér hvert udgivelsestag.
  6. Slå secret scanning med push protection til, og kommer en hemmelighed alligevel ind, så udskift den først og rens historikken bagefter.
  7. Arbejd i kortlivede grene, der flettes ofte, og tag hver udgivelse, så I altid kan vise, hvad der kørte.
  8. Tjek repositoriernes indstillinger jævnligt med værktøjer som OpenSSF Scorecard eller Allstar, og tag backup af repositories uden for hostingplatformen.

Typiske faldgruber

  • At stole på forfatternavnet på et commit, som enhver kan sætte, i stedet for en verificeret signatur.
  • At lade administratorer kunne omgå grenbeskyttelsen, så reglen om gennemgang har en stille bagdør.
  • At fjerne en committet adgangskode i et nyt commit uden at udskifte den.
  • At betragte hostingplatformen som backup af jeres kildekode.

Gode vejledninger

Teknisk uddybning

Versionsstyring har udviklet sig i generationer. SCCS (Marc Rochkind, Bell Labs, 1972) og RCS (Walter Tichy, 1982) versionerede enkeltfiler med låsning; CVS (fra 1986) og Subversion (2000) indførte en central server med historikken for hele projekter, og med Subversion kom atomiske commits. Distribuerede systemer - BitKeeper, siden Git (skabt af Linus Torvalds i april 2005, efter at Linux-kernen havde mistet sin gratis BitKeeper-licens) og Mercurial (også 2005) - giver hver klon den fulde historik, så commits, grene og fletninger bliver lokale operationer. Git er i dag de facto-standarden, hostet på platforme som GitHub, GitLab, Bitbucket og Azure DevOps, der lægger pull requests, gennemgange og adgangskontrol ovenpå.

Kernen i Git er et indholdsadresseret objektlager. En blob rummer filindhold, et tree kobler navne og tilstande til blobs og undertræer, et commit peger på ét tree, nul eller flere forældre-commits, identiteter for author og committer med tidsstempler samt en besked; et annoteret tag peger på et objekt med egne metadata. Hvert objekts ID er hashen af dets indhold, historisk SHA-1 (hærdet med kollisionsdetektion efter SHAttered-kollisionen i 2017), og et SHA-256-objektformat har været tilgængeligt siden Git 2.29, men bruges stadig kun lidt på grund af begrænset interoperabilitet. Fordi hvert commit hasher sine forældre, danner historikken en Merkle-DAG: ændres et gammelt commit, ændres ID'et for alle efterkommere, så manipulation bliver synlig for alle, der kender de tidligere ID'er. Grene og tags er blot navngivne refs; fletning bruger en trevejsfletning mod den fælles forfader, mens rebase omskriver commits og dermed deres ID'er.

Hashkæden beviser integritet, ikke forfatterskab: felterne author og committer er fritekst, som enhver kan sætte. Signerede commits og tags (OpenPGP, SSH-nøgler siden Git 2.34 eller X.509 og Sigstores gitsign) binder et commit til en nøgle, og hostingplatforme kan kræve verificerede signaturer på beskyttede grene. Andre kontroller er grenbeskyttelse med krævede gennemgange og statustjek, forbud mod force-push, CODEOWNERS-filer, der sender ændringer til ansvarlige reviewere, og MFA eller hardwarenøgler for konti med skriveadgang. NIST SSDF-praksis PS.1 beder producenter beskytte alle former for kode mod uautoriseret adgang og manipulation, og SLSA's Source-spor fastlægger niveauer for sådanne garantier.

En hyppig fejl er committede hemmeligheder: sletter man filen i et nyt commit, ligger legitimationsoplysningen stadig i historikken og i alle kloner og forks, så den skal udskiftes, og omskrivning af historikken (git filter-repo) er kun en sekundær oprydning. Versionsstyring adskiller sig fra backup, der gendanner en tilstand, men ikke rummer en gennemgået ændringshistorik, og fra GitOps, der bruger et repository som den operationelle sandhedskilde og ikke blot som et register over ændringer.

Relationer

Kilder og videre læsning

Standarder og officielle tekster

Officiel dokumentation

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.