9.1 Git and Other Systems - Git as a Client

Die basisopdrag in Git vir al die Subversion-brugopdragte is git svn. Dit neem 'n hele paar opdragte, so ons sal die algemeenste wys terwyl ons deur 'n paar eenvoudige werkvloeie gaan.

Dit is belangrik om op te let dat wanneer jy git svn gebruik, jy met Subversion wisselwerking het, wat 'n stelsel is wat baie anders as Git werk. Alhoewel jy plaaslike takking en saamsmelting kan doen, is dit oor die algemeen die beste om jou geskiedenis so lineair as moontlik te hou deur jou werk te rebasen, en te vermy om dinge te doen soos om gelyktydig met 'n Git-remote te wisselwerking.

Moenie jou geskiedenis herskryf en probeer om weer te push nie, en moenie na 'n parallelle Git-bewaarplek push om terselfdertyd met mede-Git-ontwikkelaars saam te werk nie. Subversion kan slegs 'n enkele lineêre geskiedenis hê, en dit is baie maklik om dit te verwar. As jy met 'n span werk, en sommige gebruik SVN en ander gebruik Git, maak seker almal gebruik die SVN-bediener om saam te werk – dit sal jou lewe makliker maak.

Om hierdie funksionaliteit te demonstreer, benodig jy 'n tipiese SVN-bewaarplek waartoe jy skryftoegang het. As jy hierdie voorbeelde wil kopieer, sal jy 'n skryfbare kopie van 'n SVN-toetsbewaarplek moet maak. Om dit maklik te doen, kan jy 'n hulpmiddel genaamd svnsync gebruik wat saam met Subversion kom.

Om te volg, moet jy eers 'n nuwe plaaslike Subversion-bewaarplek skep:

Stel dan al gebruikers in staat om revprops te verander – die maklike manier is om 'n pre-revprop-change skrip by te voeg wat altyd 0 uitstaan:

Jy kan nou hierdie projek na jou plaaslike masjien sinchroniseer deur svnsync init te roep met die na- en van-bewaarplekke.

Dit stel die eienskappe op om die sinchronisasie te laat loop. Jy kan dan die kode kloon deur dit uit te voer:

Alhoewel hierdie operasie säl 'n paar minute kan neem, as jy probeer om die oorspronklike bewaarplek na 'n ander afgeleë bewaarplek te kopieer in plaas van 'n plaaslike een, sal die proses amper 'n uur neem, al is daar minder as 100 vasleggings. Subversion moet een hersiening op 'n slag kloon en dit dan terugpush in 'n ander bewaarplek – dit is belaglik ondoeltreffend, maar dit is die enigste maklike manier om dit te doen.

Noudat jy 'n Subversion-bewaarplek het waartoe jy skryftoegang het, kan jy deur 'n tipiese werkvloei gaan. Jy sal begin met die git svn clone opdrag, wat 'n hele Subversion-bewaarplek in 'n plaaslike Git-bewaarplek inporteer. Onthoud dat as jy van 'n egte gehoste Subversion-bewaarplek inporteer, jy die file:///tmp/test-svn hier moet vervang met die URL van jou Subversion-bewaarplek:

Dit voer die ekwivalent van twee opdragte uit – git svn init gevolg deur git svn fetch – op die URL wat jy verskaf. Dit kan 'n rukkie neem. As die toetsprojek byvoorbeeld net sowat 75 vasleggings het en die kodebasis nie so groot is nie, moet Git nog steeds elke weergawe uittrek, een op 'n slag, en dit individueel vaslê. Vir 'n projek met honderde of duisende vasleggings kan dit letterlik ure of selfs dae neem om te voltooi.

Die -T trunk -b branches -t tags gedeelte sê vir Git dat hierdie Subversion-bewaarplek die basiese takking- en merkerkonvensies volg. As jy jou trunk, branches of tags anders noem, kan jy hierdie opsies verander. Omdat dit so algemeen is, kan jy hierdie hele gedeelte vervang met -s, wat standaarduitleg beteken en al daardie opsies impliseer. Die volgende opdrag is ekwivalent:

