# Holdt fire repoer til én historikkstandard — konvensjonell, uten emojier og uten attribusjonslinjer, håndhevet av en hook for commit‑meldinger — sammen med 48 instruksjonsdokumenter som styrer hvordan arbeidet gjøres. juli 2026 **Situasjon.** Fire repoer bygd over atten måneder av én person er situasjonen der prosess er lettest å hoppe over, fordi det ikke finnes noen å koordinere med, og kostnaden ved en uleselig historikk betales helt av ens fremtidige selv, som ikke har klaget ennå. Det er også situasjonen der en inkonsekvent historikk er mest sannsynlig, siden hvert repo kan gli inn i sine egne vaner uten at noe trekker dem sammen. **Oppgave.** Én standard for historikk og én standard for instruksjoner måtte gjelde i hvert repo der arbeidet skrives, og det måtte håndheves maskinelt i stedet for å huskes. **Handling.** Commitstandarden er et konvensjonelt prefiks som angir typen endring og et omfang, en emnelinje under en fast lengde, ingen emojier og ingen attribusjonslinjer av noe slag — det siste fordi en linje som krediterer et verktøy, ikke er et faktum om endringen, og historikken er til for fakta om endringer. En hook for commitmeldinger avviser alt som ikke følger standarden, i hvert repo som det arbeides i, så standarden er en egenskap ved repoet og ikke ved den som committer. Fordelingen i det største repoet viser hva arbeidet faktisk var: 156 commits med funksjoner, 133 rettinger, 128 dokumentasjon, 81 vedlikehold, 26 refaktoreringer, 20 stil, 5 ytelse og 3 test. Dokumentasjon ligger nær nok rettingene til å være verdt å legge merke til, og det er en følge av den andre halvdelen av dette — 48 instruksjonsdokumenter fordelt på de fire, hvert av dem dekker ett domene, hvert av dem er skrevet som regler i stedet for beskrivelse, og alle kan nås fra ett inngangsdokument per repo, så det finnes ett sted å begynne. En linter for dokumentasjon håndhever størrelsesbudsjetter per fil og at hver fil står i indeksen, så samlingen forblir navigerbar i stedet for å vokse til et arkiv. **Resultat.** Fire repoer deler ett historikkformat og én instruksjonsstruktur, og begge håndheves av hooks i stedet for av disiplin. Det dette ikke gjør, er å gjøre historikken god: formatet sjekkes, men innholdet gjør det ikke, så en emnelinje som følger standarden, men som ikke beskriver noe, slipper gjennom like lett som en som forklarer endringen. --- - Rolle: Teknisk skribent - Kategorier: [DevOps](https://platform.engineer.company/nb/categories/devops/), [Automatisering og CI/CD](https://platform.engineer.company/nb/categories/automation/), [Teknisk ledelse](https://platform.engineer.company/nb/categories/technical-leadership/), [Prosjektledelse](https://platform.engineer.company/nb/categories/project-management/), [Smidig og Scrum](https://platform.engineer.company/nb/categories/agile/), [Dokumentasjon](https://platform.engineer.company/nb/categories/documentation/) - Tjenester: [DevOps og CI/CD‑automatisering](https://platform.engineer.company/nb/services/devops-cicd/), [Teknisk ledelse og rådgivning](https://platform.engineer.company/nb/services/technical-leadership/), [Prosjektledelse (smidig)](https://platform.engineer.company/nb/services/project-management/), [Teknisk dokumentasjon](https://platform.engineer.company/nb/services/technical-documentation/)