-
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
7.12 Git-verktyg - Bunta
Bunta
Även om vi har gått igenom de vanliga sätten att överföra Git‑data över nätverk (HTTP, SSH, osv.) finns det faktiskt ytterligare ett sätt som inte används så ofta men kan vara riktigt användbart.
Git kan "bunta" sin data till en enda fil.
Det kan vara användbart i olika scenarier.
Kanske ligger nätverket nere och du vill skicka ändringar till dina kollegor.
Kanske jobbar du på annan ort och har inte åtkomst till det lokala nätverket av säkerhetsskäl.
Kanske gick ditt trådlösa nätverkskort eller ethernetkort sönder.
Kanske har du för tillfället ingen delad server, du vill skicka någon uppdateringar via e-post och du vill inte skicka 40 incheckningar via format-patch.
Det är här kommandot git bundle kan vara till hjälp.
Kommandot git bundle buntar ihop allt som normalt skulle skickas över tråden med kommandot git push i en binärfil som du kan skicka via e-post till någon eller lägga på ett USB‑minne, och sedan packa upp i ett annat kodförråd.
Låt oss se ett enkelt exempel. Säg att du har ett kodförråd med två incheckningar:
$ git log
commit 9a466c572fe88b195efd356c3f2bbeccdb504102
Author: Scott Chacon <schacon@gmail.com>
Date: Wed Mar 10 07:34:10 2010 -0800
Second commit
commit b1ec3248f39900d2a406049d762aa68e9641be25
Author: Scott Chacon <schacon@gmail.com>
Date: Wed Mar 10 07:34:01 2010 -0800
First commit
Om du vill skicka det kodförrådet till någon och du inte har åtkomst till ett kodförråd att skicka till, eller helt enkelt inte vill sätta upp ett, kan du bunta det med git bundle create.
$ git bundle create repo.bundle HEAD master
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (6/6), 441 bytes, done.
Total 6 (delta 0), reused 0 (delta 0)
Nu har du en fil som heter repo.bundle som innehåller all data som behövs för att återskapa kodförrådets master‑gren.
Med kommandot git bundle måste du lista varje referens eller specifikt incheckningsintervall som du vill inkludera.
Om du vill att det ska kunna klonas någon annanstans bör du också lägga till HEAD som referens, precis som vi gjorde här.
Du kan skicka filen repo.bundle via e-post till någon annan eller lägga den på ett USB‑minne och bära över.
På andra sidan, säg att du får filen repo.bundle och vill arbeta med projektet.
Du kan klona från den binära filen till en katalog, ungefär som du skulle från en URL.
$ git clone repo.bundle repo
Cloning into 'repo'...
...
$ cd repo
$ git log --oneline
9a466c5 Second commit
b1ec324 First commit
Om du inte inkluderar HEAD i referenserna måste du också ange -b master eller vilken gren som än ingår, eftersom den annars inte vet vilken gren den ska växla till.
Säg nu att du gör tre incheckningar där och vill skicka de nya incheckningarna tillbaka via en bunt på ett USB‑minne eller via e-post.
$ git log --oneline
71b84da Last commit - second repo
c99cf5b Fourth commit - second repo
7011d3d Third commit - second repo
9a466c5 Second commit
b1ec324 First commit
Först behöver vi bestämma intervallet av incheckningar vi vill inkludera i bunten. Till skillnad från nätverksprotokollen som räknar ut minsta mängden data att överföra åt oss måste vi räkna ut detta manuellt. Du kan förstås göra samma sak och bunta hela kodförrådet, vilket fungerar, men det är bättre att bara bunta skillnaden — bara de tre incheckningar vi just gjorde lokalt.
För att göra det behöver du beräkna skillnaden.
Som vi beskrev i Incheckningsintervall kan du ange ett incheckningsintervall på flera sätt.
För att få de tre incheckningarna som vi har i vår master‑gren men inte i grenen vi ursprungligen klonade kan vi använda något som origin/master..master eller master ^origin/master.
Du kan testa det med kommandot log.
$ git log --oneline master ^origin/master
71b84da Last commit - second repo
c99cf5b Fourth commit - second repo
7011d3d Third commit - second repo
Så nu när vi har listan över incheckningar vi vill inkludera i bunten, låt oss bunta dem.
Vi gör det med kommandot git bundle create, där vi anger filnamnet vi vill att bunten ska ha och intervallet av incheckningar vi vill stoppa in.
$ git bundle create commits.bundle master ^9a466c5
Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (9/9), 775 bytes, done.
Total 9 (delta 0), reused 0 (delta 0)
Nu har vi en fil commits.bundle i vår katalog.
Om vi tar den och skickar den till vår partner kan hon importera den i det ursprungliga kodförrådet, även om mer arbete har gjorts där under tiden.
När hon får bunten kan hon inspektera den för att se vad den innehåller innan hon importerar den i sitt kodförråd.
Det första kommandot är git bundle verify, som säkerställer att filen faktiskt är en giltig Git‑bunt och att du har alla nödvändiga anfäder för att återskapa den korrekt.
$ git bundle verify ../commits.bundle
The bundle contains 1 ref
71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master
The bundle requires these 1 ref
9a466c572fe88b195efd356c3f2bbeccdb504102 second commit
../commits.bundle is okay
Om den som buntade hade skapat en bunt av bara de två senaste incheckningarna de gjorde, i stället för alla tre, skulle det ursprungliga kodförrådet inte kunna importera den, eftersom nödvändig historik saknas.
Kommandot verify skulle ha sett ut så här i stället:
$ git bundle verify ../commits-bad.bundle
error: Repository lacks these prerequisite commits:
error: 7011d3d8fc200abe0ad561c011c3852a4b7bbe95 Third commit - second repo
Vår första bunt är dock giltig, så vi kan uppdatera med incheckningar från den. Om du vill se vilka grenar som finns i bunten och kan importeras finns också ett kommando för att bara lista huvudena:
$ git bundle list-heads ../commits.bundle
71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master
Underkommandot verify talar också om huvudena.
Poängen är att se vad som kan dras in, så du kan använda kommandona fetch eller pull för att importera incheckningar från den här bunten.
Här uppdaterar vi master‑grenen från bunten till en gren som heter other-master i vårt kodförråd:
$ git fetch ../commits.bundle master:other-master
From ../commits.bundle
* [new branch] master -> other-master
Nu kan vi se att vi har de importerade incheckningarna på grenen other-master samt eventuella incheckningar vi gjort under tiden i vår egen master‑gren.
$ git log --oneline --decorate --graph --all
* 8255d41 (HEAD, master) Third commit - first repo
| * 71b84da (other-master) Last commit - second repo
| * c99cf5b Fourth commit - second repo
| * 7011d3d Third commit - second repo
|/
* 9a466c5 Second commit
* b1ec324 First commit
Så git bundle kan vara riktigt användbart för att dela eller göra nätverksliknande operationer när du inte har rätt nätverk eller delat kodförråd för att göra det.