Hjem » Siste artikler » Grunnleggende Git uten drama: slik bruker du versjonskontroll trygt på egen PC

Grunnleggende Git uten drama: slik bruker du versjonskontroll trygt på egen PC

Hovedillustrasjon
Hovedillustrasjon. Foto: Danial Igdery / Unsplash.

Git høres ofte avansert ut, men for de fleste nybegynnere handler det om noe ganske enkelt: å kunne angre trygt, se historikk og slippe å ha ti mapper med navn somprosjekt_final_ny_siste_2. Med noen få kommandoer får du mye bedre kontroll.

I denne artikkelen får du en jordnær innføring i Git brukt lokalt på din egen maskin. Målet er at du skal forstå hva som skjer, ikke bare kopiere kommandoer. Vi holder oss til enkle scenarier som passer små prosjekter og nybegynnere.

Hva Git egentlig gjør, uten kompliserte ord

Git er et verktøy som følger med på endringene i filene dine over tid. Hver gang du sier ifra, lagrer Git et nytt “bilde” av prosjektet. Disse bildene kallescommits, og de danner en historikk du kan bla i.

Poenget er at du når som helst kan gå tilbake til en tidligere tilstand, se hva som ble endret, og hvem som gjorde det. Selv om du bare jobber alene, er det gull verdt når noe plutselig slutter å virke.

Installer Git og sjekk at det fungerer

Git finnes til Windows, macOS og Linux. De fleste finner oppdatert installasjonsinfo på det offisielle Git-nettstedet eller via pakkebehandleren til operativsystemet. Grensesnitt og installasjonsdetaljer kan endre seg, så ta en rask sjekk der før du begynner.

Når Git er installert, åpner du terminal eller kommandolinje og skriver:

Windows, macOS eller Linux:

git --version

Får du opp et versjonsnummer, er du klar. Får du feilmelding, sjekk dokumentasjonen til Git for ditt system.

Lag ditt første Git-prosjekt

Velg en mappe der du har et lite kodeprosjekt, eller lag en ny mappe som test. I terminalen navigerer du til mappen, for eksempel:

cd /sti/til/prosjekt

Deretter initialiserer du et nytt Git-repositorium:

git init

Nå har du fortalt Git at denne mappen skal versjonskontrolleres. Git har laget en skjult mappe.gitsom inneholder all historikken. Ikke slett eller endre denne manuelt.

Fra endring til commit: den enkle arbeidsflyten

Git skiller mellom tre nivåer: filene i mappen din, en “ventekø” for endringer (staging area), og selve historikken (commits). Tenk slik: du jobber fritt, velger hvilke endringer som skal bli med, og så lagrer du et nytt steg i historikken.

En typisk arbeidsrunde ser slik ut:

  1. Endre eller lag en fil.
  2. Se status: git status.
  3. Legg til i ventekøen: git add filnavn.
  4. Lag et nytt historikksteg: git commit -m "kort beskrivelse".

Et raskt eksempel:

git status
git add index.html
git commit -m "Legg til enkel startside"

Forstågit statussom sikkerhetsnett

git statuser kommandolinjens “kontrollpanel”. Den forteller deg hvilke filer som er endret, hvilke som er klare til commit, og om du har noe som gjenstår. Kjør den ofte, spesielt mens du lærer.

Når du er usikker på hva som skjer, skriv git status før du gjør noe annet. Da reduserer du sjansen for overraskelser betydelig.

Gode commit-meldinger for fremtidige deg

Commit-meldingen er notatet du skriver til fremtidige deg (og eventuelle samarbeidspartnere). Unngå “fix” eller “oppdatert ting”. Skriv heller hva og gjerne hvorfor. For eksempel:

  • git commit -m "Bytt til mørkt tema for bedre kontrast"
  • git commit -m "Refaktorer brukerinnlogging til egen modul"

Prøv å holde hver commit noenlunde logisk avgrenset. Det gjør det mye enklere å feilsøke ved å gå gjennom historikken steg for steg.

Se historikk og sammenligne endringer

Tematisk illustrasjon
Tematisk illustrasjon. Foto: Google DeepMind / Pexels.

For å se en enkel liste over tidligere commits bruker du:

git log

Dette viser commit-id, forfatter, dato og meldingen du skrev. For en kortere visning kan du teste:

git log --oneline

Hvis du vil se hva som er endret i forhold til siste commit, bruker du:

git diff

Her får du en linje-for-linje-sammenligning, med markering av hva som er lagt til og fjernet. Det er et nyttig verktøy for å dobbeltsjekke endringer før du committer.

Angre uten panikk: enkle scenarier

Alle gjør feil, og Git har flere måter å angre på. Her er noen trygge varianter for nybegynnere, men vær forsiktig og sørg for at du forstår hva de gjør før du bruker dem.

Du har endret en fil, men vil tilbake til siste commit:

git restore filnavn

Du har kjørt git add, men vil ta filen ut av ventekøen igjen:

git restore --staged filnavn

Eliminerer du en feil på et tidlig steg, slipper du ofte større ryddejobber senere.

Enkelt oppsett for trygg lokal branching

Selv om du jobber alene, er en enkel grenestruktur nyttig. Tenk hovedgren som “stabil versjon” og en eller flere arbeidsgrener for nye ideer. Da slipper du å ødelegge det som allerede fungerer mens du eksperimenterer.

Typisk oppsett:

  • mainellermaster: den stabile varianten.
  • Egne grener for oppgaver: for eksempelfeature-dark-modeellerbugfix-login-timeout.

Lag og slå sammen en gren steg for steg

For å lage en ny gren og gå rett inn i den:

git checkout -b feature-dark-mode

Nå jobber du fritt, committer som vanlig, og tester. Når du er fornøyd og vil slå endringene inn i hovedgrenen:

  1. Gå tilbake til hovedgren: git checkout main
  2. Slå sammen: git merge feature-dark-mode

Hvis Git klarer å slå sammen automatisk, er du ferdig. Hvis ikke, får du beskjed om konflikt som du må løse ved å redigere de aktuelle filene manuelt og deretter gjøre en ny commit.

Vanlige nybegynnerfeller og hvordan unngå dem

Noen typiske problemer dukker opp igjen og igjen, spesielt når du er ny:

  • For sjeldne commits: Lag flere små commits i stedet for én stor. Det gir mer oversikt.
  • Vage meldinger: Skriv kort og konkret. Tenk “om tre måneder, skjønner jeg dette?”.
  • Commit av midlertidige filer: Sett opp en.gitignore-fil for å unngå å versjonskontrollere byggfiler, cache og editorfiler.

Du finner mange eksempler på typiske.gitignore-filer fra rammeverk og språk på nett. Sjekk gjerne oppdatert dokumentasjon for teknologien du bruker.

Neste steg: fra lokal Git til GitHub

Når du er komfortabel med lokal bruk, er det naturlige neste steget å koble prosjektet til en ekstern tjeneste, for eksempel GitHub, GitLab eller Bitbucket. Da får du sikkerhetskopi, enkel deling og flere verktøy for samarbeid.

Men selv om du aldri legger noe på nett, er lokal Git en stor oppgradering fra å bare kopiere mapper. Du får historikk, angremuligheter og struktur, uten å gjøre arbeidsdagen unødvendig komplisert.

0 kommentarer