9.1 Гит и остали системи - Гит као клијент

Основна команда у програму Гит за све команде премошћавања до Subversion је git svn. Постоји поприличан број команди, тако да ћемо приказати најчешће док пролазимо кроз неколико једноставних процеса рада.

Важно је приметити да када користите git svn, ви имате интеракцију са програмом Subversion, а то је систем који функционише веома различито у односу на програм Гит. Мада можете да радите локално гранање и спајање, у општем случају је најбоље да историју држите што је могуће више линеарном тако што ребазирате свој рад и избегавате да радите ствари као што је истовремена интеракција са удаљеним Гит репозиторијумом.

Немојте поново да исписујете своју историју и покушате поново да је гурнете и немојте да истовремено гурате на паралелни Гит репозиторијум како би сарађивали са колегама који за развој користе Гит. Subversion може да има са једну линеарну историју, и врло је једноставно да га збуните. Ако радите у тиму где неко користи SVN, а остали користе Гит, обезбедите да сви за сарадњу користе SVN сервер – на тај начин ће вам живот бити једноставнији.

Да бисте пробали ову функционалност, потребан вам је типичан SVN репозиторијум на који има те право уписа. Ако желите да копирате ове примере, мораћете да направите копију мог тест репозиторијума по којој можете да пишете. То једноставно можете урадити алатом који се зове svnsync и долази уз програм Subversion. Као подршку овим тестовима, направили смо нови Subversion репозиторијум на Google Code који је представљао делимичну копију пројекта protobuf, алата који кодира структуре података тако да могу да се преносе кроз мрежу.

Да бисте успешно пратили, најпре морате да креирате нови локални Subversion репозиторијум:

Затим омогућите свим корисницима право да мењају revprops – то се на једноставан начин ради тако да додате скрипту pre-revprop-change која увек враћа повратну вредност 0:

Овај пројекат сада можете да синхронизујете на своју локалну машину тако што позовете svnsync init са ’из’ и ’у’ репозиторијумима.

Ово поставља особине за позив синхронизације. Затим клонирате кôд извршавајући:

Мада ова операција може да потраје само неколико минута, ако уместо на локални оригинални репозиторијум покушате да копирате на други удаљени репозиторијум, процес ће трајати скоро сат времена, мада постоји мање од 100 комитова. Subversion мора да клонира ревизије једну по једну, па да их затим гурне на други репозиторијум – потпуно неефикасно, али је то једини начин да се ово уради.

Сада када имате Subversion репозиторијум у који можете да уписујете, можете да прођете кроз типичан процес рада. Почећете да командом git svn clone која увози комплетан Subversion репозиторијум у локални Гит репозиторијум. Упамтите да ако увозите из реалног хостованог Subversion репозиторијума, фајл file:///tmp/test-svn приказан овде треба да замените са URL адресом вашег Subversion репозиторијума:

Ово извршава еквивалент две команде – git svn init након које следи git svn fetch – над URL адресом коју наведете. Може да потраје. Тест пројекат има само око 75 комитова и база кода није толико велика, али програм Гит мора да одјави сваку верзију, једну по једну, па да је засебно комитује. За пројекат са стотинама или хиљадама комитова, ово буквално може да потраје сатима или чак данима док се не заврши.

-T trunk -b branches -t tags део говори програму Гит да овај Subversion репозиторијум прати основне конвенције гранања и означавања. Ако свом стаблу, гранама или ознакама желите да дате другачија имена, промените ове опције. Пошто је ово толико уобичајено, комплетан део можете да замените са -s, што значи стандардни распоред и подразумева све те опције. Следећа команда је еквивалентна:

У овом тренутку би требало да имате исправан Гит репозиторијум које увезао ваше гране и ознаке:

Приметите како овај алат управља Subversion ознакама као удаљеним референцама. Хајде да детаљније погледамо водоводном командом програма Гит show-ref:

