-
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
4.8 Git på servern - GitLab
GitLab
GitWeb är dock ganska primitivt. Om du är ute efter en mer modern, fullutrustad Gitserver finns det några öppen källkods-alternativ där ute som du kan installera istället. Eftersom GitLab är en av de mer populära, behandlar vi installation och användning av det som exempel. Detta är lite mer komplicerat än GitWeb-alternativet och kräver troligtvis mer underhåll, men det är ett mycket mer utrustat alternativ.
Installation
GitLab är en databasbackad webbapplikation, så dess installation är lite mer krävande än andra Gitservrar. Lyckligtvis är denna processen väldigt väldokumenterad och underhållen.
Det finns ett antal vägar du kan ta för att installera GitLab. För att få igång något snabbt, kan du ladda ner en virtuell maskin-avbild eller ett en-klicks-installationsprogram från https://bitnami.com/stack/gitlab, och modifiera konfigurationen för att passa din miljö. Ett trevligt som Bitnami har inkluderat är inloggningsskärmen (som man kommer åt med alt+→); den ger dig IP-adressen och standardanvändarnamnet och lösenordet för det installerade GitLab.
För allt annat, följ guiden i Readme för GitLab Community Edition, vilken du finner på https://gitlab.com/gitlab-org/gitlab-ce/tree/master. Där hittar du också hjälp för att installera GitLab via Chef-recept, en virtuell maskin på Digital Ocean, och RPM- samt DEB-paket (vilket, vid tiden för författandet, är i betaversion). Det finns också “inofficiella” guider för hur man får igång GitLab med ovanliga operativsystem och databaser, ett fullt manuellt installationsskript, och många andra saker.
Administration
GitLabs administrationsgränssnitt nås över webben.
Via din webbläsare, gå till datornamnet eller IP-adressen för den dator där GitLab är installerat och logga in som en admin-användare.
Standardanvändarnamnet är admin@local.host
och standardlösenordet är 5iveL!fe
(som du kommer bli påbjuden att ändra så fort du skriver in det).
När du väl loggat in, klicka på menyalternativet “Admin area” i menyn uppe till höger.
Användare
Användare i GitLab är konton som motsvarar personer.
Användarkonton är inte så komplicerade; i huvudsak är det en samling personlig information bunden till inloggningsdata.
Varje användarkonto har en namnrymd, som är en logisk gruppering av projekt som tillhör den användaren.
Om användaren jane
har ett projekt som heter project
så är det projektets URL http://server/jane/project
.
Man kan ta bort en användare på två sätt. “Blockering” av en användare förhindrar att de loggar in på GitLabinstansen, men all data under den användarens namnrymd finns bevarad, och versioner som är signerade med den användarens epostadress länkar fortfarande till deras profil.
“Radering” av en användare å andra sidan, tar bort dem från både databasen och filsystemet. Alla projekt och data i deras namnrymd tas bort, och alla grupper de äger kommer också att tas bort. Detta är således en mycket mer permanent och destruktiv handling, och används därför sällan.
Grupper
En GitLab-grupp är en samling av projekt tillsammans med data om hur användare kan nå de projekten.
Varje grupp har en projektnamnrymd (på samma sätt som användare), så om gruppen training
har ett projekt materials
, kommer dess URL att vara http://server/training/materials
.
Varje grupp är associerad med ett antal användare, som var och en har en nivå av rättigheter för gruppens projekt och gruppen i sig. Dessa spänner från “Guest” (enbart arbetspaket och chat) till “Owner” (full kontroll över gruppen, dess medlemmar och dess projekt). De olika rättigheterna är för många för att lista här, men GitLab har en hjälpsam länk på administrationsskärmen.
Projekt
Ett GitLabprojekt motsvarar grovt mot ett enskilt Gitrepo. Varje projekt tillhör en enda namnrymd, antingen en användare eller en grupp. Om projektet tillhör en en användare, har ägaren av projektet direkt kontroll över vem som har åtkomst till projektet; om projektet tillhör en grupp, spelar även gruppens användarnivåbehörigheter roll.
Varje projekt har en synlighetsnivå, som kontrollerar vem som har läsåtkomst till projektets sidor och repo.
Om ett projekt är Private, måste projektets ägare explicit ge åtkomst till specifika användare.
Ett projekt som är Internal är synligt för alla inloggade anbvändare, medan projekt som är Public är synliga för alla.
Notera att denna kontrollerar både git fetch
-åtkomst såväl som åtkomst till webbgränssnittet för det projektet.
Krokar
GitLab har stöd för krokar både på projekt- och systemnivå. Oavsett vilken kommer GitLabservern att utföra ett HTTP POST-anrop med en beskrivande JSON när en relevant händelse inträffar. Detta är ett förträffligt sätt att koppla dina Gitrepon och GitLabinstansen till resten av din utvecklingsautomation, såsom CI-servrar, chatrum eller distributionsverktyg.
Grundläggande användning
Det första du kommer vilja göra med GitLab är att skapa ett nytt projekt. Detta gör du genom att klicka på ikonen “+” i verktygsfältet. Du kommer bli ombedd att ange projektets namn, vilken namnrymd det skall tillhöra och vad dess synlighetsnivå skall vara. Det mesta du anger här är inte permanent och kan justeras senare genom inställningsgränssnittet. Klicka på “Create Project”, och sedan är du klar.
Så fort projektet finns så vill du säkert ansluta det med ett lokalt Gitrepo.
Varje projekt är nåbart över HTTPS eler SSH, som båda kan användas för att konfigurera ett fjärrepo.
URL:erna är synliga vid toppen av projektets hemsida.
För ett existerande lokalt repo, kommer följande kommando att skapa ett repo benämnt gitlab
till värdplatsen:
$ git remote add gitlab https://server/namespace/project.git
Om du inte har en lokal kopia av repot, kan du helt enkelt göra såhär:
$ git clone https://server/namespace/project.git
Webbgränssnittet tillhandahåller åtkomst till flera användbara vyer av repot självt. På varje projekts hemsida visas senaste aktivitet, och länkar i toppen leder dig till vyer över peojektets filer och versionslogg.
Arbeta tillsammans
Det enklaste sättet att arbeta tillsammans på ett GitLabprojekt är genom att ge en annan användare direkt skrivrättighet till Gitrepot. Du kan lägga till en användare till ett projekt genom att gå till delen “Members” i projektet inställningar och associera den nya användaren med enn åtkomstnivå (skillnaden mellan åtkomstnivåer diskuteras i Grupper). Genom att ge en användare åtkomstnivån “Developer” eller över, kan den användaren villkorslöst skicka upp versioner och grenar direkt till repot.
Ett annat, mer frikopplat sätt att samarbeta är att använda sammanslagningsbegäran.
Denna funktion ger vilken användare som helst som kan se projektet möjlighet att bidra till det på ett kontrollerat sätt.
Användare med direkt åtkomst kan helt enkelt skapa en gren, skicka versioner till den och öppna en sammanslagningsbegäran från sin gren tillbaks in till master
eller någon annan gren.
Användare som inte har skrivrättigheter fölr ett repo kan “klyva” repot (skapa sin egen kopia), skicka versioner till den kopian, och sedan öppna en sammanslagningsbegäran från deran gren tillbaks in till huvudprojektet.
Denna modellen ger ägaren möjlighet att ständight ha full kontroll av vad som kommer in i repot och när, samtidigt som man tillåter bidrag från opålitliga användare.
Sammanslagningsbegäran och felrapporter är huvuddelarna i långlivade diskussioner i GitLab. Varje sammanslagningsbegäran tillåter rad-för-rad-diskussion av den föreslagna ändringen (som stödjer en enkel form av kodgranskning), så väl som generell översiktlig disussion. Båda kan tilldelas användare, eller organiseras i milstolpar.
Detta avsnitt fokuserade huvudsakligen på Git-relaterade funktioner av GitLab, men som ett moget projekt har den många andra verktyg för att hjälpa ditt team att jobba tillsammans såsom projektwikisidor och sytemunderhållningsverktyg. En fördel med GitLa är att när väl Servern är uppe och kör, behöver du sällan modifiera en konfigurationsfil eller läsrättigheter till servern via SSH; den mesta administrationen och generell användning kan ske via webbläsarfönstret.