Chapters ▾ 2nd Edition

2.2 Grunderna i Git - Spara ändringar i kodförrådet

Spara ändringar i kodförrådet

Nu ska du ha ett riktigt Git‑kodförråd på din lokala dator och en utcheckad arbetskopia av alla filer. Vanligtvis vill du nu börja göra ändringar och spara ögonblicksbilder av dem i kodförrådet var gång projektet når ett läge du vill bevara.

Kom ihåg att varje fil i arbetskatalogen kan befinna sig i ett av två tillstånd: spårad eller ospårad. Spårade filer är filer som fanns i den senaste ögonblicksbilden, samt nyss köade filer; de kan vara omodifierade, ändrade eller köade. Kort sagt: spårade filer är sådana som Git känner till.

Ospårade filer är allt annat – filer i arbetskatalogen som inte fanns i den senaste ögonblicksbilden och som inte ligger i köytan. När du först klonar ett kodförråd är alla filer spårade och omodifierade eftersom Git just tog ut dem och du inte har redigerat något.

När du redigerar filer markerar Git dem som ändrade, eftersom du har ändrat dem sedan senaste incheckningen. Under arbetets gång väljer du ut ändringar att köa, gör en incheckning av det som är köat och sedan börjar cykeln om.

Livscykeln för filernas status
Figur 8. Livscykeln för filernas status

Kontrollera filstatus

Det viktigaste verktyget för att avgöra vilka filer som befinner sig i vilket läge är kommandot git status. Om du kör kommandot direkt efter en kloning ser du något i stil med detta:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

Det betyder att du har en ren arbetskatalog; med andra ord är inga spårade filer ändrade. Git ser heller inga ospårade filer, annars skulle de listas här. Slutligen berättar kommandot vilken gren du står på och att den inte har avvikit från samma gren på servern. Just nu är grenen alltid master, vilket är standard; det behöver du inte bry dig om här. Git-grenar går igenom grenar och referenser i detalj.

Notera

GitHub bytte standardgren från master till main under mitten av 2020, och andra Git‑värdar följde efter. Du kan därför stöta på att standardgrenen i nyare kodförråd heter main och inte master. Dessutom går det att byta standardgrensnamn (som du såg i Ditt standardgrennamn), så det kan se annorlunda ut.

Själva Git använder fortfarande master som standard, så vi använder det i boken.

Säg att du lägger till en ny fil i projektet, en enkel README-fil. Om filen inte fanns innan och du kör git status ser du den ospårade filen:

$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    README

nothing added to commit but untracked files present (use "git add" to track)

Du ser att README är ospårad eftersom den listas under rubriken "Untracked files". Ospårad betyder att Git ser en fil som inte fanns i den senaste ögonblicksbilden (incheckningen) och som ännu inte har köats; Git börjar inte ta med den i framtida incheckningar förrän du säger till. Detta för att du inte oavsiktligt ska börja inkludera genererade binärer eller andra filer du inte vill ha. Du vill däremot inkludera README, så vi börjar med att spåra filen.

Spåra nya filer

För att börja spåra en ny fil använder du kommandot git add. För att börja spåra README kan du köra:

$ git add README

Om du kör git status igen ser du att README nu är spårad och köad för nästa incheckning:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

    new file:   README

Att filen är köad ser du eftersom den finns under rubriken "Changes to be committed". Om du gör en incheckning nu blir det filversionen vid senaste git add som hamnar i nästa ögonblicksbild. Du minns kanske att när du körde git init gjorde du sedan git add <filer> – det var för att börja spåra filer i katalogen. git add tar en sökväg till antingen en fil eller en katalog; om det är en katalog lägger kommandot till alla filer i katalogen rekursivt.

Köa ändrade filer

Låt oss ändra en fil som redan är spårad. Om du ändrar en tidigare spårad fil som heter CONTRIBUTING.md och kör git status igen får du något som liknar detta:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