Програм Гит ово не ради када клонира са Гит сервера; ево како изгледа репозиторијум након свежег клонирања:

Програм Гит преузима ознаке директно у refs/tags, уместо да их третира као удаљене гране.

Сада када имате функционалан репозиторијум, можете да урадите неки посао на пројекту и гурнете своје комитове узводно, тако што програм Гит ефективно користите као SVN клијент. Ако уредите један од фајлова и комитујете га, имаћете комит који постоји локално у програму Гит и не постоји на Subversion серверу:

Затим, своју измену морате да гурнете узводно. Приметите како ово мења начин на који радите са програмом Subversion – можете да урадите неколико комитова док ста ван мреже, па да их све одједном гурнете на Subversion сервер. Када желите да гурнете на Subversion сервер, извршите команду git svn dcommit:

Ово узима све комитове које сте направили преко кода са Subversion сервера, за сваки од њих врши Subversion комит, па онда поново исписује ваш локални Гит комит тако да укључи јединствени идентификатор. То је важно јер значи да се све SHA-1 контролне суме ваших комитова мењају. Делимично због овог разлога, истовремени рад са удаљеним Гит верзијама вашег пројекта и Subversion сервером није добра идеја. Ако погледате последњи комит, можете видети уметнути нови git-svn-id:

Приметите да је SHA-1 контролна сума када сте раније комитовали почињала са 4af61fd, а да сада почиње са 95e0222. Ако желите да гурнете и на Гит и на Subversion сервер, прво морате да гурнете (dcommit) на Subversion сервер, јер та акција мења ваше комит податке.

Ако радите са другим програмерима, онда ће у неком тренутку један од вас гурнути, па ће онда неко други покушати да гурне измену која изазива конфликт. Та измена ће бити одбијена док не спојите њихов рад. У git svn то изгледа овако:

Да бисте разрешили ову ситуацију, можете да извршите git svn rebase, која повлачи евентуалне измене на серверу које још увек немате и ребазира ваш рад (ако га има) на врх онога што се налази на серверу:

Сада је сав ваш рад преко онога што се налази на Subversion серверу, тако да можете успешно извршити dcommit:

Приметите да за разлику од програма Гит, који од вас захтева да пре него што гурнете спојите сав узводни рад који још увек немате локално, git svn од вас то тражи само ако измене изазивају конфликт (слично као што ради и Subversion). Ако неко други гурне измену једног фајла, панда ви гурнете измену неког другог фајла, ваша dcommit ће функционисати без проблема:

Ово је важно да се запамти, је крајњи исход стање пројекта које није постојало ни на једном од ваших компјутера када сте гурнули. Ако измене нису компатибилне али не изазивају конфликт, можете имати проблеме који се тешко откривају. То је разлика у односу на употребу Гит сервера – у програму Гит Git стање можете потпуно тестирати на свом клијентском систему пре него што га објавите, док у SVN, никада не можете бити сигурни да су стања непосредно пре и након комита идентична.

Ову команду би такође требало да извршите за повлачење измена са Subversion сервера, чак и ако сами нисте спремни да комитујете. Можете извршити git svn fetch да само преузмете нове податке, али git svn rebase преузима па ажурира ваше локалне комитове.

Повремено извршавање git svn rebase обезбеђује да је ваш кôд увек у свежем стању. Ипак, да бисте ово извршили, морате бити сигурни да је ваш радни директоријум чист. Ако имате локалне измене, морате прво или да сакријете свој рад, или да га привремено комитујете пре покретања git svn rebase – у супротном ће команда прекинути извршавање ако види да ће резултат ребазирања изазвати конфликт при спајању.

Када вам Гит процес рада постане удобан, вероватно ћете почети да креирате тематске гране, радите на њима, па их спајате у главну. Ако гурате на Subversion сервер командом git svn, уместо да гране спајате могли бисте да свој рад ребазирате на једну грану. Ребазирање је пожељније од спајања јер Subversion има линеарну историју и не носи се са спајањима као што то ради програм Гит, тако да git svn следи само првог родитеља када конвертује снимке у Subversion комитове.