Op hierdie punt behoort jy 'n geldige Git-bewaarplek te hê wat jou takke en merkers geïmporteer het:

Let op hoe hierdie hulpmiddel Subversion-merkers as afgeleë verwysings (remote refs) bestuur. Kom ons kyk van naderby met die Git-loodgietersopdrag show-ref:

Git doen dit nie wanneer dit van 'n Git-bediener kloon nie; hier is hoe 'n bewaarplek met merkers lyk na 'n vars kloon:

Git fetch die merkers direk in refs/tags, eerder as om hulle as afgeleë takke te hanteer.

Noudat jy 'n werkgids het, kan jy 'n bietjie werk aan die projek doen en jou vasleggings terug stroomop push, deur Git effektief as 'n SVN-kliënt te gebruik. As jy een van die lêers redigeer en dit vaslê, het jy 'n vaslegging wat plaaslik in Git bestaan wat nie op die Subversion-bediener bestaan nie:

Volgende moet jy jou verandering stroomop push. Merk op hoe dit die manier verander waarop jy met Subversion werk – jy kan verskeie vasleggings vanlyn doen en dit dan alles gelyktydig na die Subversion-bediener push. Om na 'n Subversion-bediener te push, voer jy die git svn dcommit opdrag uit:

Dit neem al die vasleggings wat jy gemaak het bo-op die Subversion-bedienerkode, doen 'n Subversion-vaslegging vir elkeen, en herskryf dan jou plaaslike Git-vaslegging om 'n unieke identifiseerder in te sluit. Dit is belangrik omdat dit beteken dat al die SHA-1 kontrolesomme vir jou vasleggings verander. Gedeeltelik om hierdie rede is dit nie 'n goeie idee om gelyktydig met 'n Subversion-bediener aan Git-gebaseerde afgeleë weergawes van jou projekte te werk nie. As jy na die laaste vaslegging kyk, kan jy die nuwe git-svn-id sien wat bygevoeg is:

Let op dat die SHA-1 kontrolesom wat oorspronklik met 4af61fd begin het toe jy vasgelê het, nou met 95e0222 begin. As jy na beide 'n Git-bediener en 'n Subversion-bediener wil push, moet jy eers na die Subversion-bediener push (dcommit), omdat daardie aksie jou vasleggingsdata verander.

As jy saam met ander ontwikkelaars werk, sal een van julle op 'n stadium push, en dan sal die ander een probeer om 'n verandering te push wat konstrasteer (konflik). Daardie verandering sal geweiger word tensy jy hul werk insmelt. In git svn lyk dit soos dit:

Om hierdie situasie op te los, kan jy git svn rebase uitvoer, wat enige veranderings op die bediener aftrek wat jy nog nie het nie en enige werk wat jy het rebase bo-op dit wat op die bediener is:

Nou is al jou werk bo-op dit wat op die Subversion-bediener is, sodat jy suksesvol dcommit kan doen:

Let daarop dat in teenstelling met Git, wat vereis dat jy stroomopwaartse werk wat jy nog nie plaaslik het nie, moet insmelt voordat jy kan push, dwing git svn jou om dit slegs te doen as die veranderings konflik (baie soos hoe Subversion werk). As iemand anders 'n verandering aan een lêer push en jy dan 'n verandering aan 'n ander lêer push, sal jou git svn dcommit goed werk:

Dit is belangrik om te onthou, aangesien die uitkoms 'n projektoestand is wat nie op enige van julle rekenaars bestaan het toe julle gepush het nie. As die veranderings onversoenbaar is maar nie konflik maak nie, kan jy kwessies kry wat moeilik is om te gagnostiseer. Dit verskil van die gebruik van 'n Git-bediener – in Git kan jy die toestand op jou kliëntstelsel ten volle toets voordat jy dit publiseer, terwyl jy in SVN nooit seker kan wees dat die toestande onmiddellik voor vaslegging en na vaslegging identies is nie.

