Du har endret tre filer. To av dem hører til den nye menyen, den tredje er en rettet skrivefeil. Skriver du git add . og git commit, havner alt i én commit med en melding som bare passer på halvparten. Det er her git status, git add og git commit skiller seg fra en vanlig lagreknapp: du bestemmer selv hva som hører sammen.
Tre steder en endring kan være
Git deler arbeidet ditt i tre lag, og kommandoene flytter endringer mellom dem.
- Arbeidsmappen er filene slik de ser ut på disken nå. Her redigerer du.
- Staging-området er en kladd for neste commit. Det du legger her med git add, blir med når du committer.
- Historikken er alle commitene. Det som er committet, er lagret for godt, og du kan alltid gå tilbake til det.
I GitHub Desktop er staging-området avkrysningsboksene ved hver fil. I terminalen er det git add.
git status: hva har skjedd?
git status viser hvor hver endring befinner seg. Svaret har opptil tre lister:
- Untracked files er nye filer Git aldri har sett før.
- Changes not staged for commit er filer Git kjenner, som er endret, men ikke lagt i staging.
- Changes to be committed er det som blir med i neste commit.
Blir svaret langt, gir git status -s en kortversjon med én linje per fil. To spørsmålstegn betyr ny fil, M betyr endret, og A betyr lagt til i staging. Dukker det opp filer som aldri skal versjoneres, som node_modules eller .env, hører de hjemme i en .gitignore-fil, ikke i listen hver gang du sjekker status.
Står det «nothing to commit, working tree clean», er alt lagret. Kjør git status før og etter alle andre kommandoer. Den koster ingenting, og den foreslår ofte selv hva du bør skrive neste gang.
git add: velg hva som skal med
git add . legger alle endringer i staging. Det er det du bruker oftest, og det tilsvarer å krysse av for alle filene i GitHub Desktop. Vil du bare ha med noen filer, skriver du navnene:
- Kjør git add index.html for å legge bare den filen i staging.
- Kjør git status. index.html står nå under Changes to be committed, mens style.css fortsatt er untracked.
- Ombestemmer du deg, legger git add style.css til den andre også.
Har du lagt noe i staging som ikke skulle vært der, fjerner git restore --staged etterfulgt av filnavnet det igjen. Endringen i filen blir værende, den er bare ikke med i neste commit.
Tips: Med git add -p går Git gjennom hver endring for seg og spør om den skal med. Da kan du dele endringer i én og samme fil på to commits, for eksempel menyen og skrivefeilen.
git commit: lagre med en melding
git commit -m "Legg til meny i headeren" lagrer alt i staging som én commit. Valget -m betyr melding. Det tilsvarer feltet nederst til venstre og knappen Commit to main i GitHub Desktop.
Glemmer du -m, åpner Git en teksteditor for meldingen. Ofte er det Vim, som forvirrer mange første gang. Skriv meldingen, trykk Esc, skriv :wq og trykk Enter for å lagre og gå ut.
To snarveier er verdt å kjenne:
- git commit -am "melding" legger alle endrede filer Git allerede kjenner i staging og committer i ett. Nye filer blir ikke med.
- git commit --amend -m "ny melding" retter meldingen på siste commit. Bruk det bare før du har pushet, ellers skriver du om historikk andre allerede har hentet.
Slik skriver du gode commit-meldinger
Meldingene er det du leser når du leter etter når noe ble endret, og hvorfor. «Fikset ting» hjelper ingen om tre måneder. Noen enkle regler gjør historikken lesbar:
- Skriv hva commiten gjør, i bydeform: «Legg til footer», ikke «La til footer» eller «footer».
- Hold første linje under rundt 50 tegn. Det er den som vises i lister.
- Én commit, én ting. Blir meldingen lang med «og» i midten, er det to commits.
- Bruker teamet GitHub Issues, legger du til nummeret, for eksempel «Legg til footer #4».
Og commit ofte. En god tommelfingerregel er å committe hver gang du er ferdig med noe som virker, selv om det er lite. Små commits er lette å forstå, lette å angre, og gjør det mye enklere å finne ut når en feil kom inn.
Commitene ligger bare på maskinen din til du pusher dem. Hvordan du laster dem opp og henter kollegaenes, står i Forskjellen på git fetch og git pull. Vil du se hva du har committet så langt, er Slik ser du historikken i Git med log, show og diff neste steg. Har du ikke satt opp et repo ennå, starter du med Slik kobler du et lokalt Git-repo til GitHub.
Denne videoen er hentet fra kurset Git og GitHub på Utdannet.no. I det fulle kurset ser du hver kommando side om side med GitHub Desktop, slik at du forstår hva som skjer begge steder, og kapittelet avsluttes med spørsmålskort og quiz på kommandoene.
