Kunden bruker nettsiden hver dag, og du skal bygge en ny innlogging. Gjør du det rett i koden som ligger ute, havner halvferdige endringer hos kunden, og en feil kan ta ned hele siden. Med branches i Git bygger du i en egen versjon av prosjektet, mens den ekte siden går upåvirket videre. Først når det nye virker, slår du det sammen.
Hvorfor branches
En branch er en parallell versjon av prosjektet. Endringer i én branch er usynlige i de andre til du slår dem sammen. Det gjør at flere ting kan utvikles samtidig, uten at de går i beina på hverandre eller på det som allerede er i drift.
Et vanlig oppsett har tre nivåer:
- main er hovedbranchen. Den skal alltid virke, fordi den ofte publiseres automatisk til kundene.
- dev er der nye ting samles og testes sammen før de går videre til main.
- Feature-branches lages for hver funksjon, for eksempel «ny-innlogging» og «nytt-design». Hvert team jobber i sin, og arbeidet møtes først i dev.
Når alt i dev virker sammen, slås det inn i main, og en ny runde begynner. Kundene merker bare at siden blir bedre.
Se og opprett branches
git branch lister alle branches i repoet. Den du står på, har en stjerne foran seg. Trykk Q for å gå ut hvis listen åpner seg i en egen visning.
git branch viser bare branchene på maskinen din. git branch -a tar også med branchene du har hentet fra GitHub. De står med «remotes/origin/» foran navnet, og er nyttige når en kollega har pushet en branch du skal jobbe videre på. Da holder det å skrive git switch med navnet uten forstavelsen, så lager Git en lokal kopi som er koblet til den på GitHub.
For å lage en ny branch skriver du git branch dev. Branchen lages som en kopi av der du står nå, men du blir stående der du var. Det overrasker mange. Kjør git branch igjen, og stjernen står fortsatt ved den gamle.
I GitHub Desktop lager du en branch fra menyen Current branch øverst, med New branch. Den nye branchen finnes bare lokalt til du klikker Publish branch.
Bytt branch med git switch
git switch dev flytter deg til dev. Terminalen svarer «Switched to branch 'dev'», og filene i mappen endrer seg til slik de er i den branchen. Trykk Tab mens du skriver navnet, så fullfører terminalen det.
Vil du lage en branch og gå til den i samme slag, bruker du git switch -c ny-innlogging. Det er den kommandoen du kommer til å bruke mest.
Obs: Uferdige endringer som ikke er committet, blir med deg når du bytter branch. Kolliderer de med noe i branchen du bytter til, nekter Git å bytte. Committ eller legg endringene til side med git stash først.
Gi nytt navn og slett
- git branch -m dev gir branchen du står på et nytt navn, her «dev».
- git branch -d test sletter branchen test. Git nekter hvis den har endringer som ikke er slått sammen noe sted.
- git branch -D test sletter uansett. Bruk den bare når du vet at arbeidet i branchen kan kastes.
Du kan ikke slette branchen du står på. Bytt til en annen først.
git checkout, den gamle måten
I eldre guider og på Stack Overflow ser du git checkout dev i stedet for git switch. Det virker fortsatt og gjør det samme. Problemet er at checkout også gjør noe helt annet: git checkout -- index.html kaster alle endringer du har gjort i filen siden siste commit, uten å spørre.
At samme kommando både bytter branch og sletter arbeid, er grunnen til at Git i 2019 fikk to nye kommandoer med hver sin jobb: git switch for å bytte branch og git restore for å forkaste endringer i filer. Bruk dem, så er det tydelig hva du gjør.
Del branchen og slå den sammen
En ny branch finnes bare på maskinen din til du pusher den. Første gang skriver du git push -u origin ny-innlogging. Valget -u kobler den lokale branchen til den på GitHub, slik at git push og git pull virker uten mer senere.
Når funksjonen er ferdig, skal den inn i dev eller main. Du kan gjøre det selv med git merge: bytt til branchen som skal motta endringene, for eksempel med git switch main, og skriv git merge dev. I et team er det tryggere å la en kollega se på koden først, med en pull request. Det står i Slik lager du en pull request i GitHub.
Har to branches endret de samme linjene, får du en merge-konflikt når de slås sammen. Slik løser du en merge-konflikt i Git viser hvordan du leser og løser den. Hvis du vil se branchene som en graf, gir git log --oneline --graph --all deg det, og kapittelet om branches i Pro Git forklarer hva som skjer under panseret.
Denne videoen er hentet fra kurset Git og GitHub på Utdannet.no. I det fulle kurset lager, bytter, gir nytt navn til og sletter du branches både i GitHub Desktop og i terminalen, slår dem sammen med git merge og pull requests, og lager en merge-konflikt med vilje for å løse den.
