Du har publisert en artikkel med feil kommando i. Eller en pris som var riktig i fjor. Eller et avsnitt som ikke burde stå der. Spørsmålet er ikke om det skjer. Spørsmålet er hvor lang tid det tar å rette, og om du kan se hva som endret seg.

Hvis innholdet ditt ligger som Markdown-filer i Git, har du allerede svaret. Du trenger ikke et CMS med versjonshistorikk, revisjonsflyt og rollback-knapp. Du trenger fem kommandoer og litt disiplin.

Hva Git faktisk gir deg #

Tre ting, og alle tre er det du ønsker deg fra et publiseringsverktøy:

  • Hver endring er et navngitt punkt i historien. Hvem, når og hvorfor.
  • Du kan se nøyaktig hva som ble endret, linje for linje, mellom to versjoner av en tekst.
  • Du kan gå tilbake, helt eller for én enkelt fil, uten at noe forsvinner.

Markdown er det som gjør dette godt: ren tekst gir lesbare forskjeller. Et lite tips: skriv gjerne én setning per linje, så peker diffen på setningen som ble endret, ikke hele avsnittet.

Flyten, fra redigering til publisering #

Her er den enkleste varianten som fortsatt er trygg. Den bruker en egen gren per endring, så den publiserte versjonen aldri blir halvferdig.

bash 
# 1. Lag en gren for endringen
git switch -c rett-feil-i-backupartikkelen

# 2. Rediger artikkelen i editoren din

# 3. Se hva du faktisk endret
git diff

# 4. Lagre endringen som et navngitt punkt
git add innhold/backup.md
git commit -m "Rett feil kommando i restore-eksempelet"

Du skriver ikke til hovedgrenen direkte. Du lager en gren, endrer, ser på forskjellen og lagrer.

Forhåndsvisning. Kjør nettstedets lokale utviklingsserver for å se resultatet slik leserne vil se det. Bruker du en hostingtjeneste som bygger forhåndsvisninger av pull requests, får du en egen testadresse å sjekke og dele. Hos Netlify lages slike deploy previews som standard for pull requests, ifølge dokumentasjonen, mens branch deploys må slås på manuelt. Sjekk hva som er aktivert hos deg.

Publisering. Når forhåndsvisningen ser riktig ut, slår du grenen inn i hovedgrenen (merge, gjerne via en pull request). Hvis nettstedet bygges automatisk fra hovedgrenen, er artikkelen publisert når bygget er ferdig. Før det er den bare en fil i Git.

Rollback: tre situasjoner, tre verktøy #

Her skiller amatørene seg fra de som sover godt. Det finnes flere måter å gå tilbake på, og de gjør forskjellige ting.

Du vil finne ut hva som skjedde.

bash 
git log --oneline -- innhold/backup.md      # historikken for én fil
git show <commit>                           # hva endret denne commit'en?
git diff <commit>^ <commit> -- innhold/backup.md

Du vil angre én hel endring. Bruk git revert. Dokumentasjonen beskriver at kommandoen lager en ny commit som reverserer endringene fra en tidligere. Historikken bevares, og det er nettopp derfor den er trygg på en delt gren:

bash 
git revert <commit>

Merk at den krever et rent arbeidstre uten ulagrede endringer.

Du vil bare ha én fil tilbake slik den var. Bruk git restore med --source. Ifølge Git-dokumentasjonen henter den filen fra en bestemt commit, gren eller tag:

bash 
git restore --source=<commit> -- innhold/backup.md
git diff                                    # se at det ble slik du ville
git add innhold/backup.md
git commit -m "Gjenopprett backup-artikkelen fra før omskrivingen"

Restore overskriver filen i arbeidskatalogen, så se på diffen før du lagrer. Publiseringen er først tilbakerullet når den nye commit'en er slått inn og nettstedet er bygget på nytt.

Hvis feilen kom inn via en merge #

En revert av en merge-commit krever at du oppgir hvilken forelder som er «hovedlinjen», med -m:

bash 
git revert -m 1 <merge-commit>

Les advarselen i dokumentasjonen: å reversere en merge sier i praksis at du aldri vil ha de endringene fra den grenen, så en senere merge av samme gren henter ikke dem inn igjen uten at du først reverserer reverteringen. Det er forståelig, men det overrasker folk.

Ikke bruk git reset --hard på noe som er publisert #

Kommandoen finnes, og den virker, men den kaster ulagrede endringer. Og hvis du skriver om historikk som andre allerede har hentet, får de problemer. Revert er den vennlige varianten: den legger til historie i stedet for å fjerne den.

Versjonskontroll er ikke synkronisering #

Her er en fallgruve som er verdt å nevne, fordi den koster mye tid. Mange prøver å løse «to personer redigerer samme tekst» med automatisk toveis-synkronisering mellom verktøy: en mappesynkronisering, et dokumentverktøy som skriver til Git og et annet som leser fra det. Det virker til to steder endrer samme fil samtidig. Da får du konfliktkopier, overskrevne avsnitt og en historikk ingen forstår.

Git løser dette med eksplisitt versjonskontroll: du henter først, redigerer, lagrer et punkt, og Git forteller deg om noen andre har endret det samme. Konflikter er synlige og løses av et menneske. Hold deg til én regel: Git er sannhetskilden, og alle endringer går gjennom en commit. Bruker du et CMS som skriver til Git, er det fortsatt i orden, så lenge det skriver commits i stedet for å erstatte filer i det stille.

Hva dette ikke gir deg #

Ærlighet: Git gir deg ikke en grafisk redigeringsflate for folk som ikke vil lære kommandoer, og det forhindrer ikke at to personer skriver om samme avsnitt. Det gir deg historikk og kontroll. Har du redaktører som ikke vil røre terminalen, trenger du et grensesnitt oppå, men da legger du det oppå Git, ikke i stedet.

For de fleste små publikasjoner er dette nok: en gren, en diff, en commit, en forhåndsvisning, en merge og en revert i bakhånd. Det er ikke sexy, men det er det som lar deg trykke «publiser» uten å få svette hender.