{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/version-control","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/version-control/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/version-control/"},"term":{"en":"Version control","da":"Versionsstyring"},"aka":{"en":["source control","revision control"],"da":["versionskontrol"]},"domain":["platform"],"cluster":"delivery","layer":"delivery","status":"current","era":1972,"summary":{"en":"A system that keeps every saved version of a set of files, with who changed what and when, so work can be compared or rolled back.","da":"Et system, der gemmer hver version af en samling filer, og hvem der ændrede hvad hvornår, så man kan sammenligne eller rulle tilbage."},"body":{"formal":{"en":"A store that records each change to a set of files as a numbered or named step with its author, time and reason, lets several people work in separate branches, and joins their work back together.","da":"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."},"plain":{"en":"Like the full edit history of a shared document, where you can see every earlier draft, who wrote each line, and go back to last Tuesday's copy with one click.","da":"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."},"inPractice":{"en":"An operations engineer at a pension fund changes a firewall setting in a file and asks a colleague to review it before it is merged; months later the fund's IT auditor can see exactly who approved the change and why.","da":"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."},"whyItMatters":{"en":"Without a trusted history, nobody can prove what was running at a given time or quickly undo a bad change, and both are basic needs for security and audits.","da":"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."}},"deepDive":{"en":"Version control developed in generations. SCCS (Marc Rochkind, Bell Labs, 1972) and RCS (Walter Tichy, 1982) versioned single files with locking; CVS (from 1986) and Subversion (2000) introduced a central server holding the history of whole projects, with atomic commits arriving in Subversion. Distributed systems - BitKeeper, then Git (created by Linus Torvalds in April 2005 after the Linux kernel lost its free BitKeeper licence) and Mercurial (also 2005) - give every clone the full history, making commits, branches and merges local operations. Git is now the de facto standard, hosted on platforms such as GitHub, GitLab, Bitbucket and Azure DevOps that add pull requests, reviews and access control on top.\n\nGit's core is a content-addressed object store. A blob holds file content, a tree maps names and modes to blobs and subtrees, a commit points to one tree, zero or more parent commits, author and committer identities with timestamps, and a message; an annotated tag points to an object with its own metadata. Each object's ID is the hash of its content, historically SHA-1 (hardened with collision detection after the 2017 SHAttered collision), with a SHA-256 object format available since Git 2.29 but still little used because of interoperability limits. Because every commit hashes its parents, history forms a Merkle DAG: altering an old commit changes every descendant ID, which makes tampering evident to anyone holding the previous IDs. Branches and tags are merely named refs; merging uses a three-way merge against the common ancestor, while rebasing rewrites commits and therefore their IDs.\n\nThe hash chain proves integrity, not authorship: the author and committer fields are free text anyone can set. Signed commits and tags (OpenPGP, SSH keys since Git 2.34, or X.509 and Sigstore's gitsign) bind a commit to a key, and hosting platforms can require verified signatures on protected branches. Other controls are branch protection with required reviews and status checks, disabled force-pushes, CODEOWNERS files routing changes to accountable reviewers, and MFA or hardware keys for accounts with write access. NIST SSDF practice PS.1 asks producers to protect all forms of code from unauthorised access and tampering, and SLSA's Source track sets levels for such guarantees.\n\nA frequent failure mode is committed secrets: deleting a file in a new commit leaves the credential in history and in every clone and fork, so the credential must be rotated, and history rewriting (git filter-repo) is only a secondary clean-up. Version control differs from backup, which restores state but carries no reviewed change history, and from GitOps, which uses a repository as the operational source of truth rather than just a record of change.","da":"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å.\n\nKernen 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.\n\nHashkæ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.\n\nEn 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."},"edges":[{"type":"part-of","to":"platform/software-supply-chain","confidence":"high","strength":"normal"}],"depth":0,"sources":[{"title":"Pro Git - Getting Started, About Version Control","url":"https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control","tier":"official-doc","publisher":"Git project"},{"title":"NIST SP 800-218 - Secure Software Development Framework (SSDF)","url":"https://csrc.nist.gov/pubs/sp/800/218/final","tier":"standard","publisher":"NIST"}],"draft":true}