-
1. Kom igång
- 1.1 Om versionshantering
- 1.2 En kort historik om Git
- 1.3 Vad är Git?
- 1.4 Kommandoraden
- 1.5 Installera Git
- 1.6 Första gången med Git
- 1.7 Få hjälp
- 1.8 Sammanfattning
-
2. Grunderna i Git
- 2.1 Att få tag i ett Git‑kodförråd
- 2.2 Spara ändringar i kodförrådet
- 2.3 Visa incheckningshistoriken
- 2.4 Ångra saker
- 2.5 Arbeta med fjärrkodförråd
- 2.6 Att tagga
- 2.7 Git-alias
- 2.8 Sammanfattning
-
3. Git-grenar
- 3.1 Grenar i korthet
- 3.2 Grundläggande gren- och sammanfogningsarbete
- 3.3 Grenhantering
- 3.4 Arbetsflöden med grenar
- 3.5 Fjärrgrenar
- 3.6 Ombasering
- 3.7 Sammanfattning
-
4. Git på servern
- 4.1 Protokollen
- 4.2 Konfigurera Git på en server
- 4.3 Generera din publika SSH-nyckel
- 4.4 Konfigurera servern
- 4.5 Git-demon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Tredjepartsalternativ
- 4.10 Sammanfattning
-
5. Distribuerat Git
-
6. GitHub
-
7. Git-verktyg
- 7.1 Revisionsurval
- 7.2 Interaktiv köläggning
- 7.3 Lägga undan och städa
- 7.4 Signera ditt arbete
- 7.5 Sökning
- 7.6 Skriva om historik
- 7.7 Nollställning förklarad
- 7.8 Avancerad sammanslagning
- 7.9 Rerere
- 7.10 Felsöka med Git
- 7.11 Undermoduler
- 7.12 Bunta
- 7.13 Ersätt
- 7.14 Lagring av inloggningsuppgifter
- 7.15 Sammanfattning
-
8. Anpassa Git
- 8.1 Git‑konfiguration
- 8.2 Git‑attribut
- 8.3 Git‑krokar
- 8.4 Ett exempel på Git‑upprätthållen policy
- 8.5 Sammanfattning
-
9. Git och andra system
- 9.1 Git som klient
- 9.2 Migrera till Git
- 9.3 Sammanfattning
-
10. Git bakom kulisserna
- 10.1 Lågnivådel och användardel
- 10.2 Git-objekt
- 10.3 Git-referenser
- 10.4 Packfiler
- 10.5 Refspecen
- 10.6 Överföringsprotokoll
- 10.7 Underhåll och dataåterställning
- 10.8 Miljövariabler
- 10.9 Sammanfattning
-
A1. Bilaga A: Git i andra miljöer
- A1.1 Grafiska gränssnitt
- A1.2 Git i Visual Studio
- A1.3 Git i Visual Studio Code
- A1.4 Git i IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git i Sublime Text
- A1.6 Git i Bash
- A1.7 Git i Zsh
- A1.8 Git i PowerShell
- A1.9 Sammanfattning
-
A2. Bilaga B: Bädda in Git i dina applikationer
- A2.1 Git på kommandoraden
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Bilaga C: Git-kommandon
- A3.1 Uppstart och konfiguration
- A3.2 Skaffa och skapa projekt
- A3.3 Grundläggande ögonblicksbilder
- A3.4 Grening och sammanslagning
- A3.5 Dela och uppdatera projekt
- A3.6 Inspektion och jämförelse
- A3.7 Felsökning
- A3.8 Patchning
- A3.9 E‑post
- A3.10 Externa system
- A3.11 Administration
- A3.12 Lågnivåkommandon
4.2 Git på servern - Konfigurera Git på en server
Konfigurera Git på en server
Nu går vi igenom hur du sätter upp en Git-tjänst med protokoll på din egen server.
|
Notera
|
Här visar vi kommandon och steg för en grundläggande, förenklad installation på en Linuxbaserad server, men det går också att köra tjänsterna på en macOS- eller Windows-servrar. Att sätta upp en produktionsserver i din infrastruktur innebär förstås skillnader i säkerhetsåtgärder och verktyg, men förhoppningsvis ger detta en tydlig bild av vad som krävs. |
För att komma igång behöver du exportera ett befintligt kodförråd till ett nytt bart kodförråd – ett kodförråd utan arbetskatalog.
Det är i regel okomplicerat.
För att klona ditt kodförråd till ett nytt bart kodförråd kör du clone med flaggan --bare.
Av konvention slutar namnet på ett bart kodförråd med .git, till exempel:
$ git clone --bare my_project my_project.git
Cloning into bare repository 'my_project.git'...
done.
Nu har du en kopia av Git-datan i my_project.git.
Det motsvarar ungefär:
$ cp -Rf my_project/.git my_project.git
Det finns några mindre skillnader i konfigurationsfilen, men för ditt ändamål är det i praktiken samma sak. Det tar kodförrådet utan arbetskatalog och skapar en särskild katalog för det.
Lägg det bara kodförrådet på en server
När du har en bar kopia återstår att lägga den på en server och konfigurera protokollen.
Anta att du har en server som heter git.example.com där du har SSH-åtkomst och vill lägga alla Git-kodförråd under /srv/git.
Om /srv/git finns kan du skapa det nya kodförrådet genom att kopiera upp det:
$ scp -r my_project.git user@git.example.com:/srv/git
Nu kan andra användare som har SSH-baserad läsbehörighet till /srv/git klona kodförrådet med:
$ git clone user@git.example.com:/srv/git/my_project.git
Om en användare loggar in via SSH och har skrivrättigheter till /srv/git/my_project.git kan hen också skicka.
Git lägger automatiskt till gruppskrivrättigheter om du kör git init med --shared.
Det förstör inga incheckningar eller referenser.
$ ssh user@git.example.com
$ cd /srv/git/my_project.git
$ git init --bare --shared
Du ser hur enkelt det är: ta ett kodförråd, skapa en bar version och lägga den på en server som du och dina medarbetare når via SSH. Nu kan ni samarbeta i samma projekt.
Det är viktigt att förstå att det här i praktiken är allt som krävs för att köra en användbar Git-server dit flera personer har åtkomst – lägg till SSH-konton och lägg ett bart kodförråd där alla har läs- och skrivbehörighet. Klart.
I nästa avsnitt går vi igenom mer avancerade uppsättningar. Det inkluderar att slippa skapa användarkonton för varje person, lägga till offentlig läsåtkomst, webbaserade gränssnitt och mer. Men för att samarbeta med ett par personer i ett privat projekt är allt du behöver en SSH-server och ett bart kodförråd.
Små uppsättningar
Om ni är ett litet team eller bara provar Git i organisationen och har få utvecklare kan det vara väldigt enkelt. En av de mer komplexa delarna är användarhantering. Om du vill att vissa kodförråd ska vara läsbara för några och läs/skriv för andra kan behörigheter bli mer pilliga.
SSH-åtkomst
Om du redan har en server där alla utvecklare har SSH-åtkomst är det vanligtvis enklast att sätta upp det första kodförrådet där, eftersom du knappt behöver göra något (som vi beskrev nyss). Om du behöver mer detaljerad åtkomstkontroll kan du hantera det via filrättigheterna i serverns operativsystem.
Om du vill lägga kodförråden på en server som inte har konton för alla som ska få skrivrättigheter måste du sätta upp SSH-åtkomst för dem. Vi antar då att SSH redan finns och att det är så du når servern.
Det finns några sätt att ge åtkomst till alla i teamet.
Det första är att skapa konton för alla, vilket är enkelt men kan bli krångligt.
Du kanske inte vill köra adduser (eller useradd) och sätta temporära lösenord för varje ny användare.
En andra metod är att skapa ett gemensamt användarkonto, till exempel git, och be alla som ska ha skrivrättigheter att skicka sin publika SSH-nyckel.
Du lägger nycklarna i ~/.ssh/authorized_keys för kontot git.
Då kan alla ansluta via git-kontot.
Det påverkar inte incheckningsdata – vilken SSH-användare du ansluter som påverkar inte incheckningarna.
Ett tredje sätt är att låta SSH-servern autentisera mot LDAP eller en annan central källa som du redan använder. Så länge varje användare kan få skalåtkomst på maskinen fungerar i stort sett vilken SSH-autentiseringsmekanism som helst.