-
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
-
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
5.1 Distribuerade Git - Distribuerade arbetsflöden
Nu nÀr du har ett fjÀrrarkiv för Git instÀllt som en hub för samtliga utvecklare, och du Àr bekant med grundlÀggande Git-kommandon lokalt, ska vi titta pÄ hur man anvÀnder nÄgra av de distribuerade arbetsflöden som Git erbjuder.
I det hÀr kapitlet kommer du att lÀra dig att arbeta med Git i en distribuerad miljö, bÄde som bidragslÀmnare och förvaltare. Du kommer alltsÄ att lÀra dig hur du framgÄngsrikt bidar med kod till ett projekt och gör det sÄ enkelt för dig och den som underhÄller projektet som möjligt, samt hur du framgÄngsrikt förvaltar ett projekt med flera utvecklare som bidrar.
Distribuerade arbetsflöden
Till skillnad frÄn centraliserade versionshanteringssystem (CVCS) tillÄter Gits distribuerade natur mer flexibilitet nÀr utvecklare ska samarbeta. I centraliserade system Àr varje utvecklare en nod som arbetar mer eller mindre likvÀrdigt mot ett nav. I Git dÀremot, kan varje utvecklare bÄde en nod och ett nav samtidigt; varje utvecklare kan parallellt bidra med kod till andras arkiv och sjÀlv underhÄlla ett öppet arkiv som andra kan bidra till. Det öppnar upp för en mÀngd olika möjligheter att organisera samarbetet i ditt projekt och/eller i ditt team. Vi kommer att titta nÀrmare pÄ nÄgra vanliga processer som drar nytta av den hÀr flexibiliteten. Vi gÄr igenom bÄde styrkor och svagheter för varje arbetsprocess; du kan vÀlja att anvÀnda en enda eller blanda och matcha de finesser som verkar passa bÀst.
Centraliserad arbetsprocess
Centraliserade system har i stort sett en enda samarbetsmodellâââden centraliserade arbetsprocessen. Ett nav, eller arkiv, accepterar kod frĂ„n utvecklarna, som alla synkroniserar sitt arbete mot det. Utvecklarna Ă€r noder till den centrala enheten.
Det innebÀr att om tvÄ utvecklare klonar navet och gör Àndringar, sÄ kan den första utvecklaren som skickar upp sina Àndringar göra det utan problem. Den andra utvecklaren mÄste dÀremot sammanfoga den första utvecklarens arbete innan den skickar upp sina Àndringar, annars kommer de nya Àndringarna att skrivas över. Det Àr likadant i Git som i Subversion (eller nÄgot annat CVCS), och i Git fungerar modellen utmÀrkt.
Om du redan Àr bekvÀm med en centraliserad arbetsprocess i ditt företag eller team kan du enkelt fortsÀtta anvÀnda den i Git. Det Àr bara att sÀtta upp ett enda arkiv och ge alla i teamet skrivbehörighet; Git kommer inte att lÄta anvÀndare skriva över varandras arbeten.
LÄt oss sÀga att John och Jessika bÄda börjar arbeta samtidigt. John avslutar sina Àndringar och skickar upp dem till servern. Sen försöker Jessika att skicka upp sina, men servern avvisar dem. Hon fÄr veta att hon försöker skicka upp Àndringar som inte kan snabbspolas, och att hon inte kommer att kunna göra det förrÀn hon först hÀmtar och sammanfogar incheckade Àndringar. Detta arbetsflöde Àr tilltalande för mÄnga eftersom det Àr ett tillvÀgagÄngssÀtt mÄnga Àr bekanta och bekvÀma med.
Det Àr heller inte begrÀnsat till smÄ team. Gits grenmodell gör det möjligt för hundratals utvecklare att arbeta framgÄngsrikt pÄ ett enda projekt genom dussintals grenar pÄ en och samma gÄng.
Integrationsstyrd arbetsprocess
Eftersom Git tillĂ„ter dig att ha flera fjĂ€rrarkiv Ă€r det möjligt att med ett arbetsflöde dĂ€r varje utvecklare har skrivbehörighet till sitt eget öppna arkiv och lĂ€sbehörighet till andras. Detta scenario inkluderar ofta ett arkiv som representerar det âofficiellaâ projektet. För att bidra till det projektet gör du en öppen klon av det som du skickar dina Ă€ndringar till. Sen kan du skicka en förfrĂ„gan till den som förvaltar det officiella projektet att hĂ€mta dina Ă€ndringar. Förvaltaren kan dĂ„ lĂ€gga till ditt arkiv som ett fjĂ€rrarkiv, testa dina Ă€ndringar lokalt, sammanfoga dem i sin gren och skicka till det officiella arkivet. Processen ser ut sĂ„ hĂ€r (se Integrationssstyrt arbetsflöde.):
-
Förvaltaren skickar till sitt öppna arkiv.
-
En deltagare klonar arkivet och gör Àndringar.
-
Deltagaren skickar sina Àndringar till sin egna öppna klon.
-
Deltagaren skickar ett e-postmeddelande till förvaltaren och ber denne att hÀmta Àndringarna.
-
Förvaltaren lÀgger till deltagarens arkiv som ett fjÀrrarkiv och slÄr ihop Àndringarna lokalt.
-
Förvaltaren skickar de sammanslagna Àndringarna till det officiella arkivet.
Detta Ă€r ett mycket vanligt arbetsflöde som anvĂ€nds av verktyg som GitHub eller GitLab, dĂ€r det Ă€r enkelt att förgrena ett projekt och skicka upp sina Ă€ndringar. En av de största fördelarna med detta tillvĂ€gagĂ„ngssĂ€tt Ă€r att du kan fortsĂ€tta att arbeta vidare, och den som underhĂ„ller det officiella arkivet kan hĂ€mta in dina Ă€ndringar nĂ€r som helst. BidragslĂ€mnaren behöver inte vĂ€nta pĂ„ att Ă€ndringarna ska slĂ„s samman innan hen kan börja pĂ„ nĂ„got nyttâââvarje part kan istĂ€llet arbeta i sin egen takt.
Diktatorns och löjtnanternas arbetsflöde
Diktatorns och löjtnanternas arbetsflöde Àr en variant av ett flerarkivsarbetsflöde. Det anvÀnds vanligtvis i stora projekt med hundratals medarbetare; ett kÀnt exempel Àr LinuxkÀrnan. DÀr har integrationsansvariga hand om varsin del av arkivet; de kallas löjtnanter. Löjtnanterna har en gemensam integrationsansvarig som kallas den vÀlvillige diktatorn. Den vÀlvillige diktatorn Àr den enda med skrivrÀttigheter till det heliga referensarkiv, som alla medverkande hÀmtar kod frÄn. Flödet fungerar sÄ hÀr (se Den vÀlvillige diktatorns arbetsflöde.):
-
Utvecklarna arbetar pĂ„ sina egna funktionsgrenar och ombaserar sitt arbete till toppen av âmasterâ. âMasterâ-grenen Ă€r det referensarkiv som endast diktatorn skickar Ă€ndringar till.
-
Löjtnanterna slĂ„r samman utvecklarnas funktionsgrenar med sina respektive âmasterâ-grenar.
-
Diktatorn slĂ„r samman löjtnanternas âmasterâ-grenar med sin egen âmasterâ-gren.
-
Slutligen skickar diktatorn sin âmasterâ-gren till referensarkivet, sĂ„ att de andra utvecklarna kan ombasera frĂ„n den.
Det hÀr arbesflödet Àr inte sÄ vanligt, men kan vara anvÀndbart i mycket stora projekt eller hierarkiska miljöer. Det gör det möjligt för projektledaren (diktatorn) att delegera mycket av arbetet och samla stora kodÀndringsuppsÀttningar innan de integreras.
Sammanfattning av arbetsflöden
Det hÀr Àr nÄgra av de vanligaste arbetsflödena i distribuerade system, som till exempel Git, men det Àr möjligt att anpassa dem efter specifika omstÀndigheter i ett projekt. Nu nÀr du (förhoppningsvis) kan avgöra vilken kombination av arbetsflöden som kan fungera för dig, kommer vi att gÄ igenom nÄgra mer specifika exempel pÄ hur du kan utföra de huvudsakliga rollerna som ingÄr i processerna. I nÀste avsnitt kommer du att lÀra dig om nÄgra vanliga tillvÀgagÄngssÀtt för att bidra till ett projekt.