-
1. Kom igång
- 1.1 Om versionshantering
- 1.2 En kort historik om Git
- 1.3 Vad är Git?
- 1.4 Kommandoraden
- 1.5 Installera Git
- 1.6 Första gången med Git
- 1.7 Få hjälp
- 1.8 Sammanfattning
-
2. Grunderna i Git
- 2.1 Att få tag i ett Git‑kodförråd
- 2.2 Spara ändringar i kodförrådet
- 2.3 Visa incheckningshistoriken
- 2.4 Ångra saker
- 2.5 Arbeta med fjärrkodförråd
- 2.6 Att tagga
- 2.7 Git-alias
- 2.8 Sammanfattning
-
3. Git-grenar
- 3.1 Grenar i korthet
- 3.2 Grundläggande gren- och sammanfogningsarbete
- 3.3 Grenhantering
- 3.4 Arbetsflöden med grenar
- 3.5 Fjärrgrenar
- 3.6 Ombasering
- 3.7 Sammanfattning
-
4. Git på servern
- 4.1 Protokollen
- 4.2 Konfigurera Git på en server
- 4.3 Generera din publika SSH-nyckel
- 4.4 Konfigurera servern
- 4.5 Git-demon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Tredjepartsalternativ
- 4.10 Sammanfattning
-
5. Distribuerat Git
-
6. GitHub
-
7. Git-verktyg
- 7.1 Revisionsurval
- 7.2 Interaktiv köläggning
- 7.3 Lägga undan och städa
- 7.4 Signera ditt arbete
- 7.5 Sökning
- 7.6 Skriva om historik
- 7.7 Nollställning förklarad
- 7.8 Avancerad sammanslagning
- 7.9 Rerere
- 7.10 Felsöka med Git
- 7.11 Undermoduler
- 7.12 Bunta
- 7.13 Ersätt
- 7.14 Lagring av inloggningsuppgifter
- 7.15 Sammanfattning
-
8. Anpassa Git
- 8.1 Git‑konfiguration
- 8.2 Git‑attribut
- 8.3 Git‑krokar
- 8.4 Ett exempel på Git‑upprätthållen policy
- 8.5 Sammanfattning
-
9. Git och andra system
- 9.1 Git som klient
- 9.2 Migrera till Git
- 9.3 Sammanfattning
-
10. Git bakom kulisserna
- 10.1 Lågnivådel och användardel
- 10.2 Git-objekt
- 10.3 Git-referenser
- 10.4 Packfiler
- 10.5 Refspecen
- 10.6 Överföringsprotokoll
- 10.7 Underhåll och dataåterställning
- 10.8 Miljövariabler
- 10.9 Sammanfattning
-
A1. Bilaga A: Git i andra miljöer
- A1.1 Grafiska gränssnitt
- A1.2 Git i Visual Studio
- A1.3 Git i Visual Studio Code
- A1.4 Git i IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git i Sublime Text
- A1.6 Git i Bash
- A1.7 Git i Zsh
- A1.8 Git i PowerShell
- A1.9 Sammanfattning
-
A2. Bilaga B: Bädda in Git i dina applikationer
- A2.1 Git på kommandoraden
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Bilaga C: Git-kommandon
- A3.1 Uppstart och konfiguration
- A3.2 Skaffa och skapa projekt
- A3.3 Grundläggande ögonblicksbilder
- A3.4 Grening och sammanslagning
- A3.5 Dela och uppdatera projekt
- A3.6 Inspektion och jämförelse
- A3.7 Felsökning
- A3.8 Patchning
- A3.9 E‑post
- A3.10 Externa system
- A3.11 Administration
- A3.12 Lågnivåkommandon
7.3 Git-verktyg - Lägga undan och städa
Lägga undan och städa
Ofta, när du har arbetat med en del av projektet, är saker i ett rörigt tillstånd och du vill byta gren ett tag för att jobba med något annat.
Problemet är att du inte vill göra en incheckning av halvfärdigt arbete bara för att kunna komma tillbaka till samma punkt senare.
Svaret på detta är kommandot git stash.
Att lägga undan tar det smutsiga tillståndet i din arbetskatalog — alltså ändrade spårade filer och köade ändringar — och sparar det på en stapel av oavslutade ändringar som du kan återanvända när som helst (även på en annan gren).
|
Notera
|
Migrera till
git stash push
Sedan slutet av oktober 2017 har det förts en omfattande diskussion på Gits e-postlista där kommandot
|
Lägg undan ditt arbete
För att demonstrera att lägga undan går du in i projektet och börjar arbeta på ett par filer och kanske köar en av ändringarna.
Om du kör git status kan du se ditt smutsiga tillstånd:
$ git status
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: index.html
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: lib/simplegit.rb
Nu vill du byta gren, men du vill inte checka in det du har arbetat med ännu, så du lägger undan ändringarna.
För att lägga en ny undanläggning på din stapel kör du git stash eller git stash push:
$ git stash
Saved working directory and index state \
"WIP on master: 049d078 Create index file"
HEAD is now at 049d078 Create index file
(To restore them type "git stash apply")
Du kan nu se att din arbetskatalog är ren:
$ git status
# On branch master
nothing to commit, working directory clean
Vid det här laget kan du byta gren och arbeta på annat håll; dina ändringar ligger sparade på din stapel.
För att se vilka undanläggningar du har sparat kan du använda git stash list:
$ git stash list
stash@{0}: WIP on master: 049d078 Create index file
stash@{1}: WIP on master: c264051 Revert "Add file_size"
stash@{2}: WIP on master: 21d80a5 Add number to log
I det här fallet har två undanläggningar sparats tidigare, så du har tillgång till tre olika undanlagda arbeten.
Du kan återapplicera den du just lade undan med kommandot som visas i hjälputdata från det ursprungliga git stash-kommandot: git stash apply.
Om du vill applicera en av de äldre undanläggningarna kan du ange den genom att namnge den, till exempel: git stash apply stash@{2}.
Om du inte anger en undanläggning antar Git den senaste och försöker applicera den:
$ git stash apply
On branch 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: index.html
modified: lib/simplegit.rb
no changes added to commit (use "git add" and/or "git commit -a")
Du kan se att Git åter modifierar filerna du återställde när du sparade undanläggningen. I det här fallet hade du en ren arbetskatalog när du försökte applicera undanläggningen, och du försökte applicera den på samma gren som du sparade den från. Att ha en ren arbetskatalog och applicera den på samma gren är inte nödvändigt för att lyckas applicera en undanläggning. Du kan lägga undan en undanläggning på en gren, byta till en annan gren senare och försöka applicera ändringarna. Du kan också ha ändrade och ej checkade in filer i din arbetskatalog när du applicerar en undanläggning — Git ger dig sammanslagningskonflikter om något inte längre går att applicera rent.
Ändringarna i dina filer återapplicerades, men filen du köade tidigare köades inte om.
För att göra det måste du köra git stash apply med flaggan --index för att tala om att kommandot ska försöka återapplicera de köade ändringarna.
Om du hade kört det i stället skulle du ha fått tillbaka ditt ursprungsläge:
$ git stash apply --index
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: index.html
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: lib/simplegit.rb
Alternativet apply försöker bara applicera det undanlagda arbetet — du har det fortfarande kvar på din stapel.
För att ta bort det kan du köra git stash drop med namnet på undanläggningen:
$ git stash list
stash@{0}: WIP on master: 049d078 Create index file
stash@{1}: WIP on master: c264051 Revert "Add file_size"
stash@{2}: WIP on master: 21d80a5 Add number to log
$ git stash drop stash@{0}
Dropped stash@{0} (364e91f3f268f0900bc3ee613f9f733e82aaed43)
Du kan också köra git stash pop för att applicera undanläggningen och sedan omedelbart ta bort den från din stapel.
Kreativ undanläggning
Det finns några varianter av undanläggning som också kan vara hjälpsamma.
Det första alternativet som är ganska populärt är --keep-index-flaggan till git stash.
Den säger till Git att inte bara inkludera allt köat innehåll i undanläggningen som skapas, utan samtidigt lämna det kvar i index.
$ git status -s
M index.html
M lib/simplegit.rb
$ git stash --keep-index
Saved working directory and index state WIP on master: 1b65b17 added the index file
HEAD is now at 1b65b17 added the index file
$ git status -s
M index.html
En annan vanlig sak du kanske vill göra med undanläggning är att lägga undan ospårade filer såväl som spårade.
Som standard lägger git stash bara undan ändrade och köade spårade filer.
Om du anger --include-untracked eller -u kommer Git att inkludera ospårade filer i undanläggningen som skapas.
Men att inkludera ospårade filer i undanläggningen kommer fortfarande inte att inkludera uttryckligen ignorerade filer; för att även inkludera ignorerade filer använder du --all (eller bara -a).
$ git status -s
M index.html
M lib/simplegit.rb
?? new-file.txt
$ git stash -u
Saved working directory and index state WIP on master: 1b65b17 added the index file
HEAD is now at 1b65b17 added the index file
$ git status -s
$
Till sist, om du anger flaggan --patch kommer Git inte att lägga undan allt som är ändrat utan i stället fråga interaktivt vilka ändringar du vill lägga undan och vilka du vill behålla i din arbetskatalog.
$ git stash --patch
diff --git a/lib/simplegit.rb b/lib/simplegit.rb
index 66d332e..8bb5674 100644
--- a/lib/simplegit.rb
+++ b/lib/simplegit.rb
@@ -16,6 +16,10 @@ class SimpleGit
return `#{git_cmd} 2>&1`.chomp
end
end
+
+ def show(treeish = 'master')
+ command("git show #{treeish}")
+ end
end
test
Stash this hunk [y,n,q,a,d,/,e,?]? y
Saved working directory and index state WIP on master: 1b65b17 added the index file
Skapa en gren från en undanläggning
Om du lägger undan arbete, lämnar det ett tag och fortsätter på grenen där du lade undan arbetet kan du få problem när du ska återapplicera det. Om appliceringen försöker ändra en fil som du sedan har ändrat får du en sammanslagningskonflikt och behöver försöka lösa den.
Om du vill ha ett enklare sätt att testa de undanlagda ändringarna igen kan du köra git stash branch <nytt grennamn>, vilket skapar en ny gren åt dig med ditt valda grennamn, växlar till incheckningen du var på när du lade undan arbetet, återapplicerar arbetet där och sedan tar bort undanläggningen om den går att återapplicera:
$ git stash branch testchanges
M index.html
M lib/simplegit.rb
Switched to a new branch 'testchanges'
On branch testchanges
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: index.html
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: lib/simplegit.rb
Dropped refs/stash@{0} (29d385a81d163dfd45a452a2ce816487a6b8b014)
Det här är en smidig genväg för att återställa undanlagt arbete och fortsätta i en ny gren.
Städa arbetskatalogen
Till sist kanske du inte vill lägga undan något arbete eller några filer i din arbetskatalog, utan bara bli av med dem; det är vad kommandot git clean är till för.
Några vanliga skäl att städa arbetskatalogen kan vara att ta bort skräp som har skapats av sammanslagningar eller externa verktyg eller att ta bort byggartefakter för att köra en ren byggning.
Du vill vara ganska försiktig med det här kommandot, eftersom det är utformat för att ta bort filer från din arbetskatalog som inte är spårade.
Om du ändrar dig finns det ofta ingen väg tillbaka till innehållet i dessa filer.
Ett säkrare alternativ är att köra git stash --all för att ta bort allt men spara det i en undanläggning.
Om du antar att du vill ta bort skräpfiler eller städa arbetskatalogen kan du göra det med git clean.
För att ta bort alla ospårade filer i din arbetskatalog kan du köra git clean -f -d, vilket tar bort alla filer och även alla underkataloger som blir tomma.
Flaggan -f betyder "tvinga" eller "gör verkligen detta" och krävs om Git-konfigurationsvariabeln clean.requireForce inte uttryckligen är satt till false.
Om du någon gång vill se vad det skulle göra kan du köra kommandot med flaggan --dry-run (eller -n), vilket betyder "gör en torrkörning och berätta vad du skulle ha tagit bort".
$ git clean -d -n
Would remove test.o
Would remove tmp/
Som standard tar git clean bara bort ospårade filer som inte är ignorerade.
Filer som matchar ett mönster i din .gitignore eller andra ignoreringsfiler tas inte bort.
Om du vill ta bort även dessa filer, till exempel för att ta bort alla .o-filer som skapats i en byggning så att du kan göra en helt ren byggning, kan du lägga till -x till kommandot clean.
$ git status -s
M lib/simplegit.rb
?? build.TMP
?? tmp/
$ git clean -n -d
Would remove build.TMP
Would remove tmp/
$ git clean -n -d -x
Would remove build.TMP
Would remove test.o
Would remove tmp/
Om du inte vet vad kommandot git clean kommer att göra, kör det alltid med -n först för att dubbelkolla innan du byter från -n till -f och gör det på riktigt.
Ett annat sätt att vara försiktig med processen är att köra det med flaggan -i eller "interaktiv".
Detta kör clean-kommandot i ett interaktivt läge.
$ git clean -x -i
Would remove the following items:
build.TMP test.o
*** Commands ***
1: clean 2: filter by pattern 3: select by numbers 4: ask each 5: quit
6: help
What now>
På så sätt kan du gå igenom varje fil för sig eller ange mönster för borttagning interaktivt.
|
Notera
|
Det finns en märklig situation där du kan behöva vara extra kraftfull när du ber Git städa din arbetskatalog.
Om du råkar befinna dig i en arbetskatalog där du har kopierat eller klonat andra Git-kodförråd (kanske som undermoduler) kommer |