Jy moet ook hierdie opdrag uitvoer om veranderings van die Subversion-bediener in te trek, selfs al is jy nie gereed om self vas te lê nie. Jy kan git svn fetch uitvoer om die nuwe data te gryp, maar git svn rebase doen die fetch en werk dan jou plaaslike vasleggings op.

Om git svn rebase kort-kort uit te voer, maak seker dat jou kode altyd op datum is. Jy moet egter seker wees dat jou werkgids skoon is wanneer jy dit uitvoer. As jy plaaslike veranderings het, moet jy óf jou werk bêre (stash) óf dit tydelik vaslê voordat jy git svn rebase uitvoer – anders sal die opdrag stop as dit sien dat die rebase in 'n saamsmeltingskonflik sal aanhits.

Wanneer jy gemaklik geraak het met 'n Git-werkvloei, sal jy waarskynlik onderwerptakke (topic branches) skep, werk daaraan doen, en dit dan insmelt. As jy na 'n Subversion-bediener push via git svn, wil jy dalk eerder jou werk op 'n enkele tak rebase elke keer in plaas daarvan om takke saam te smelt. Die rede om herbasering (rebasing) te verkies, is dat Subversion 'n lineêre geskiedenis het en nie met saamsmeltings omgaan soos Git dit doen nie, so git svn volg slegs die eerste ouer wanneer die momentopnames in Subversion-vasleggings omgeskakel word.

Veronderstel jou geskiedenis lyk soos die volgende: jy het 'n experiment tak geskep, twee vasleggings gedoen, en dit toe terug in master gesmelt. Wanneer jy dcommit, sien jy afvoer soos dit:

Die uitvoering van dcommit op 'n tak met gesmelte geskiedenis werk goed, behalwe dat wanneer jy na jou Git-projekgeskiedenis kyk, dit geen van die vasleggings wat jy op die experiment tak gemaak het, herskryf het nie – in plaas daarvan verskyn al daardie veranderings in die SVN-weergawe van die enkele saamsmeltingsvaslegging.

Wanneer iemand anders daardie werk kloon, sien al wat hulle sien die saamsmeltingsvaslegging met al die werk daarin saamgepers (squashed), asof jy git_merge --squash uitgevoer het; hulle sien nie die vasleggingsdata oor waar dit vandaan kom of wanneer dit vasgelê is nie.

Takking in Subversion is nie dieselfde as takking in Git nie; as jy kan vermy om dit veel te gebruik, is dit waarskynlik die beste. Jy kan egter takke in Subversion skep en daaraan vaslê met git svn.

Om 'n nuwe tak in Subversion te skep, voer jy git svn branch [new-branch] uit:

Dit doen die ekwivalent van die svn copy trunk branches/opera opdrag in Subversion en werk op die Subversion-bediener. Dit is belangrik om op te let dat dit jou nie uittrek in daardie tak nie; as jy op hierdie punt vaslê, sal daardie vaslegging na trunk op die bediener gaan, nie opera nie.

Git vind uit na watter tak jou dcommits gaan deur te soek na die punt van enige van jou Subversion-takke in jou geskiedenis – jy behoort slegs een te hê, en dit behoort die laaste een te wees met 'n git-svn-id in jou huidige takgeskiedenis.

As jy aan meer as een tak gelyktydig wil werk, kan jy plaaslike takke opstel om na spesifieke Subversion-takke te dcommit deur hulle te begin by die geïmporteerde Subversion-vaslegging vir daardie tak. As jy 'n opera tak wil hê waarop jy afsonderlik kan werk, kan jy uitvoer:

Nou, as jy jou opera tak in trunk (jou master tak) wil insmelt, kan jy dit doen met 'n normale git merge. Maar jy moet 'n beskrywende vasleggingsboodskap verskaf (via -m), anders sal die saamsmelting sê “Merge branch opera” in plaas van iets nuttigs.

