-
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. Distributed Git
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Summary
-
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
1.1 Kom igång - Om versionshantering
Detta kapitel kommer att handla om hur du kommer igång med Git. Vi börjar med en liten introduktion till versionshanteringsverktyg, sedan går vi vidare med hur du får igång Git på din dator, och slutligen hur du kan börja använda det. I slutet av kapitlet skall du förstå varför Git finns, varför det skall användas och du skall vara redo att kunna använda det.
Om versionshantering
Vad är “versionshantering”, och varför skall du bry dig? Ett versionshanteringsverktyg är ett program som håller reda på ändringar i en eller flera filer över tid så att du kan återskapa specifika versioner vid en senare tidpunkt. I exemplena i denna boken, kommer du att använda källkod som de filer som skall versionshanteras, men i verkligheten kan du göra samma sak med nästan vilken typ av fil som helst på en dator.
Om du är grafiker eller webdesigner och vill spara varje version av en bild eller layout (vilket du med största sannolikt vill), så är ett versionshanteringssysttem (VCS, efter engelskans “Version Control System”) en bra sak att använda. Det tillåter dig att återskapa valda filer eller hela projekt till ett tidigare tillstånd, jämföra ändringar över tid, se vem som senast ändrade något som kan ge upphov till ett problem, vem som introducerade ett fel och när, samt mycket mer. Att använda ett VCS betyder även att om du klantar till det eller förlorar filer, så kan du i regel med lätthet återställa allt. Allt detta får du utan att det ger speciellt mycket merarbete.
Lokala versionshanteringssystem
Många väljer att kopiera filer till ett annan mapp för som en primitiv versionshanteringsmetod (förslagsvis en mapp med aktuell tid i namnet, om man har tänkt till). Detta arbetssätt är mycket vanligt för att det är så enkelt, men det är också väldigt felkänsligt. Det är lätt att glömma vilken mapp du är i och råkar skriva till fel fil eller skriver över filer som du inte hade tänkt.
För att hantera detta problem, utvecklade programmerare för längesedan lokala VCS som hade en simpel databas för att hålla koll på ändrigarna i filerna som var versionshanterade.
En av de mer populära VCS-verktygen var ett system som kallades RCS, vilket än idag distribueras med många datorer. RCS arbetar genom att hålla reda på s.k. patchar (d.v.s. skillnader mellan filer) i ett speciellt format på hårddisken; det kan återskapa hur en fil såg ut vid en speciell tidpunkt genom att summera de olika patcharna.
Centraliserade Versionshanteringssystem
Nästa stora problem folk stöter på är när de skall samarbeta med andra utvecklare på andra system. För att hantera detta problem utvecklade man centrala versionshanteringssystem (CVCS). Dessa system (som t.ex. CVS, Subversion, och Perforce) har en enda server som innehåller alla versionshanterade filer och ett antal klienter som checkar ut filer från den centrala servern. Under många år var detta det vanligaste sättet att versionshantera.
Denna setup ger många fördelar, speciellt över lokala VCS. Till exempel så vet alla, till viss del, vad andra gör i projektet. Administratörer har detaljerad kontroll över vem som kan göra vad, och det är betydligt enklare att administrera ett centralt system än att hantera lokala databaser på varje klient.
Dock har denna setup några verkliga tillkortakommanden. Den mest uppenbara är den felkritiska del som en enda central server utgör. Om servern går ner under en timme så kan ingen samarbeta alls eller spara versionshanterade ändringar av något de jobbar med för tillfället. Om hårddisken på servern blir korrupt eller skadas, och att inga säkerhetskopior har sparats, så förloras allt — hela projektets historik, förutom enstaka versioner som folk råkar ha på sina lokala maskiner. Lokala versionshanteringssystem lider av samma problem — om hela projektets historik finns lagrat på ett enda ställe, riskerar man att förlora allt.
Distribuerade Versionshanteringssystem
Det är här distribuerade versionshanteringssystem (DVCS) kommer in. I ett sådant system, checkar klienterna inte ut den senaste versionen av filerna; istället speglar de hela förvaret, inklusive all historik. Således, om en server dör och systemen samarbetar via den servern, så kan vilken som helst av klienternas förvar kopieras upp till servern för att återställa den. Varje klon är i själva verket en fullständig säkerhetskopia av all data.
Vidare hanterar dessa systemen ganska bra med att ha flera fjärrförvar som de kan jobba med, så du kan samarbeta med olika personer på olika sätt samtidigt inom samma projekt. Detta ger möjligheten att använda sig av olika arbetsflöden som inte är möjliga med centrala system, som t.ex. hierarkiska modeller.
