Chapters ▾ 2nd Edition

7.12 Git Tools - Bundeling (Bundling)

Bundeling (Bundling)

Alhoewel ons die algemene maniere gedek het om Git-data oor 'n netwerk oor te dra (HTTP, SSH, ens.), is daar eintlik nog een manier om dit te doen wat nie algemeen gebruik word nie, maar wat eintlik baie nuttig kan wees.

Git is in staat om sy data in 'n enkele lêer te “bundel”. Dit kan in verskeie scenario’s nuttig wees. Miskien is jou netwerk af en jy wil veranderings aan jou medewerkers stuur. Miskien werk jy iewers op 'n afgeleë plek en het om veiligheidsredes nie toegang tot die plaaslike netwerk nie. Miskien het jou draadlose/ethernet-kaart net gebreek. Miskien het jy op die oomblik nie toegang tot 'n gedeelde bediener nie, jy wil vir iemand opdaterings e-pos en jy wil nie 40 vasleggings (commits) via format-patch oordra nie.

Dit is waar die git bundle opdrag nuttig kan wees. Die bundle opdrag sal alles wat normaalweg met 'n git push opdrag oor die netwerk opgestuur sou word, in 'n binêre lêer verpak wat jy vir iemand kan e-pos of op 'n flitsstok (flash drive) kan sit, en dan in 'n ander bewaarplek kan ontbondel (unbundle).

Kom ons kyk na 'n eenvoudige voorbeeld. Sê nou jy het 'n bewaarplek met twee vasleggings:

$ 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

As jy daardie bewaarplek vir iemand wil stuur en jy het nie toegang tot 'n bewaarplek om na te push nie, of eenvoudig nie een wil opstel nie, kan jy dit bundel met 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)

Nou het jy 'n lêer genaamd repo.bundle wat al die data het wat nodig is om die bewaarplek se master tak te herskep. Met die bundle opdrag moet jy elke verwysing of spesifieke reeks vasleggings lys wat jy wil insluit. As jy van plan is dat dit iewers anders gekloon moet word, moet jy HEAD ook as 'n verwysing byvoeg, soos ons hier gedoen het.

Jy kan hierdie repo.bundle lêer vir iemand anders e-pos, of dit op 'n USB-skyf sit en dit oorstap.

Aan die ander kant, sê jy word hierdie repo.bundle lêer gestuur en wil aan die projek werk. Jy kan vanaf die binêre lêer in 'n gids kloon, baie soos jy van 'n URL af sou doen.

$ git clone repo.bundle repo
Cloning into 'repo'...
...
$ cd repo
$ git log --oneline
9a466c5 Second commit
b1ec324 First commit

As jy nie HEAD in die verwysings insluit nie, moet jy ook -b master spesifiseer of watter tak ook al ingesluit is, want anders sal dit nie weet watter tak om uit te check nie.

Kom ons sê nou jy doen drie vasleggings daarop en wil die nuwe vasleggings terugstuur via 'n bundel op 'n USB-stokkie of e-pos.

$ git log --oneline
71b84da Last commit - second repo
c99cf5b Fourth commit - second repo
7011d3d Third commit - second repo
9a466c5 Second commit
b1ec324 First commit

Eerstens moet ons die reeks vasleggings bepaal wat ons in die bundel wil insluit. Anders as die netwerkprotokolle wat die minimum stel data wat oor die netwerk oorgedra moet word vir ons uitwerk, sal ons dit handmatig moet uitvind. Jy kan natuurlik net dieselfde ding doen en die hele bewaarplek bundel, wat sal werk, maar dit is beter om net die verskil te bundel - net die drie vasleggings wat ons pas plaaslik gemaak het.

Om dit te doen, sal jy die verskil moet bereken. Soos ons in Vasleggingsreekse (Commit Ranges) beskryf het, kan jy 'n reeks vasleggings op verskeie maniere spesifiseer. Om die drie vasleggings te kry wat ons in ons master tak het wat nie in die tak was wat ons oorspronklik gekloon het nie, kan ons iets soos origin/master..master of master ^origin/master gebruik. Jy kan dit toets met die log opdrag.

$ git log --oneline master ^origin/master
71b84da Last commit - second repo
c99cf5b Fourth commit - second repo
7011d3d Third commit - second repo

So noudat ons die lys van vasleggings het wat ons in die bundel wil insluit, kom ons bundel hulle. Ons doen dit met die git bundle create opdrag, wat dit 'n lêernaam gee wat ons wil hê ons bundel moet wees en die reeks vasleggings wat daarin moet gaan.

$ 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)

Nou het ons 'n commits.bundle lêer in ons gids. As ons dit neem en dit na ons vennoot stuur, kan sy dit dan in die oorspronklike bewaarplek invoer, selfs al is daar intussen meer werk daar gedoen.

Wanneer sy die bundel kry, kan sy dit inspekteer om te sien wat dit bevat voordat sy dit in haar bewaarplek invoer. Die eerste opdrag is die bundle verify opdrag wat sal seker maak dat die lêer werklik 'n geldige Git-bundel is en dat jy al die nodige voorouers het om dit behoorlik te hersaamstel.

$ 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

As die bundelaar 'n bundel geskep het van net die laaste twee vasleggings wat hulle gedoen het, eerder as al drie, sou die oorspronklike bewaarplek dit nie kon invoer nie, aangesien dit vereiste geskiedenis kort. Die verify opdrag sou in plaas daarvan so gelyk het:

$ git bundle verify ../commits-bad.bundle
error: Repository lacks these prerequisite commits:
error: 7011d3d8fc200abe0ad561c011c3852a4b7bbe95 Third commit - second repo

Ons eerste bundel is egter geldig, so ons kan vasleggings daaruit afhaal (fetch). As jy wil sien watter takke in die bundel is wat ingevoer kan word, is daar ook 'n opdrag om net die koppe (heads) te lys:

$ git bundle list-heads ../commits.bundle
71b84daaf49abed142a373b6e5c59a22dc6560dc refs/heads/master

Die verify subopdrag sal jou ook die koppe (heads) vertel. Die punt is om te sien wat in gepull kan word, sodat jy die fetch of pull opdragte kan gebruik om vasleggings uit hierdie bundel in te voer. Hier sal ons die master tak van die bundel na 'n tak genaamd other-master in ons bewaarplek afhaal (fetch):

$ git fetch ../commits.bundle master:other-master
From ../commits.bundle
 * [new branch]      master     -> other-master

Nou kan ons sien dat ons die ingevoerde vasleggings op die other-master tak het asook enige vasleggings wat ons intussen in ons eie master tak gedoen het.

$ 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

Dus, git bundle kan regtig nuttig wees om te deel of netwerk-tipe bewerkings te doen wanneer jy nie die regte netwerk of gedeelde bewaarplek het om dit te doen nie.