Onthoud dat al gebruik jy git merge om hierdie bewerking te doen, en die saamsmelting sal waarskynlik baie makliker wees as wat dit in Subversion sou wees (omdat Git outomaties die gepaste saamsmeltingsbasis vir jou sal detekteer), is dit nie 'n normale Git-saamsmeltingsvaslegging nie. Jy moet hierdie data terugpush na 'n Subversion-bediener wat nie 'n vaslegging kan hanteer wat meer as een ouer naspoor nie; dus, nadat jy dit opgestoot het, sal dit lyk soos 'n enkele vaslegging wat al die werk van 'n ander tak onder 'n enkele vaslegging saamgepers het. Nadat jy een tak in 'n ander gesmelt het, kan jy nie maklik teruggaan en aan daardie tak voortgaan te werk soos jy normaalweg in Git kan nie. Die dcommit opdrag wat jy uitvoer, vee enige inligting uit wat sê watter tak ingesmelt is, so daaropvolgende saamsmeltingsbasis-berekeninge sal verkeerd wees – die dcommit laat jou git merge resultaat lyk asof jy git merge --squash uitgevoer het. Ongelukkig is daar geen goeie manier om hierdie situasie te vermy nie – Subversion kan nie hierdie inligting stoor nie, so jy sal altyd gekortwiek word deur sy beperkings terwyl jy dit as jou bediener gebruik. Om kwessies te vermy, moet jy die plaaslike tak (in hierdie geval, opera) verwyder nadat jy dit in trunk ingesmelt het.

Die git svn hulpmiddelset bied 'n aantal opdragte om die oorgang na Git te vergemaklik deur sekere funksionaliteit te verskaf wat soortgelyk is aan wat jy in Subversion gehad het. Hier is 'n paar opdragte wat jou gee wat Subversion gewoond was om te verskaf.

Die git svn hulpmiddels is nuttig as jy vas sit met 'n Subversion-bediener, of andersins in 'n ontwikkelingsomgewing is wat die uitvoering van 'n Subversion-bediener noodsaak. Jy moet dit egter as 'n gekortwiekte Git beskou, anders sal jy kwessies in vertaling teëkom wat jou en jou medewerkers kan verwar. Om uit die moeilikheid te bly, probeer om hierdie riglyne te volg:

As jy daardie riglyne volg, kan die werk met 'n Subversion-bediener meer draaglik wees. As dit egter moontlik is om na 'n egte Git-bediener te skuif, kan dit jou span veel meer besorg.

Eerstens moet jy git-remote-hg installeer. Dit behels basies om sy lêer iewers in jou pad te plaas, soos dit:

…aannemende dat ~/bin in jou $PATH is. git-remote-hg het een ander afhanklikheid: die mercurial biblioteek vir Python. As jy Python geïnstalleer het, is dit so eenvoudig as:

As jy nie Python geïnstalleer het nie, besoek https://www.python.org/ en kry dit eers.

Die laaste ding wat jy nodig het, is die Mercurial-kliënt. Gaan na https://www.mercurial-scm.org/ en installeer dit as jy dit nie reeds gedoen het nie.

Nou is jy gereed om te begin. Al wat jy nodig het, is 'n Mercurial-bewaarplek waarna jy kan push. Gelukkig kan elke Mercurial-bewaarplek op hierdie manier optree, so ons sal net die "hello world" bewaarplek gebruik wat almal gebruik om Mercurial te leer:

Noudat ons 'n geskikte “bedienerkant”-bewaarplek het, kan ons deur 'n tipiese werkvloei gaan. Soos jy sal sien, is hierdie twee stelsels soortgelyk genoeg dat daar nie baie wrywing is nie.

Soos altyd met Git, kloon ons eerste:

Jy sal opmerk dat die werk met 'n Mercurial-bewaarplek die standaard git clone opdrag gebruik. Dit is omdat git-remote-hg op 'n taamlik lae vlak werk, deur gebruik te maak van 'n meganisme wat soortgelyk is aan hoe Git se HTTP/S-protokol geïmplementeer word (remote helpers). Aangesien Git en Mercurial beide ontwerp is sodat elke kliënt 'n volledige kopie van die bewaarplekgeskiedenis het, maak hierdie opdrag 'n volledige kloon, insluitend al die projek se geskiedenis, en doen dit redelik vinnig.

