-
1. Kom igång
- 1.1 Om versionshantering
- 1.2 En kort historik av Git
- 1.3 Vad är Git?
- 1.4 Kommandoraden
- 1.5 Installera Git
- 1.6 Använda Git för första gången
- 1.7 Få hjälp
- 1.8 Sammanfattning
-
2. Grunder i Git
- 2.1 Skaffa ett Git-förvar
- 2.2 Spara ändringar till förvaret
- 2.3 Visa historiken
- 2.4 Ångra saker
- 2.5 Jobba med fjärrförvar
- 2.6 Taggning
- 2.7 Git alias
- 2.8 Sammanfattning
-
3. Git förgreningar
- 3.1 Grenar i ett nötskal
- 3.2 Grundläggande förgrening och sammanslagning
- 3.3 Hantera grenar
- 3.4 Arbetsflöde med grenar
- 3.5 Fjärrgrenar
- 3.6 Grenflytt
- 3.7 Sammanfattning
-
4. Git på servern
- 4.1 Protokollen
- 4.2 Skaffa Git på en server
- 4.3 Generera din publika SSH-nyckel
- 4.4 Konvigurera servern
- 4.5 Git Daemonen
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Alternativ tillhandahållna av tredje part
- 4.10 Sammanfattning
-
5. Distribuerade Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 Summary
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Summary
-
A1. Bilaga A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in PowerShell
- A1.7 Summary
-
A2. Bilaga B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Bilaga C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
2.4 Grunder i Git - Ångra saker
Ångra saker
Det finns tillfällen då du kanske vill ångra något. Här kommer vi att titta på några få grundläggande verktyg för att ångra ändringar du gjort. Var försiktig, för att du kan inte alltid ångra något som du ångrat. Detta är ett av några få områden i Git där du faktiskt kan förlora något om du gör det fel.
En av de vanligaste sakerna man vill ångra är ifall du sparar en version för tidigt och kanske glömmer att lägga till filer, alternativt om du skriver fel i ditt versionsmeddelande.
Om du vill göra om versionen, göra ytterligare ändringar, preparera dem och skapa en ny version igen, så kan du använda valet --amend
:
$ git commit --amend
Kommandot tar din preparationsyta och använder den för versionen. Om du inte gjort några ändringar sedan din förra version (till exempel om du kör kommandot direkt efter att du skdapat en version) kommer ögonblicksbilden att se identisk ut, och allt du kan ändra är ditt versionsmeddelande.
Samma editor som du använde när du gjorde din förra version öppnas, men den innehåller då ditt förra versionsmeddelande. Du kan ändra meddelandet som alltid, men det skriver över din tidigare sparade version.
Som exempel, om du sparar en version och sedan inser att du glömde lägga till ändringar i en fil du ville ha med i versionen så kan du göra något liknande detta:
$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend
I slutändan får du en enda version — den andra versionen ersätter resultatet av den första.
Notera
|
Det är viktigt att förstå att när du gör ett tillägg till din senaste version, så ersätter du egentligen din gamla version med en helt ny, förbättrad version som knuffar undan den gamla versionen och lägger den nya versionen i dess ställe. I praktiken är det som att den föregående versionen aldrig fanns, och den kommer inte heller att visas i din versionshistorik. Det uppenbara värdet i att göra tillägg på detta sätt är att göra mindre förbättringar till din senaste version utan att kladda ner din versionshistorik med meddelanden som “Hoppsan, glömde lägga till en fil” eller “Skit också, tryckfelsnisse i senaste versionen”. |
Ångra en preparerad fil
Kommande två avsnitt demonstrerar hur man arbetar med prepareringsytan och ändringar i arbetskatalogen.
Det trevliga är att kommandot du använder för att avgöra statusen på de två ytorna även påminner om hur man gör ändringar ogjorda till dem.
Till exempel, säg att du har ändrat två filer och vill spara dem som två separata ändringar, men du har av misstag skrivit git add *
och markerat båda att ingå i din nästa version.
Hur kan du markera en av dem som oförbredd?
Kommandot git status
påminner dig:
$ git add *
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
modified: CONTRIBUTING.md
Under texten “Changes to be committed” (Ändringar att spara) står det git reset HEAD <file>...
för att markera filen som oförberedd.
Låt oss använda det rådet och flagga filen CONTRIBUTING.md
som oförberedd:
$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> 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
Kommandot är lite märkligt, men fungerar.
Filen CONTRIBUTING.md
är modifierad men återigen inte förberedd för nästa version.
Notera
|
Det är sant att |
För nu är denna magiska användning allt du behvöver veta om kommandot git reset
.
Vi kommer att gå in i mer detalj kring vad reset
gör och hur man använder det för att göra mycket intressanta saker i Reset Demystified.
Återställa en modifierad fil
Vad gör du om du inser att du inte vill behålla ändringarna i CONTRIBUTING.md
?
Hur kan man återställa den — återställa till så den såg ut i din senast sparade version (eller klonade, eller hur du nu fick in den i din arbetskatalog)?
Som tur är ger git status
oss en fingervisning om detta också.
I förra exempelutskriften så såg det ut såhär:
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
Den talar uttryckligen om hur du kastar bort ändringarna som du gjort. Låt oss pröva:
$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
renamed: README.md -> README
Du kan se att ändringarna nu är borta.
Viktigt
|
Det är viktigt att förstå att |
Om du vill behålla ändringarna i filen men bara vill få dem ur vägen för nu, så kommer vi att gå igenom gömman och förgreningar i Git förgreningar; dessa är generellt sätt bättre vägar att ta.
Kom ihåg att allt som är sparat i en version (commit) i Git nästan alltid kan återskapas.
Även versioner som var på grenar som tagits bort, eller versioner som skrivits över med flaggan --amend
kan återskapas (se Data Recovery för återställning av data).
Dock, det som du förlorar som aldrig sparats i en version kommer sannolikt aldrig mer se dagens ljus.