-
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
10.5 Git bakom kulisserna - Refspecen
Refspecen
Genom hela boken har vi använt enkla mappningar från fjärrgrenar till lokala referenser, men de kan också vara mer komplexa. Anta att du följde med i de senaste avsnitten och skapade ett litet lokalt Git‑kodförråd, och nu vill lägga till en fjärr:
$ git remote add origin https://github.com/schacon/simplegit-progit
När du kör kommandot ovan läggs en sektion till i kodförrådets .git/config‑fil som anger fjärrkodförrådets namn (origin), URL:en till fjärrkodförrådet och den refspec som ska användas vid uppdatering:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
Formatet för refspecen är först ett valfritt +, följt av <src>:<dst>, där <src> är mönstret för referenser på fjärrsidan och <dst> anger var dessa referenser ska spåras lokalt.
+ talar om för Git att uppdatera referensen även om det inte är en fast‑forward.
I standardfallet som automatiskt skrivs av kommandot git remote add origin uppdaterar Git alla referenser under refs/heads/ på servern och skriver dem lokalt till refs/remotes/origin/.
Så om det finns en gren master på servern kan du komma åt loggen för den grenen lokalt via något av följande:
$ git log origin/master
$ git log remotes/origin/master
$ git log refs/remotes/origin/master
Alla är likvärdiga, eftersom Git expanderar var och en av dem till refs/remotes/origin/master.
Om du i stället vill att Git bara ska uppdatera grenen master varje gång, och inte alla andra grenar på fjärrservern, kan du ändra uppdatering‑raden så att den bara pekar på den grenen:
fetch = +refs/heads/master:refs/remotes/origin/master
Det här är standard‑refspecen för git fetch för det fjärrkodförrådet.
Om du vill göra en engångsuppdatering kan du också ange den specifika refspecen på kommandoraden.
För att uppdatera grenen master från fjärrkodförrådet till origin/mymaster lokalt kan du köra:
$ git fetch origin master:refs/remotes/origin/mymaster
Du kan också ange flera refspecar. På kommandoraden kan du uppdatera flera grenar så här:
$ git fetch origin master:refs/remotes/origin/mymaster \
topic:refs/remotes/origin/topic
From git@github.com:schacon/simplegit
! [rejected] master -> origin/mymaster (non fast forward)
* [new branch] topic -> origin/topic
I det här fallet nekades uppdateringen av grenen master eftersom den inte var listad som en fast‑forward‑referens.
Du kan åsidosätta det genom att ange + framför refspecen.
Du kan också ange flera refspecar för uppdatering i din konfigurationsfil.
Om du alltid vill uppdatera grenarna master och experiment från fjärrkodförrådet origin lägger du till två rader:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/experiment:refs/remotes/origin/experiment
Sedan Git 2.6.0 kan du använda delvisa globbar i mönstret för att matcha flera grenar, så detta fungerar:
fetch = +refs/heads/qa*:refs/remotes/origin/qa*
Ännu bättre är att du kan använda namnrymder (eller kataloger) för att åstadkomma samma sak mer strukturerat.
Om du har ett QA‑team som skickar upp en serie grenar och du vill få grenen master och QA‑teamets grenar men inget annat, kan du använda en konfigurationssektion som denna:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
Om du har ett komplext arbetsflöde där ett QA‑team skickar upp grenar, utvecklare skickar upp grenar och integrationsteam skickar upp och samarbetar på fjärrgrenar kan du enkelt namnge dem på det här sättet.
Skicka refspecar
Det är trevligt att du kan uppdatera namnrymda referenser på det sättet, men hur får QA‑teamet in sina grenar i en qa/‑namnrymd från början?
Det åstadkommer du genom att använda refspecar för att skicka.
Om QA‑teamet vill skicka sin gren master till qa/master på fjärrservern kan de göra så här:
$ git push origin master:refs/heads/qa/master
Om de vill att Git automatiskt ska göra det varje gång de kör git push origin, kan de lägga till ett push‑värde i sin konfigurationsfil:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/master:refs/heads/qa/master
Det innebär också att git push origin som standard skickar upp den lokala grenen master till fjärrgrenen qa/master.
|
Notera
|
Du kan inte använda refspecen för att uppdatera från ett kodförråd och skicka till ett annat. För ett exempel på hur man gör det, se Håll ditt publika GitHub-kodförråd uppdaterat. |
Radera referenser
Du kan också använda refspecen för att radera referenser från fjärrservern genom att köra något i den här stilen:
$ git push origin :topic
Eftersom refspecen är <src>:<dst> betyder det, genom att utelämna <src>‑delen, i praktiken att grenen topic i fjärrkodförrådet blir ingenting, vilket tar bort den.
Eller så kan du använda den nyare syntaxen (tillgänglig sedan Git v1.7.0):
$ git push origin --delete topic