Претпоставимо да вам историја изгледа на следећи начин: креирали сте experiment грану, направили два комита, па их онда спојили назад у master. Када извршите dcommit, добијате следећи излаз:

Извршавање dcommit на грани са спојеном историјом ради како треба, није поново исписала ниједан од комитова које сте направили на experiment грани – уместо тога, све те измене се појављују у SVN верзији једног јединог комита спајања.

Када неко други клонира тај рад, све што види је комит спајања са комплетним радом сабијеним у њега, као да сте извршили git merge --squash; не види податке о томе одакле је комит дошао или када је направљен.

Гранање у програму Subversion није исто као гранање у програму Гит; вероватно је најбоље ако можете избећи да га често користите. Ипак, са git svn можете да креирате и комитујете Subversion гране.

Ако желите да креирате нову Subversion грану, извршите git svn branch [имегране]:

Ово је еквивалентно Subversion команди svn copy trunk branches/opera и оперише на Subversion серверу. Важно је приметити да она вас она не одјављује у ту грану; ако у овом тренутку комитујете, так комит иде у trunk на серверу, а не у opera.

Програм Git открива на коју грану иду ваши dcommit тако што гледа на врх било које Subversion гране у вашој историји – требало би да имате само једну, а то би у исорији тренутне гране требало да буде последња са git-svn-id.

Ако желите истовремено да радите на више од једне гране, команди dcommit можете да подесите локалне гране на одређене Subversion грана започињући их као увезени Subversion комит за ту грану. Ако желите грану opera на којој можете одвојено да радите, извршите:

Ако сада желите да своју opera грану спојите у trunk (односно вашу master грану), то можете урадити обичном git merge командом. Али морате навести описну комит поруку (са -m), или ће спајање уместо нечег корисниг да буде „Merge branch opera”.

Упамтите да мада за ову операцију користите git merge и спајање ће вероватно бити доста једноставније него што би било у програму Subversion (јер ће програм Гит аутоматски за вас да открије погодну базу за спајање), ово није уобичајен Гит комит спајања. Ове податке морате да гурнете назад Subversion серверу који не може да обради комит који прати више од једног родитеља; дакле, након што га гурнете узводно, изгледаће као један једини комит који је сабио сав рад на другој грани у један комит. Када једну грану спојите у другу, можете једноставно да се вратите назад и наставите да радите на тој грани, као и иначе што бисте у програму Гит. Команда dcommit коју извршавате брише било какве информације које кажу која грана је спојена, тако да ће накнадна израчунавања базе спајања вити погрешна – dcommit чини да резултат ваше git merge команде изгледа као да се извршили git merge --squash. Нажалост, не постоји добар начин да се избегне оваква ситуација – Subversion не може да забележи ову информацију, тако да ће вас увек спутавати његова ограничења док год га користите као свој сервер. Да бисте спречили проблеме, када је спојите у trunk требало би да обришете локалну грану (у овом случају, opera).

git svn скуп алата обезбеђује већи број команди које помажу да се олакша прелаз на Гит нудећи неку функционалност која је слична оној коју имате у програму Subversion. Ево неколико команди које вам пружају оно што је Subversion.

git svn алату су корисни ако сте заглављени на Subversion серверу, или у неком развојном окружењу у којем је неопходно покретање Subversion сервера. Ипак, требало би да га сматрате ограниченим програмом Гит, или ћете наићи на проблеме у превођењу коју могу да збуне и вас и ваше сараднике. Покушајте се држати следећих смерница како не бисте упали у невоље:

Ако следите ове препоруке, рад са Subversion сервером може постати подношљив. Међутим, ако постоји могућност, пређите на прави Гит сервер, на тај начин ћете и ви и тим добити још много више.