Die log opdrag wys twee vasleggings, waarvan die laaste aangewys word deur 'n hele tros verwysings (refs). Dit blyk dat sommige van hierdie nie werklik daar is nie. Kom ons kyk na wat eintlik in die .git gids is:

git-remote-hg probeer dinge meer idiomaties Git-agtig maak, maar onder die enjinkap bestuur dit die konseptuele kartering tussen twee effens verskillende stelsels. Die refs/hg gids is waar die werklike afgeleë verwysings gestoor word. Byvoorbeeld, die refs/hg/origin/branches/default is 'n Git-verwysingslêer wat die SHA-1 bevat wat begin met “ac7955c”, wat die vaslegging is waarna master wys. Dus is die refs/hg gids 'n bietjie soos 'n vals refs/remotes/origin, maar dit het die bykomende onderskeid tussen boekmerke (bookmarks) en takke (branches).

Die notes/hg lêer is die beginpunt vir hoe git-remote-hg Git-vasleggingshuts (commit hashes) aan Mercurial-wysigingstel-ID’s (changeset IDs) karteer. Kom ons verken 'n bietjie:

Dus wys refs/notes/hg na 'n boom (tree), wat in die Git-objekdatabasis 'n lys is van ander objekte met name. git ls-tree voer die modus, tipe, objekhuts en lêernaam uit vir items binne 'n boom. Sodra ons afgrawe na een van die boomitems, vind ons dat binne-in dit 'n blob is genaamd “ac9117f” (die SHA-1 huts van die vaslegging waarna master wys), met inhoud “0a04b98” (wat die ID is van die Mercurial-wysigingstel aan die punt van die default tak).

Die goeie nuus is dat ons meestal nie hoef te bekommer oor al hierdie dinge nie. Die tipiese werkvloei sal nie baie verskil van die werk met 'n Git-remote nie.

Daar is een ding waaraan ons aandag moet gee voordat ons voortgaan: ignores. Mercurial en Git gebruik 'n baie soortgelyke meganisme hiervoor, maar dit is waarskynlik dat jy nie werklik 'n .gitignore lêer in 'n Mercurial-bewaarplek wil vaslê nie. Gelukkig het Git 'n manier om lêers te ignoreer wat plaaslik is vir 'n bewaarplek op die skyf, en die Mercurial-formaat is versoenbaar met Git, so jy hoef dit net oór te kopieer:

Die .git/info/exclude lêer tree presies soos 'n .gitignore op, maar word nie in vasleggings ingesluit nie.

Kom ons aanvaar dat ons 'n bietjie werk gedoen het en 'n paar vasleggings op die master tak gemaak het, en jy is gereed om dit na die afgeleë bewaarplek te push. Hier is hoe ons bewaarplek op die oomblik lyk:

Ons master tak is twee vasleggings voor op origin/master, maar daardie twee vasleggings bestaan slegs op ons plaaslike masjien. Kom ons kyk of iemand anders terselfdertyd belangrike werk gedoen het:

Aangesien ons die --all vlag gebruik het, sien ons die “notes” verwysings wat intern deur git-remote-hg gebruik word, maar ons kan hulle ignoreer. Die res is wat ons verwag het; origin/master het met een vaslegging gevorder, en ons geskiedenis het nou uiteengegaan. In teenstelling met die ander stelsels waarmee ons in hierdie hoofstuk werk, is Mercurial in staat om saamsmeltings (merges) te hanteer, so ons gaan niks fancy doen nie.

Perfek. Ons laat die toetse loop en alles slaag, so ons is gereed om ons werk met die res van die span te deel:

Dis dit! As jy 'n kykie neem na die Mercurial-bewaarplek, sal jy sien dat dit gedoen het wat ons sou verwag:

Die wysigingstel genommer 2 is deur Mercurial gemaak, en die wysigingstelle genommer 3 en 4 is deur git-remote-hg gemaak deur vasleggings te push wat met Git gemaak is.

