-
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
4.2 Git på servern - Skaffa Git på en server
Skaffa Git på en server
Nu kommer vi behandla hur man konfigurerar en Gittjänst som använder dessa protokoll på din egen server.
Notera
|
Här kommer vi demonstrera kommandon och steg som krävs för en grundlig och förenklad installation på en Linuxbaserad server, men det är också möjligt att köra dessa på en Mac- eller Windowsserver. Att konfigurera en produktionsserver inom din infrastruktur kommer säkerligen att medföra skillnader i säkerhetsåtgärder och operativsystemsverktyg, men förhoppningsvis kommer detta ge dig en god inblick av vad som är involverat. |
För att börja konfigurera en Gitserver måste du exportera ett existerande repo till ett nytt bart repo — ett repo som inte innehåller en arbetskatalog.
Detta är i regel okomplicerat att göra.
För att klona ditt repo för att skapa ett nytt bart repo, kör du clone-kommandot med flaggan --bare
.
Av konvention namnges alltid en bar repokatalog med suffixet .git
, såhär:
$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.
Du ska nu ha en kopia av Gitkatalogens data i din my_project.git
-katalog.
Detta är ungefär likvädigt med
$ cp -Rf my_project/.git my_project.git
Det finns ett antal mindre skillnader i konfigurationsfiilen, men för ditt ändamål är detta nära samma sak. Den tar Gitrepot i sig själv, utan arbetsträd, och skapar en katalog specifikt för det.
Lägga det Bara repot på en server
Nu när du har en bar kopia av dit repo är allt du behöver göra att lägga den på en server och konfigurera dina protokoll.
Antag att du har konfigurerat en server som kallas git.example.com
dit du har SSH-åtkomst och du vill spara alla dina Gitrepon under katalogen /srv/git
.
Anta att /srv/git
finns på servern kan du konfigurera ditt nya repo genom att bara kopiera över ditt bara repo:
$ scp -r my_project.git user@git.example.com:/srv/git
När detta är gjort, kan andra användare som har SSH-baserad läsrättighet till /srv/git
-katalogen på den servern klona ditt repo genom
$ git clone user@git.example.com:/srv/git/my_project.git
Om en användare SSH:ar in till en server och skrivrättigheter i /srv/git/my_project.git
-katalogen kommer de också automatiskt ha rättigheter att skicka upp data till repot.
Gitt kommer automatiskt lägga till gruppskrivrättigheter till ett repo ordentligt om du kör git init
med flaggan --shared
.
Notera att du inte kommer att förstöra några versioner, referenser, etc. genom att göra detta.
$ ssh user@git.example.com
$ cd /srv/git/my_project.git
$ git init --bare --shared
Du ser hur enkelt det är att ta ditt Gitrrepo, skapa en bar kopia och placera det på en server dit du och dina medarbetare har SSH-åtkomst. Nu är du redo att samarbeta på samma projekt.
Det är viktigt att poängera att detta bokstavligen är allt du behöver göra för att köra en användbar Gitserver dit flera användare har åtkomst — bara lägg till SSH-tillåtna användare på en server och lägg ett bart repo nånstans dit alla användare har läs- och skrivrättigheter. Du är färdig — inget annat behövs.
I kommande avsnitt kommer du få se hur man kan utöka till mera sofistikerade konfigurationer. Diskussioner kommer inkludera att inte behöva skapa användarkonto för varje användare, lägga till publika läsrättigheter till repon och konfigurera grafiska webbgränssnitt och mer. Ha dock alltid i åtanke att för att samarbeta med ett par människor på ett privat projekt, är allt du behöver enn SSH-server och ett bart repo.
Små uppsättningar
Om du vill köra i liten skala eller bara testar Git i din organisation och bara har ett fåtal utvecklare kan det vara enkelt för dig. En av de mest komplicerade aspekterna av att konfigurera en Gitserver är användarhantering. Om du vill att några repon skall vara enbart läsbara för några användare men även skrivbara för andra så kan behörighets- och rättighetskonfiguration vara lite svårare att hantera.
SSH-åtkomst
Om du har en server dit alla dina utveckare redan har SSH-åtkomst är det generellt sett enklare att konfigurera ditt första repo där, eftersom du nästan inte behöver göra något (som vi beskrev i senaste avsnittet). Om du vill ha mer komplex rättighetssyrning på dina repon kan du hantera det med filsystemsrättigheter på din servers operativsystem.
Om du vill lägga dina repon på en server som inte har användarkonton för alla i ditt team som du vill ge skrivrättigheter till, måste du sätta upp SSH-åtkomst för dem. Vi antar att om du har en server att göra dett detta på, har du redan en SSH-server installerad och det är så du kommer åt servern.
Det finns några sätt du kan ge åtkomst till alla i ditt team.
Det första är att konfigurera konton för alla, vilket är enkelt men kan vara omständligt.
Du kanske inte vill köra adduser
(eller det möjliga alternativet useradd
) och ställa in temporära lösenord för varje ny användare.
En andra metod är att skapa ett enkelt git-användarkonto på maskinen och be alla användare som har skrivrättigheter att skicka dig sin publika SSH-nyckel och att lägga till den till ~/.ssh/authorized_keys
-filen ov det nya git-användarkontot.
Efter det kommer alla åt maskinen via git-användarkontot.
Detta påverar inte versionsdatan på något sätt — SSH-användaren du ansluter som påverkar inte versionerna du har sparat.
Ett annat sätt att göra på är att låta din SSH-server autentisera från en LDAP-server eller någon annan centraliserad autentiseringskälla som du kanske redan har konfigurerat. Så länge som varje användare kan få skalåtkomst på maskinen bör alla SSH-autentiseringsmekanismer du kan tänka på fungera.