Најпре је потребно да инсталирате git-remote-hg. То практично значи да поставите његов фајл негде на путању, отприлике овако:

…уз претпоставку да се ~/bin налази у вредности ваше $PATH променљиве. Git-remote-hg има још једну зависност: mercurial библиотеку за Пајтон. Ако имате инсталиран језик Пајтон, то је просто као пасуљ:

Ако још увек немате инсталиран Пајтон, најпре посетите https://www.python.org/ и набавите га.

Последња ствар која вам је потребна је Меркуријал клијент. Посетите https://www.mercurial-scm.org/ и инсталирајте га, ако то већ нисте учинили.

Сада можете да пређете на ствар. Потребан вам је само Меркуријал репозиторијум на који можете да гурате. На срећу, сваки Меркуријал репозиторијум може да се понаша на овај начин, тако да ћемо једноставно употребити „hello world” репозиторијум који користи свако да научи Меркуријал:

Сада када имамо погодан „серверски” репозиторијум, можемо да прођемо кроз типични процес рада. Као што можете да видите, ова два система су довољно слична тако да нема много трења.

Најпре клонирамо, као што је увек и обичај у програму Гит:

Приметићете да рад са Меркуријал репозиторијумом користи стандардну git clone команду. То је зато јер git-remote-hg функционише на прилично ниском нивоу, користећи сличне механизме којима је имплементиран HTTP/S протокол у програму Гит (удаљени помоћници). Пошто су и Гит и Меркуријал дизајнирани тако да сваки клијент има комплетну копију историје репозиторијума, ова команда креира потпуни клон, укључујући комплетну историју пројекта, а то обавља прилично брзо.

Log команда приказује два комита, од којих на последњи показује читава шума референци. Испоставља се да неке од њих заиста и нису ту. Хајде да погледамо шта се заиста налази у .git директоријуму:

Git-remote-hg покушава да ствари буду што природније у Гит стилу, али под хаубом он управља концептуалним мапирањем између два незнатно различита система. Директоријум refs/hg је место где се чувају стварне референце. На пример, refs/hg/origin/branches/default је фајл Гит референце који садржи SHA-1 што почиње на „ac7955c” и то је комит на који показује master. Тако да је директоријум refs/hg нека врста лажног refs/remotes/origin, али уз додато прављење разлике између маркера и грана.

Фајл notes/hg је почетна тачка из које git-remote-hg мапира Гит комит хешеве у Меркуријал идентификаторе скупа измена. Хајде да истражимо мало:

Дакле, refs/notes/hg показује на стабло које у Гит бази података објеката представља листу осталих објеката са именима. git ls-tree исписује режим, тип, хеш објекта и име фајла за ставке унутар стабла. Када дођемо да једне од ставке стабла, видимо да се у њој налази блоб под именом „ac9117f” (SHA-1 хеш комита на који показује master), и садржајем „0a04b98” (ID Меркуријал скупа измена на врху default гране).

Добра вест је да углавном уопште нема потребе да бринемо о свему овоме. Типичан процес рада се неће много разликовати од рада са Гит удаљеним репозиторијумом.

Постоји још једна ствар коју би требало да обрадимо пре него што наставимо: игнорисања. Меркуријал и Гит за то користе врло сличан механизам, али вероватно не желите да заиста комитујете .gitignore фајл у Меркуријал репозиторијум. На сву срећу, програм Гит има начин да игнорише фајлове који су локални репозиторијуми на диску, а Меркуријал формат је компатибилан са Гит форматом, тако да једноставно можете да га прекопирате:

Фајл .git/info/exclude се понаша као .gitignore, али није део комитова.

Хајде да претпоставимо да смо урадили неки посао и направили неколико комитова на master грану, па сте сада спремни да их гурнете на удаљени репозиторијум. Ево како наш репозиторијум сада изгледа:

Наша master грана се налази два комита испред origin/master, али та два комита постоје само на нашој локалној машини. Хајде да видимо да ли је још неко у исто време радио важан посао:

Пошто смо употребили заставицу --all, видимо „notes” референце које git-remote-hg интерно користи, али их можемо занемарити. Остатак је оно што смо и очекивали; origin/master је напредовала за један комит, па се наша историја сада раздвојила. За разлику од осталих система са којима радимо у овом поглављу, Меркуријал је способан да обради спајања, тако да нема потребе да радимо било шта спектакуларно.

Савршено. Покрећемо тестове и све пролази како треба, тако да смо спремни да свој рад поделимо са остатком тима:

И то је то! Ако погледате Меркуријал репозиторијум видећете да је ова команда урадила оно што смо и очекивали:

Скуп измена под бројем 2 је направио Меркуријал, а скупове измена 3 и 4 git-remote-hg, гурањем комитова који су креирани програмом Гит.

Програм Git има само једну врсту грана: референцу која се помера када се направе комитови. У програму Меркуријал се ова врста референце назива „маркер” (bookmark) и понаша се скоро исто као и грана у програму Гит.

Концепт „гране” у програму Меркуријал има много дубље значење. Грана на којој се креира скуп измена се чува заједно са скупом измена, што значи да ће увек бити у историји репозиторијума. Ево примера комита који је направљен на develop грани:

Приметите линију која почиње са „branch”. Програм Гит ово не може у потпуности да преслика (и нема потребе за тим; оба типа гране се могу представити као Гит референца), али git-remote-hg мора да разуме разлику, јер је Меркуријал прави.

Креирање Меркуријал маркера је једноставно као креирање Гит грана. На Гит страни:

И то је све. На Меркуријал страни, изгледа овако:

Приметите нову ознаку [featureA] на ревизији 5. Оне се понашају потпуно исто као Гит гране са стране програма Гит, уз један изузетак: маркер не можете да обришете са стране програма Гит (ово је ограничење помоћника за удаљене).

Такође можете да радите и на „тешким” Меркуријал гранама: једноставно ставите грану у branches простор имена:

Ево како то изгледа са Меркуријал стране:

Име гране „permanent” је снимљено са скупом измена под ознаком 7.

Гледано са Гит стране, рад са било којоим од ова два стила грана је сити: једноставно одјављујете, комитујете, преузимате, спајате, повлачите и гурате као и иначе. Једна ствар коју би требало да знате је да Меркуријал не подржава поновно исписисвање историје, може само да додаје у историју. Ево како наш Меркуријал репозиторијум изгледа након интерактивног ребазирања и наметнутог гурања:

Креирани су скупови измена 8, 9, и 10 и припадају permanent грани, али су још увек присутни стари скупови измена. Ово може тотално да збуни ваше колеге из тима који користе Меркуријал, па би било добро да то не радите.

Програми Гит и Меркуријал су довољно слични да је рад са друге стране границе прилично безболан. Ако избегнете мењање историје која је остала на вашој машини (као што се и иначе препоручује), можда нећете ни приметите да је са друге стране Меркуријал.

Ово је једноставно. Довољно је да клонирате Базаар репозиторијум тако што испред имена наведете bzr::. Пошто и Гит и Базаар раде потпуно клонирање на вашу машину, Гит клон може да се прикачи на Базаар клон, али се то не препоручује. It’s much easier to attach your Git clone directly to the same place your Bazaar clone is attached to — the central repository.

Претпоставимо да сте радили са удаљеним репозиторијумом који се налази на адреси bzr+ssh://developer@mybazaarserver:myproject. Затим морате да га клонирате на следећи начин:

У овом тренутку имате креиран Гит репозиторијум, али он није оптимизован за ефикасно искоришћење диска. Зато би требало да пречистите и сажмете ваш Гит репозиторијум, посебно ако је велики:

Базаар вам дозвољава само да клонирате гране, али репозиторијум може да садржи неколико грана, па git-remote-bzr може да клонира и једно и друго. На пример, ако желите да клонирате грану:

А да клонирате комплетан репозиторијум:

Друга команда клонира све гране које се налазе у emacs репозиторијуму; међутим, ипак је могуће да се укаже на поједине гране:

Неки репозиторијуми вам не дозвољавају да видите њихове гране, па их у том случају морате ручно навести, мада бисте могли да наведете конфигурацију у команди клонирања, можда вам је ово лакше:

Пошто радите на пројекту којим управља Базаар, не би требало да креирате .gitignore фајл јер нехотично можете да га поставите под контролу верзија и то може засметати осталим људима који користе Базаар. Решење је да фајл .git/info/exclude креирате или као симболички линк или као обичан фајл. Касније ћемо видети како се решава ово питање.

Базаар за игнорисање фајлова користи исти модел као и програм Гит, али има и две могућности које немају свој еквивалент у програму Гит. Комплетан опис се налази у документацији. Могућности су следеће:

Као последица, постоје две различите ситуације о којима треба да размислите:

Шта год да је случај, мораћете остати на опрезу у случају било какве измене фајла .bzrignore и да осигурате да фајл .git/info/exclude увек пресликава .bzrignore. Заиста, ако би измена .bzrignore фајла садржала једну или више линија које почињу са „!!” или „RE:”, како програм Git не може те линије да интерпретира, морали бисте да преправите свој .git/info/exclude фајл тако да игнорише исте фајлове као оне које игнорише .bzrignore фајл. Уз то, ако је .git/info/exclude фајл уствари симболички линк, прво морате да обришете симболички линк, копирате .bzrignore у .git/info/exclude па да онда прилагодите овај други. Међутим, будите опрезни у вези креирања овог фајла, јер је са програмом Гит немогуће поновно укључивање фајла ако је директоријум родитељ тог фајла искључен.

Да бисте преузели измене са удаљеног, повлачите измене као и обично, употребом команди програма Гит. Под претпоставком да су ваше измене на master грани, спајате или ребазирате свој рад на origin/master грану:

Пошто и Базаар има концепт комитова спајања, неће бити проблема ако гурнете комит спајања. Тако да можете радити на грани, спојити измене у master и гурнути свој рад. Затим, креирате своје гране, тестирате и комитујете рад као и обично. На крају гурнете свој рад на Базаар репозиторијум:

Радни оквир програма Гит за удаљене помоћнике има нека ограничења која важе. Тачније, следеће команде не функционишу:

Пошто су модели програма Гит и Базаар слични, нема много отпора када радите с друге стране границе. Док год пазите на ограничења и свесни сте да удаљени репозиторијум није природно Гит, биће све у реду.

Перфорс нуди производ под називом Git Fusion (доступан на http://www.perforce.com/git-fusion), који са серверске стране синхронизује Перфорс сервер са Гит репозиторијумима.

Git-p4 је двосмерни мост између програма Гит и Перфорс. Потпуно се извршава у вашем Гит репозиторијуму, тако да вам не треба никакав приступ Перфорс серверу (осим корисничких акредитива, наравно). Git-p4 није тако флексибилно или комплетно решење као Git Fusion, али омогућава да урадите већину онога што бисте желели да урадите, а да не залазите у окружење сервера.

Git-p4 омогућава да се са Перфорс сервером употребљава Гит процес рада, и прилично је добра у томе. Међутим, важно је упамтити да је Перфорс управља изворним кодом, а ви програм Гит користите само за рад у локалу. Само будите врло пажљиви са дељењем Гит комитова; ако имате удаљени репозиторијум који користе и други људи, не гурајте било које комитове који већ нису достављени Перфорс серверу.

Ако желите да слободно мешате упторебу програма Перфорс и програма Гит као клијената за контролу изворног кода, а администратора сервера можете убедити да га инсталира, Git Fusion чини да Гит постане првокласни клијент Перфорс сервера за контролу верзија.