Git het slegs een tipe tak: 'n verwysing wat skuif wanneer vasleggings gemaak word. In Mercurial word hierdie tipe verwysing 'n “boekmerke” ("bookmark") genoem, en dit tree op baie dieselfde manier op as 'n Git-tak.

Mercurial se konsep van 'n “tak” ("branch") is swaarder. Die tak waarop 'n wysigingstel gemaak word, word met die wysigingstel opgeteken, wat beteken dit sal altyd in die bewaarplekgeskiedenis wees. Hier is 'n voorbeeld van 'n vaslegging wat op die develop tak gemaak is:

Let op die reël wat begin met “branch”. Git kan dit nie regtig repliseer nie (en hoef dit ook nie; beide tipes takke kan as 'n Git-verwysing voorgestel word), maar git-remote-hg moet die verskil verstaan, omdat Mercurial daaroor gee.

Die skep van Mercurial-boekmerke is net so maklik as die skep van Git-takke. Aan die Git-kant:

Dis al wat daar is. Aan die Mercurial-kant lyk dit soos dit:

Let op die nuwe [featureA] merker op hersiening 5. Hierdie tree presies soos Git-takke aan die Git-kant op, met een uitsondering: jy kan nie 'n boekmerk van die Git-kant af verwyder nie (dit is 'n beperking van afgeleë helpers).

Jy kan ook aan 'n “swaargewig” Mercurial-tak werk: plaas net 'n tak in die branches naamruimte (namespace):

Hier is hoe dit aan die Mercurial-kant lyk:

Die taknaam “permanent” is opgeteken met die wysigingstel gemerk 7.

Van die Git-kant af is die werk met enige van hierdie takstyle dieselfde: trek net uit (checkout), lê vas (commit), haal af (fetch), smelt saam (merge), trek in (pull), en push soos jy normaalweg sou doen. Een ding wat jy moet weet, is dat Mercurial nie die herskrywing van geskiedenis ondersteun nie, slegs die byvoeging daarby. Hier is hoe ons Mercurial-bewaarplek lyk na 'n interaktiewe herbasering (rebase) en 'n geforceerde push:

Wysigingstelle 8, 9 en 10 is geskep en behoort aan die permanent tak, maar die ou wysigingstelle is steeds daar. Dit kan baie verwarrend wees vir jou spanmaats wat Mercurial gebruik, so probeer om dit te vermy.

Git en Mercurial is soortgelyk genoeg dat die werk oor die grens heen redelik pynloos is. As jy vermy om geskiedenis te verander wat jou masjien verlaat het (soos algemeen aanbeveel word), is jy dalk nie eens bewus daarvan dat die ander kant Mercurial is nie.

Perforce verskaf 'n produk genaamd Git Fusion (beskikbaar by https://www.perforce.com/manuals/git-fusion/), wat 'n Perforce-bediener aan die bedienerkant met Git-bewaarplekke sinchroniseer.

git-p4 is 'n tweerigtingbrug tussen Git en Perforce. Dit loop geheel en al binne jou Git-bewaarplek, so jy sal geen vorm van toegang tot die Perforce-bediener benodig nie (behalwe gebruikersbewyse, natuurlik). git-p4 is nie so 'n buigsame of volledige oplossing as Git Fusion nie, maar dit laat jou wel toe om die meeste te doen van wat jy wil doen sonder om indringend vir die bedieneromgewing te wees.

git-p4 maak dit moontlik om 'n Git-werkvloei met 'n Perforce-bediener te gebruik, en dit is nogal goed daarin. Dit is egter belangrik om te onthou dat Perforce in beheer van die bron is, en jy gebruik slegs Git om plaaslik te werk. Wees net baie versigtig oor die deel van Git-vasleggings; as jy 'n remote het wat ander mense gebruik, moenie enige vasleggings push wat nie reeds by die Perforce-bediener ingedien is nie.

As jy vryelik die gebruik van Perforce en Git as kliënte vir bronbeheer wil meng, en jy kan die bedieneradministrateur oortuig om dit te installeer, maak Git Fusion die gebruik van Git 'n eersteklas weergawebeheerkliënt vir 'n Perforce-bediener.