-
1. Začetek
- 1.1 O nadzoru različic
- 1.2 Kratka zgodovina Gita
- 1.3 Kaj je Git?
- 1.4 Ukazna vrstica
- 1.5 Namestitev Gita
- 1.6 Prva nastavitev Gita
- 1.7 Pridobivanje pomoči
- 1.8 Povzetek
-
2. Osnove Git
- 2.1 Pridobivanje repozitorija Git
- 2.2 Snemanje sprememb v repozitorij
- 2.3 Pregled zgodovine potrditev
- 2.4 Razveljavljanje stvari
- 2.5 Delo z daljavami
- 2.6 Označevanje
- 2.7 Aliasi Git
- 2.8 Povzetek
-
3. Veje Git
- 3.1 Veje na kratko
- 3.2 Osnove vej in združevanja
- 3.3 Upravljanje vej
- 3.4 Poteki dela z vejami
- 3.5 Oddaljene veje
- 3.6 Ponovno baziranje
- 3.7 Povzetek
-
4. Git na strežniku
- 4.1 Protokoli
- 4.2 Pridobitev Gita na strežniku
- 4.3 Generiranje vaših javnih ključev SSH
- 4.4 Nastavitev strežnika
- 4.5 Prikriti proces Git
- 4.6 Pametni HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti gostovanja pri tretjih ponudnikih
- 4.10 Povzetek
-
5. Porazdeljeni Git
- 5.1 Porazdeljeni poteki dela
- 5.2 Prispevek k projektu
- 5.3 Vzdrževanje projekta
- 5.4 Povzetek
-
6. GitHub
-
7. Orodja Git
- 7.1 Izbira revizije
- 7.2 Interaktivno pripravljanje
- 7.3 Shranjevanje na varno (angl. stashing) in čiščenje
- 7.4 Podpisovanje vašega dela
- 7.5 Iskanje
- 7.6 Prepisovanje zgodovine
- 7.7 Demistifikacija ponastavitve
- 7.8 Napredno združevanje
- 7.9 Rerere
- 7.10 Razhroščevanje z Gitom
- 7.11 Podmoduli
- 7.12 Povezovanje v pakete
- 7.13 Zamenjava
- 7.14 Shramba poverilnic
- 7.15 Povzetek
-
8. Prilagoditev Gita
- 8.1 Konfiguracija Git
- 8.2 Atributi Git
- 8.3 Kljuke Git
- 8.4 Primer pravilnika, ki ga uveljavlja Git
- 8.5 Povzetek
-
9. Git in ostali sistemi
- 9.1 Git kot odjemalec
- 9.2 Migracija na Git
- 9.3 Povzetek
-
10. Notranjost Gita
- 10.1 Napeljava in keramika
- 10.2 Objekti Git
- 10.3 Reference Git
- 10.4 Packfiles (datoteke zmanjšanih podatkov)
- 10.5 Refspec
- 10.6 Protokoli prenosa
- 10.7 Vzdrževanje in obnovitev podatkov
- 10.8 Spremenljivke okolja
- 10.9 Povzetek
-
A1. Dodatek A: Git v drugih okoljih
- A1.1 Grafični vmesniki
- A1.2 Git v Visual Studio
- A1.3 Git v Visual Studio Code
- A1.4 Git v IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git v Sublime Text
- A1.6 Git v Bashu
- A1.7 Git v Zsh
- A1.8 Git v Powershellu
- A1.9 Povzetek
-
A2. Dodatek B: Vdelava Gita v vašo aplikacijo
- A2.1 Git v ukazni vrstici
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Dodatek C: Ukazi Git
- A3.1 Nastavitev in konfiguracija
- A3.2 Pridobivanje in ustvarjanje projektov
- A3.3 Osnove posnetkov
- A3.4 Veje in združevanje
- A3.5 Deljenje in posodabljanje projektov
- A3.6 Pregled in primerjava
- A3.7 Razhroščevanje
- A3.8 Popravljanje
- A3.9 E-pošta
- A3.10 Zunanji sistemi
- A3.11 Administracija
- A3.12 Orodja za sisteme napeljave
7.12 Orodja Git - Povezovanje v pakete
Povezovanje v pakete
Čeprav smo že pokrili pogoste načine prenosa podatkov Git preko omrežja (HTTP, SSH itd.), obstaja dejansko še en način, ki ni pogosto uporabljen, vendar je lahko zelo uporaben.
Git je sposoben svoje podatke »povezati« (angl. bundle) v eno datoteko.
To je lahko uporabno v različnih scenarijih.
Morda je vaše omrežje nedostopno, vendar želite poslati spremembe svojim sodelavcem.
Morda delate nekje izven pisarne in nimate dostopa do lokalnega omrežja iz varnostnih razlogov.
Morda se vam je pokvarila brezžična/ethernet kartica.
Morda za zdaj nimate dostopa do skupnega strežnika, želite pa nekomu poslati posodobitve po e-pošti in ne želite prenesti 40 potrditev prek format-patch
.
Tukaj je lahko koristen ukaz git bundle
.
Ukaz bundle
bo vse, kar bi sicer bilo poslano po žici z ukazom git push
, zapakiral v binarno datoteko, ki jo lahko pošljete po e-pošti, ali jo shranite na pomnilniški ključ, nato pa jo razpakirate v drugem repozitoriju.
Poglejmo si preprost primer. Recimo, da imate repozitorij s tremi potrditvami:
$ 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
Če želite ta repozitorij poslati nekomu in nimate dostopa do repozitorija, na katerega bi ga lahko potisnili, ali preprosto ne želite nastaviti novega, ga lahko zapakirate s pomočjo ukaza 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)
Zdaj imate datoteko z imenom repo.bundle
, ki vsebuje vse potrebne podatke za ponovno ustvarjanje veje master
repozitorija.
Pri uporabi ukaza bundle
morate navesti vsako referenco ali določen obseg potrditev, ki jih želite vključiti.
Če nameravate to uporabiti drugje, bi morali dodati kot referenco tudi glavo (HEAD), kot smo storili tukaj.
Datoteko repo.bundle
lahko pošljete po e-pošti nekomu drugemu, ali pa jo shranite na ključ USB in jo odnesete drugam.
Po drugi strani, recimo, da ste prejeli datoteko repo.bundle
in želite delati na projektu.
Iz binarne datoteke lahko klonirate v mapo, podobno kot bi to storili iz URL-ja.
$ git clone repo.bundle repo
Cloning into 'repo'...
...
$ cd repo
$ git log --oneline
9a466c5 Second commit
b1ec324 First commit
Če v reference ne vključite glave (HEAD), morate določiti tudi -b master
ali katero koli drugo vejo, ki je vključena, saj v nasprotnem primeru Git ne bo vedel, katero vejo naj izvleče.
Recimo, da na njem naredite tri potrditve in želite nove potrditve poslati nazaj preko zbirke na ključu USB ali po e-pošti.
$ git log --oneline
71b84da Last commit - second repo
c99cf5b Fourth commit - second repo
7011d3d Third commit - second repo
9a466c5 Second commit
b1ec324 First commit
Najprej moramo določiti obseg potrditev, ki jih želimo vključiti v zbirko. V nasprotju z omrežnimi protokoli, ki sami ugotovijo minimalni nabor podatkov, ki jih je treba prenesti prek omrežja, bomo to morali ugotoviti ročno. Seveda lahko naredite enako stvar in v zbirko vključite celoten repozitorij, kar bo delovalo, vendar je bolje, da vključite le razliko — torej samo tri potrditve, ki smo jih ravnokar naredili lokalno.
Za to morate izračunati razliko.
Kot smo opisali v Obsegi potrditev, lahko obseg potrditev določimo na več načinov.
Da dobimo tri potrditve, ki jih imamo v naši veji master
in ki jih ni bilo v veji, ki smo jo prvotno klonirali, lahko uporabimo nekaj takega, kot je origin/master..master
ali master ^origin/master
.
To lahko preizkusite s pomočjo ukaza log
.
$ git log --oneline master ^origin/master
71b84da Last commit - second repo
c99cf5b Fourth commit - second repo
7011d3d Third commit - second repo
Torej, zdaj, ko imamo seznam potrditev, ki jih želimo vključiti v zbirko, jih lahko zapakiramo vanjo.
To naredimo s pomočjo ukaza git bundle create
, pri čemer navedemo ime datoteke, v katero želimo shraniti svojo zbirko, in obseg potrditev, ki jih želimo vanjo vključiti.
$ 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)
Sedaj imamo datoteko commits.bundle
v naši mapi.
Če to datoteko pošljemo svojemu partnerju, jo lahko uvozi nazaj v prvotni repozitorij, tudi če je v tem času tam že bilo opravljenega več dela.
Ko prejme zbirko, lahko preveri, kaj vsebuje, preden jo uvozi v svoj repozitorij.
Prva poteza je uporaba ukaza bundle verify
, ki bo preveril, ali je datoteka dejansko veljavna zbirka Git in ali ima vse potrebne prednike za pravilno rekonstrukcijo.
$ 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
Če bi ustvarjalec zbirke ustvaril zbirko samo zadnjih dveh potrditev, ki jih je naredil, namesto vseh treh, prvotni repozitorij ne bi mogel uvoziti te zbirke, saj manjka potrebna zgodovina.
Ukaz verify
bi bil videti takole namesto tistega v prejšnjem primeru:
$ git bundle verify ../commits-bad.bundle
error: Repository lacks these prerequisite commits:
error: 7011d3d8fc200abe0ad561c011c3852a4b7bbe95 Third commit - second repo
Vendar pa je naša prva zbirka veljavna, zato lahko iz nje pridobimo potrditve. Če želite videti, katere veje v zbirki se lahko uvozijo, obstaja tudi ukaz, ki navede le glave:
$ git bundle list-heads ../commits.bundle
71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master
Podukaz verify
vam bo prav tako povedal, katere glave so na voljo.
Namen je videti, kaj lahko povlečete, zato lahko uporabite ukaza fetch
ali pull
, da uvozite potrditve iz te zbirke.
Tukaj bomo pridobili vejo master
zbirke v vejo imenovano other-master
v našem repozitoriju:
$ git fetch ../commits.bundle master:other-master
From ../commits.bundle
* [new branch] master -> other-master
Zdaj lahko vidimo, da imamo uvožene potrditve na veji other-master
, skupaj s katerimi koli potrditvami, ki smo jih v tem času naredili na svoji lastni veji master
.
$ 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
Tako lahko git bundle
dejansko zelo koristi pri skupni rabi ali opravljanju operacij, podobnim mrežnim operacijam, ko nimate ustreznega omrežja ali skupnega repozitorija za to.