CONTRIBUTING.md visas under "Changes not staged for commit" – en spårad fil har ändrats i arbetskatalogen men ännu inte köats. För att köa den kör du git add. git add är ett mångsidigt kommando – du använder det för att börja spåra nya filer, för att köa filer och för att markera sammanslagningskonflikter som lösta. Det kan vara hjälpsamt att tänka "lägg exakt detta innehåll i nästa incheckning" snarare än "lägg till filen i projektet". Låt oss köra git add för att köa CONTRIBUTING.md och sedan köra git status igen:

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Båda filerna är köade och kommer att ingå i nästa incheckning. Anta nu att du kommer på en liten ändring du vill göra i CONTRIBUTING.md innan du sparar. Du öppnar filen igen och gör ändringen, och är redo att göra en incheckning. Men kör git status en gång till:

$ vim CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Vad betyder det här? Nu listas CONTRIBUTING.md både som köad och som oköad. Git köar filen exakt som den ser ut när du kör git add. Om du gör en incheckning nu blir det versionen av CONTRIBUTING.md från senaste git add som ingår, inte den som finns i arbetskatalogen när du kör git commit. Om du ändrar en fil efter att du kör git add måste du köra git add igen för att köa den senaste versionen:

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Kort status

Utskriften från git status är omfattande men också ganska lång. Git har en kortstatus-flagga så att du kan se ändringarna mer kompakt. Om du kör git status -s eller git status --short får du en mycket kortare utskrift:

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

Nya filer som inte spårats har ?? till vänster om namnet, nya filer som lagts till i köytan har A, ändrade filer har M, och så vidare. Det finns två kolumner till vänster om filnamnet – den vänstra visar statusen i köytan (vad som kommer ingå i nästa incheckning) och den högra visar statusen i arbetskatalogen. I exemplet är README ändrad i arbetskatalogen men inte köad för nästa incheckning, medan lib/simplegit.rb är ändrad och köad. Rakefile var ändrad, köad och sedan ändrad igen, så den innehåller både köade och oköade ändringar.

Ignorera filer

Ofta har du en uppsättning filer som du inte vill att Git automatiskt lägger till eller ens visar som ospårade. Det är vanligtvis automatiskt genererade filer som loggar eller filer som byggsystemet skapar. Då kan du skapa en fil som heter .gitignore och lista mönstren för de filer du vill ignorera. Här är ett exempel på en .gitignore-fil:

$ cat .gitignore
*.[oa]
*~

Den första raden talar om för Git att ignorera alla filer som slutar på .o eller .a – objekt- och arkivfiler som kan skapas när du bygger. Den andra raden talar om för Git att ignorera alla filer vars namn slutar på tilde (~), vilket många textredigerare, som Emacs, använder för temporära filer. Du kan också ta med logg-, tmp- och pid-kataloger, automatiskt genererad dokumentation och så vidare. Det är ofta en bra idé att skapa en .gitignore innan du börjar arbeta med ett nytt kodförråd så att du inte oavsiktligt versionshanterar filer du inte vill ha där.

Mönstren i .gitignore-filen följer dessa regler:

  • Tomma rader eller rader som börjar med # ignoreras.

  • Vanliga glob-mönster fungerar och tillämpas rekursivt i hela arbetskatalogen.

  • Inled ett mönster med ett snedstreck (/) för att undvika rekursivitet.

  • Avsluta ett mönster med ett snedstreck (/) för att ange en katalog.

  • Inled ett mönster med ett utropstecken (!) för att vända betydelsen.

Glob-mönster är förenklade reguljära uttryck som skal använder. En asterisk (*) matchar noll eller fler tecken; [abc] matchar ett av tecknen inom hakparentesen; ett frågetecken (?) matchar ett enskilt tecken, och hakparenteser med intervall ([0-9]) matchar ett tecken inom intervallet. Du kan också använda dubbla asterisker för att matcha nästlade kataloger; a/**/z matchar till exempel a/z, a/b/z och a/b/c/z.

Här är ytterligare ett exempel på en .gitignore-fil:

# ignore all .a files
*.a

# but do track lib.a, even though you're ignoring .a files above
!lib.a

# only ignore the TODO file in the current directory, not subdir/TODO
/TODO

# ignore all files in any directory named build
build/

# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt

# ignore all .pdf files in the doc/ directory and any of its subdirectories
doc/**/*.pdf
Tips

GitHub underhåller en omfattande lista med bra .gitignore-exempel för dussintals projekt och språk på https://github.com/github/gitignore.
Notera

