Mappen heter «nettside_final», ved siden av ligger «nettside_final_2» og «nettside_final_FERDIG», og ingen husker lenger hvilken som er den riktige. Eller du er tre stykker som jobber i de samme filene, og noen har nettopp overskrevet det du satt med i hele går. Begge problemene har samme løsning, og den heter Git.
Git holder orden på hver eneste endring i et prosjekt: hva som ble endret, når, og av hvem. Du kan gå tilbake til en hvilken som helst tidligere versjon, prøve ut noe nytt uten å røre det som virker, og slå sammen arbeidet til flere personer uten å lime for hånd. Git er standarden i bransjen. Rundt 94 prosent av utviklerne i Stack Overflows store utviklerundersøkelse oppgir at de bruker det.
Git og GitHub er to forskjellige ting
Git er et program som kjører på din egen maskin. Det lagrer historikken lokalt og virker uten internett. GitHub er en skytjeneste der du legger prosjektene dine, slik at andre kan hente dem, bidra til dem og følge med på hva som skjer. GitHub legger i tillegg på verktøy som Git ikke har: pull requests for å få koden gjennomgått, Issues for oppgaver og Projects for tavler i Kanban-stil.
Du kan bruke Git uten GitHub, men ikke GitHub uten Git. Og du trenger ikke terminalen for å komme i gang. GitHub Desktop gir deg de samme grunnoperasjonene med knapper, og Visual Studio Code har versjonskontroll innebygd i sidepanelet.
Tips: Start med GitHub Desktop for å forstå flyten, og gå over til terminalen når ordene commit, push og pull sitter. Kommandoene blir mye lettere å huske når du allerede vet hva de gjør.
Flyten du gjentar hver dag
Nesten alt arbeid med Git følger samme rytme. Du endrer noen filer, velger hvilke endringer som hører sammen, og lagrer dem som en commit med en kort melding om hva du gjorde. Commits ligger først bare på din maskin. Med push laster du dem opp til GitHub. Har andre gjort endringer, henter du dem med fetch og slår dem sammen med din kode med pull.
Commit, push, fetch og pull er de fire verbene som bærer resten. I terminalen kommer det noen få til: git status for å se hva som er endret, git add for å velge hva som skal med, og git log og git diff for å se historikken og forskjellene.
Branches, pull requests og merge-konflikter
Det kraftigste i Git er branches: parallelle versjoner av prosjektet. Hovedbranchen, gjerne kalt main, skal alltid virke, fordi det er den kundene ser. Nye funksjoner bygges i egne branches, og først når de er ferdige og testet, slås de sammen med main.
I et team skjer sammenslåingen sjelden direkte. Du lager en pull request på GitHub, en forespørsel om å få endringene dine inn, og en kollega går gjennom koden før den godkjennes. Har to personer endret den samme linjen, oppstår en merge-konflikt. Den ser skremmende ut første gang, men handler bare om å velge hvilken versjon som skal stå.
GitHub som prosjektverktøy
Et ryddig prosjekt på GitHub har mer enn kode. En .gitignore-fil holder passord, miljøvariabler og tusenvis av hjelpefiler utenfor repoet. En README-fil forteller hva prosjektet er og hvordan man kommer i gang. Issues er en oppgaveliste der hver oppgave får et nummer du kan nevne i commit-meldingene, og Projects samler oppgavene på en tavle der prosjektlederen ser hvem som jobber med hva.
Fra artikler til nettkurs
Artiklene her bygger på kurset Git og GitHub på Utdannet.no. Der følger du ett lite nettsideprosjekt fra første commit i GitHub Desktop, via kommandoene i terminalen, til branches, pull requests, en merge-konflikt du lager og løser selv, og et komplett løp med issue, feature-branch og code review. Vil du bli kjent med editoren som brukes i kurset, er Visual Studio Code et godt sted å starte, og har du ikke skrevet kode før, gir HTML – komplett guide deg noe å versjonere.
