Forside · Gennemgået oktober 2026 · Af John Nielsen
Git-historikken ser præcis ud: hver ændring har en forfatter, et tidspunkt og en kryptografisk identifikator. Men navn, e-mail og tidspunkter i en commit er oplysninger, som brugeren selv angiver, og Git kontrollerer dem ikke. Bevisværdien ligger derfor i sammenhængen mellem commit-objekterne og i spor uden for dem: platformens logs, byggeservere, andre udvikleres kopier og filsystemet.
Git-historikken er ofte central i tvister om IT-projekter, om ophavsret til kode og om medarbejdere, der har taget kode med til en ny arbejdsgiver. Metoderne til at sammenligne to kodebaser og til at holde commits op mod timeregistrering står i Kodelighed og Timeregistrering mod commits og tickets. I en projekttvist indgår historikken typisk i en bevaringsplan for projektet og sammen med fejllister og fejlklassifikation. Artiklen gennemgår, hvad historikken teknisk kan og ikke kan vise.
Hvad en commit indeholder
En commit i Git er et objekt med:
- en henvisning til et træ, der beskriver filernes indhold på det tidspunkt,
- henvisninger til forrige commit (parent), eller flere ved en merge,
- author: navn, e-mail, tidspunkt og tidszone for den, der skrev ændringen,
- committer: navn, e-mail, tidspunkt og tidszone for den, der lavede selve commit’en,
- en besked og eventuelt en signatur.
Commit-id’et er en hashværdi af hele objektet. De fleste repositories bruger SHA-1. Git kan også oprette repositories med SHA-256 (objektformatet angives ved oprettelsen), men formatet er endnu ikke udbredt, og understøttelsen hos hostingplatformene er begrænset. Notér derfor objektformatet i sikringen. Fordi hver commit peger på sin forgænger, ændres alle efterfølgende id’er, hvis en tidligere commit ændres. Historikken kan derfor ikke ændres i det skjulte uden at alle senere id’er skifter. Det er en vigtig egenskab: Har en anden part eller et andet system registreret et commit-id på et tidspunkt, kan det vise, hvordan historikken så ud dengang. Om algoritmerne, se Hashalgoritmer i forensic.
Author date og committer date
- Author date · Sættes når: Ændringen første gang committes · Ændres ved: Bevares normalt ved rebase og cherry-pick
- Committer date · Sættes når: Commit’en oprettes eller genskabes · Ændres ved: Rebase, cherry-pick og amend
En commit med en gammel author date og en ny committer date er typisk omskrevet. Det er normalt i mange arbejdsgange, fx når en gren rebases før en merge. Men det betyder, at author date ikke viser, hvornår koden lå i den pågældende form i dette repository.
Begge tidspunkter kan sættes frit af brugeren, og navn og e-mail kommer fra brugerens egen konfiguration. Git kontrollerer hverken, at tidspunktet er korrekt, eller at navnet tilhører den person, der faktisk skrev koden. Et commit-tidspunkt er derfor en påstand fra den computer, commit’en blev lavet på, og tidszonen i feltet er den, computeren var indstillet til.
Ved analysen bør begge felter altid vises. Standardvisningen i mange værktøjer viser kun author date, og det kan give et misvisende billede af historikken.
Signerede commits
En commit kan signeres med GPG, SSH-nøgler eller X.509-certifikater. Signaturen kan efterprøves med Git selv eller med platformens visning.
En gyldig signatur viser, at commit’en er signeret med en bestemt privat nøgle, og at objektet ikke er ændret siden. Den viser ikke, hvornår signeringen skete, og den viser ikke, at nøglen var under en bestemt persons kontrol. Det skal underbygges på anden vis, fx ved at den offentlige nøgle er registreret på personens konto hos platformen, og hvornår den blev registreret.
Platforme som GitHub og GitLab viser en markering som Verified, når signaturen passer med en nøgle på brugerens konto. Markeringen afhænger af platformens regler og af nøglens status på visningstidspunktet, og den kan ændre sig, hvis nøglen senere fjernes. Gem derfor en dokumenteret visning sammen med sikringen.
Reflog: lokal historik over ændringer
Reflog registrerer lokalt, hvor grene og HEAD har peget hen over tid, også efter rebase, reset og sletning af grene. Den ligger i logs-mappen under .git.
- Reflog findes kun i det lokale repository og sendes ikke med ved push eller clone.
- Poster udløber som standard efter 90 dage, og efter 30 dage for commits, der ikke længere kan nås fra en gren (indstillingerne gc.reflogExpire og gc.reflogExpireUnreachable). Værdierne kan være ændret i konfigurationen og skal aflæses.
- På servere med bare repositories er reflog som standard ikke slået til.
Reflog kan vise, at historikken er omskrevet, hvornår det skete ifølge computerens ur, og hvilke commits der fandtes før. Commits, der ikke længere kan nås, ligger ofte stadig som objekter i repositoriet, indtil Git’s oprydning fjerner dem. Integritetskontrollen i Git kan finde dem.
Force push
Ved force push overskrives grenen på serveren med en ny historik. De gamle commits er ikke længere synlige i grenen, men de er sjældent helt væk:
- andre udvikleres lokale kopier har ofte den gamle historik,
- byggeservere og CI-systemer kan have hentet de gamle commits og gemt byggelogs med deres id’er,
- platformen kan registrere push-hændelser i aktivitets- eller auditlogs, afhængigt af platform og abonnement,
- pull requests kan bevare henvisninger til tidligere commits.
Platformens logs har begrænset opbevaring og bør sikres tidligt. Se Logfiler og logrotation.
Spor uden for commit’en
- Platformens push-log · Hvornår der blev pushet, og af hvilken konto
- Pull requests og kommentarer · Tidspunkter registreret af platformen
- CI-kørsler · Hvilken commit der blev bygget, og hvornår
- Filsystemet på udviklerens computer · Tidsstempler for filer og objekter i .git
- Backup af serveren · Historik før en omskrivning
Platformens tidsstempler er sat af platformen, ikke af brugeren, og vejer derfor tungere end commit-felterne. Når de to typer tidspunkter sammenholdes, bliver omskrivninger ofte tydelige. Se Tidslinjeanalyse.
Sikring
- Kopiér hele .git-mappen fra udviklerens computer, helst fra en forensisk kopi af disken. Kun her findes reflog og objekter, der ikke længere kan nås.
- Fra serveren: En mirror-clone henter alle referencer, men ikke reflog og uopnåelige objekter. Et Git-bundle med alle referencer giver én fil, der kan hashes og opbevares.
- Platformdata: Eksportér auditlogs, pull requests, brugere og registrerede nøgler, så længe de findes.
- Kør ingen oprydning, garbage collection eller andre kommandoer, der ændrer objektlageret, før sikringen er sket.
- Dokumentér Git-version, de udførte kommandoer, output og hashværdier.
Typiske fejl i fortolkningen
- Et navn i author-feltet sidestilles med en person, selvom flere udviklere kan have delt computer eller konfiguration.
- En author date tages som udtryk for, hvornår koden blev skrevet, selvom commit’en er omskrevet eller importeret fra et andet repository.
- Fravær af en commit på serveren tolkes som, at koden aldrig fandtes, selvom historikken kan være overskrevet ved force push.
- Tidszoner i commit-felterne ignoreres, så rækkefølgen mellem commits fra forskellige udviklere bliver forkert.
Sammenligning af kode
Spørgsmålet om, hvorvidt kode er kopieret, kræver mere end Git. Ens hashværdier for filer viser identitet, men omdøbte variabler, ændret formatering eller ny struktur kræver analyse af lighed, fx sammenligning af token-sekvenser eller strukturer. Resultatet er et mål for lighed, ikke et bevis for kopiering, og det skal vurderes mod, hvor meget lighed der må forventes af kode, der løser samme opgave i samme sprog og med samme biblioteker. Den bredere sammenhæng er beskrevet i Tvister om IT-projekter og Forretningshemmeligheder, og den juridiske side i Ophavsret til software og kildekode.
Kilder og versioner
- Git-dokumentation: git gc og standardværdier for reflog-udløb
- Git-dokumentation: git config, herunder core.logAllRefUpdates
- Git-dokumentation: overgangen fra SHA-1 til SHA-256
Senest gennemgået: oktober 2026.
Næste skridt
- Ticket-systemer: ændringshistorik i Jira, ServiceNow og lignende
- SLA-målinger: hvordan tallene beregnes, og hvor de kan være forkerte
- Leverancens tilstand på overdragelsestidspunktet: sikring af miljøer og builds
- GitHub, GitLab og Azure DevOps: auditlogs for kloning, forks og tokens
Læs også: Escrow: verifikation af, at den deponerede kildekode kan bygges · Ticket-systemer: ændringshistorik i Jira, ServiceNow og lignende
→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