I det enklaste fallet kan ett kodförråd ha en enda .gitignore i rotkatalogen, som tillämpas rekursivt i hela kodförrådet. Det är däremot möjligt att ha flera .gitignore-filer i underkataloger. Reglerna i de nästlade .gitignore-filerna gäller endast för filer i och under den katalog där filen finns. (Linuxkärnans kodförråd har 206 .gitignore-filer.)

Det ligger utanför bokens omfattning att gå in i detalj på hur flera .gitignore-filer fungerar; se man gitignore för detaljer.

Visa köade och oköade ändringar

Om git status är för grovt – du vill veta exakt vad som har ändrats, inte bara vilka filer som är ändrade – kan du använda git diff. Vi går igenom git diff mer i detalj senare, men du använder det ofta för att svara på följande frågor: Vad har du ändrat men ännu inte köat? Vad har du köat för nästa incheckning? git status svarar på frågorna på en övergripande nivå genom att lista filnamn, men git diff visar exakt vilka rader som lagts till och tagits bort – själva ändringsmängden.

Säg att du redigerar och köar README igen och sedan ändrar CONTRIBUTING.md utan att köa den. Om du kör git status ser du något liknande:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

För att se vad du ändrat men ännu inte köat skriver du git diff utan andra argument:

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's

Kommandot jämför det som finns i arbetskatalogen med det som ligger i köytan. Resultatet visar de ändringar du gjort men ännu inte lagt i köytan.

Om du vill se vad du har köat för nästa incheckning kan du använda git diff --staged. Det jämför ändringarna i köytan med den senaste incheckningen:

$ git diff --staged
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+My Project

Viktigt att notera är att git diff i sig inte visar alla ändringar sedan senaste incheckningen – bara ändringar som ännu inte kommer ingå i nästa incheckning. Om du har köat alla ändringar att ingå i nästa incheckning ger git diff ingen utskrift.

Ytterligare ett exempel: om du köar CONTRIBUTING.md och sedan ändrar den igen kan du använda git diff för att se både de köade och oköade ändringarna. Om läget ser ut så här:

$ git add CONTRIBUTING.md
$ echo '# test line' >> CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Nu kan du använda git diff för att se vad som fortfarande är oköat:

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 643e24f..87f08c8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -119,3 +119,4 @@ at the
 ## Starter Projects

 See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
+# test line

Och git diff --cached visar vad du har köat hittills (--staged och --cached är synonymer):

$ git diff --cached
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's
Notera
Git diff i ett externt verktyg

Vi kommer att fortsätta använda git diff på olika sätt under resten av boken. Det finns också möjlighet att se skillnaderna i ett grafiskt eller externt diff-verktyg. Om du kör git difftool i stället för git diff kan du visa vilken som helst av dessa skillnader i program som emerge, vimdiff och många fler (inklusive kommersiella produkter). Kör git difftool --tool-help för att se vad som finns tillgängligt på ditt system.

Spara dina ändringar

När köytan innehåller det du vill ha kan du göra en incheckning. Kom ihåg att allt som fortfarande är oköat – filer du skapat eller ändrat sedan du senast körde git add – inte kommer att ingå i den här incheckningen. De ligger kvar som ändrade filer på din hårddisk. Anta att allt är köat och du är redo att spara. Det enklaste sättet att göra en incheckning är att skriva git commit:

$ git commit

När du gör det startas din textredigerare. (Det är den som är angiven i miljövariabeln EDITOR – oftast vim eller emacs, men du kan konfigurera den med git config --global core.editor som du såg i Kom igång).

Redigeraren visar ungefär följande text (exemplet är från Vim):

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
#	new file:   README
#	modified:   CONTRIBUTING.md
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283C

Du kan ta bort kommentarerna och skriva in ditt incheckningsmeddelande, eller lämna dem kvar som stöd. (Om du vill ha en tydligare påminnelse om vad du ändrat kan du ge flaggan -v till git commit; då får du också diffen i redigeraren.) När du avslutar redigeraren skapar Git en incheckning med ditt meddelande (kommentarer och diffar tas bort).

Alternativt kan du ange meddelandet direkt med flaggan -m:

$ git commit -m "Story 182: fix benchmarks for speed"
[master 463dc4f] Story 182: fix benchmarks for speed
 2 files changed, 2 insertions(+)
 create mode 100644 README

Nu har du gjort din första incheckning. Git skriver ut vilken gren du sparade på (master), vilken SHA‑1-kontrollsumma den har (463dc4f), hur många filer som ändrats och statistik över hur många rader som lagts till och tagits bort.

Kom ihåg att incheckningen sparar ögonblicksbilden du satte upp i köytan. Allt du inte köade ligger kvar som ändrat; du kan göra en till incheckning för att lägga in det i historiken. Varje incheckning sparar en ögonblicksbild av projektet som du kan gå tillbaka till eller jämföra med senare.

Hoppa över köytan

Även om det är användbart att skapa incheckningar precis som du vill ha dem kan köytan ibland kännas för omständig. Om du vill hoppa över den erbjuder Git en enkel genväg. Om du lägger till flaggan -a till git commit lägger Git automatiskt till alla spårade filer som är ändrade i köytan innan incheckningen, så att du kan hoppa över git add:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'Add new benchmarks'
[master 83e38c7] Add new benchmarks
 1 file changed, 5 insertions(+), 0 deletions(-)

Lägg märke till att du inte behöver köra git add på CONTRIBUTING.md i det här fallet. Det beror på att -a inkluderar alla ändrade filer. Det är bekvämt, men var försiktig: ibland tar flaggan med ändringar du inte vill ha.

Ta bort filer

För att ta bort filer från Git måste du ta bort dem från de spårade filerna (eller mer exakt från köytan) och sedan göra en incheckning. Kommandot git rm gör just det och tar även bort filen från arbetskatalogen så att du inte ser den som ospårad nästa gång.

Om du bara tar bort filen från arbetskatalogen visas den under "Changes not staged for commit" (det vill säga oköat) i git status:

$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    PROJECTS.md

no changes added to commit (use "git add" and/or "git commit -a")

Om du sedan kör git rm köas filen för borttagning:

$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    PROJECTS.md

Nästa gång du gör en incheckning är filen borta och inte längre spårad. Om du redan har ändrat filen eller lagt den i köytan måste du tvinga borttagningen med -f. Det är ett skydd för att förhindra oavsiktlig förlust av data som inte sparats i en ögonblicksbild.

En annan vanlig sak är att behålla filen i arbetskatalogen men ta bort den från köytan. Det vill säga, du vill ha filen kvar på hårddisken men inte att Git ska spåra den längre. Det är särskilt användbart om du glömde lägga till något i .gitignore och råkade köa filen, till exempel en stor loggfil eller kompilerade .a-filer. Använd då flaggan --cached:

$ git rm --cached README

Du kan ange filer, kataloger och filnamnsmönster till git rm. Det betyder att du kan göra saker som:

$ git rm log/\*.log

Notera omvänt snedstreck (\) framför *. Det behövs eftersom Git gör sin egen filnamnsexpansion utöver skalets expansion. Kommandot tar bort alla filer med filändelsen .log i katalogen log/. Eller så kan du göra något i stil med:

$ git rm \*~

Det kommandot tar bort alla filer som slutar på ~.

Flytta filer

Till skillnad från många andra versionshanteringssystem hanterar Git inte uttryckligen filflyttar. Om du byter namn på en fil i Git sparas ingen metadata som säger att filen bytt namn. Git är däremot ganska sofistikerat på att upptäcka det – vi går igenom det snart.

Det kan kännas förvirrande att Git ändå har ett flyttkommando, git mv. Om du vill byta namn på en fil i Git kan du göra så här:

$ git mv file_from file_to

Det fungerar utmärkt. Om du kör git status efteråt ser du att Git tolkar det som en namnändring:

$ git mv README.md README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Det är dock samma sak som att göra:

$ mv README.md README
$ git rm README.md
$ git add README

Git räknar ut att det är en namnändring oavsett, så det spelar ingen roll om du byter namn på filen på ena eller andra sättet. Den egentliga skillnaden är att git mv är ett kommando i stället för tre – det är en bekvämlighetsfunktion. Än viktigare är att du kan använda vilket verktyg som helst för att byta namn på filen och hantera lägg till/ta bort senare, innan du gör en incheckning.