7.1 Git и други системи - Git като клиент

Основната команда в Git за всички Subversion функционалности е git svn. Тя приема множество подкоманди и ще покажем най-използваните от тях симулирайки няколко прости работни процеса.

Важно е да помним, че използвайки git svn ние комуникираме със Subversion, система функционираща по много различен начин от Git. Въпреки че можете да правите локални клонове и сливания, в общи линии е най-добре да поддържате историята си възможно най-праволинейна използвайки пребазирания и избягвайки да правите неща като едновременна комуникация с отдалечени Git хранилища.

Не опитвайте да пренаписвате историята и да правите повторно публикуване и не публикувайте в паралелно Git хранилище за да сътрудничите с други Git колеги по едно и също време. Subversion може да има само една, линейна история и е много лесно да бъде объркана. Ако работите с екип и някои от вас използват SVN, а други Git — уверете се, че всички разработчици използват SVN сървъра за споделяне на работа, това ще ви улесни живота значително.

За целите на демонстрацията, се нуждаем от стандартно SVN хранилище с права за писане в него. Ако искате да копирате следващите примери, ще трябва да направите writeable копие на тестово Subversion хранилище. Най-лесно ще направите това с инструмента svnsync, който се разпространява със Subversion.

Първо, създаваме ново локално Subversion хранилище:

След това, позволете всички да могат да променят revprops — лесният начин за това е да добавите скрипт pre-revprop-change, който винаги излиза с exit 0:

Сега можете да синхронизирате този проект в локалната машина изпълнявайки svnsync init с целево и изходно хранилища.

Това настройва параметрите за стартиране на синхронизацията. След това може да клонирате кода с:

Въпреки, че тази операция може да отнеме само няколко минути, ако се опитате да копирате оригиналното хранилище към друго отдалечено такова (вместо към локално), процесът ще продължи близо час при все че има по-малко от 100 къмита. Subversion ще трябва да клонира една версия в един момент и след това да я публикува обратно в друго хранилище — това е тотално неефективно, но е единственият наличен начин.

След като вече имате Subversion хранилище, до което имате права за писане, можете да изпълните един типичен работен процес. Ще започнем с командата git svn clone, която импортира цяло Subversion хранилище в локално Git такова. Да не забравяме, че импортираме от реално хостнато Subversion хранилище, така че трябва да заменим израза file:///tmp/test-svn с URL-а на вашето Subversion хранилище:

Това всъщност изпълнява еквивалента на две команди, git svn init последвана от git svn fetch към URL-а посочен от вас. Процесът може да отнеме доста време. Ако например тестовият проект имаше само около 75 къмита и сорс кодът не е много голям, Git независимо от всичко ще трябва да извлече всяка една версия индивидуално и да я къмитне индивидуално всеки път. За проект със стотици или хиляди къмити, това буквално може да отнеме часове или дори дни.

Частта от командата -T trunk -b branches -t tags указва на Git, че това Subversion хранилище следва основните branching и tagging конвенции. Ако вие именувате вашия trunk, клонове или тагове по различен начин, можете да промените тези опции. Понеже това е толкова често ползвано, можете да замените целия израз просто с флага -s, което означава standart layout и прилага трите горни опции. Така че тази команда е еквивалентна:

В този момент вече трябва да разполагате с валидно Git хранилище с импортирани тагове и клонове:

Отбележете как инструментът управлява Subversion таговете като отдалечени референции. Нека погледнем в повече дълбочина с plumbing командата на Git show-ref:

Git не прави това при клониране от Git сървър, ето как изглежда прясно клонирано хранилище с тагове:

Git издърпва таговете директно в refs/tags, вместо да ги третира като отдалечени клонове.

След като имаме работна директория, можем да извършим някакви промени по нея и да публикуваме къмитите си обратно използвайки Git практически като SVN клиент. Ако променим един от файловете и къмитнем промяната, ще имаме къмит съществуващ локално, но не и на Subversion сървъра:

Следващата стъпка е да публикуваме тази промяна. Забележете как това променя начина ви на работа със Subversion — можете да направите повече от един локален къмит офлайн и след това да изпратите всички наведнъж към Subversion сървъра. За да направите това, използвайте командата git svn dcommit:

Командата взема всички ваши новоизвършени къмити, създава Subversion къмит за всеки от тях и след това редактира локалния ви Git къмит за да включи уникален идентификатор. Това е важно, защото означава, че всичките ви SHA-1 чексуми на вашите къмити се променят. Отчасти поради тази причина, да работите с Git базирани отдалечени версии на проектите едновременно със Subversion такива не е добра идея. Ако погледнете последния къмит, може да видите новодобавения идентификатор git-svn-id:

Забелязваме също така, че SHA-1 чексумата, която първоначално започваше с 4af61fd, когато къмитнахме сега започва с 95e0222. Ето защо, ако все пак настоявате да публикувате и към двата вида сървъри, трябва първо да направите това (dcommit) към Subversion сървъра, понеже това променя чексумата.

При съвместната работа в един момент неизбежно се стига до опит за публикуване на промени предизвикващи конфликт. Промяната с конфликт ще бъде отхвърлена докато не слеете работата на другия колега преди това. В git svn, това изглежда така:

За да се измъкнем от подобна ситуация, използваме git svn rebase, която издърпва от сървъра всички промени, които все още нямаме локално и след това пребазира текущата ни работа върху тях:

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

Отбележете, че за разлика от Git, при който трябва да слеете upstream промените, които ви липсват локално преди да можете да публикувате, git svn ви кара да правите това само ако промените предизвикват конфликт (точно както работи Subversion). Казано с други думи, ако някой друг публикува промени по един файл и след това вие публикувате промени по друг файл, dcommit ще си работи без проблем:

Това е важен за запомняне момент, защото резултатът ще е статус на проекта, който не съществува и на двата локални компютъра. Ако промените са несъвместими (но не правят конфликт) може да се окажете с проблеми, които са трудни за установяване. При един Git сървър това не е така — можете изцяло да тествате статуса на проекта на локалната ви машина преди да го публикувате, докато при Subversion дори не можете да сте сигурни, че статусите преди и след къмитването ви са идентични.

Трябва да използвате тази команда за изтегляне на промени от Subversion сървъра дори все още да не сте готови да къмитвате вашите. Можете да изпълните и git svn fetch за сваляне на новите данни, но git svn rebase изтегля и обновява локалните ви къмити с една команда.

Изпълнявайте git svn rebase регулярно, за да сте сигурни, че локалния ви код е актуален. Обаче трябва да сте сигурни, че работната ви директория е в чист вид, когато пуснете командата. Ако имате некъмитнати промени, трябва или да ги маскирате (stash) или временно да ги къмитнете преди изпълнението на git svn rebase, иначе командата ще спре ако види, че пребазирането ще доведе до merge конфликт.

Когато започнете да се чувствате удобно с похватите на работа на Git, доста вероятно е да започнете да правите topic клонове, да работите в тях и да ги сливате. Ако публикувате към Subversion сървър с git svn, може да искате да пребазирате работата си върху единичен клон всеки път вместо да сливате клонове. Причината да предпочетете пребазирането е, че Subversion поддържа линейна история и не обработва сливанията така, както го прави Git. Така че git svn следва само първия родител при конвертирането на snapshot-ите в Subversion къмити.

Да допуснем, че историята ни изглежда така: създали сме experiment клон, направили сме два къмита и след това сме го слели обратно в master. При изпълнение на dcommit, ще видим нещо такова:

Изпълнението на dcommit от клон със слята история работи добре с изключение на факта, че когато погледнете в историята на Git проекта, ще установите че двата къмита от клона experiment не са пренаписани, вместо това всички тези промени се появяват в SVN версията на единичния сливащ къмит.

Когато някой друг клонира тази работа, всичко което ще види е merge къмита ви с всичката работа обединена в него все едно сте изпълнили git merge --squash, но никакви подробности откъде и кога са промените направени от вас в experiment.

Клоновете в Subversion не са същите като в Git и ако можете да ги избягвате ще е най-добре. Но при все това, с git svn можете да създавате и да къмитвате в Subversion клонове.

За да създадете нов клон в Subversion, използвайте git svn branch [new-branch]:

Това прави еквивалента на svn copy trunk branches/opera командата в Subversion и работи на Subversion сървъра. Важно е да посочим, че това не ви прехвърля автоматично в този клон и ако сега къмитнете, къмитът ще отиде в клона trunk на сървъра, вместо в opera.

Git определя в кой клон отиват вашите dcommits гледайки върховете на всички ваши Subversion клонове в историята ви — трябва да имате само един и той трябва да е последния с git-svn-id в текущата ви branch история.

Ако искате да работите по повече от един клон едновременно, можете да настроите локалните клонове да правят dcommit към специфични Subversion клонове стартирайки ги от импортирания Subversion къмит за този клон. Ако искате клон opera, в който да работите отделно, може да изпълните:

Сега, ако желаете да слеете вашия opera клон в trunk (вашия master клон), можете да го направите с нормална команда git merge. Но трябва да предоставите описателно къмит съобщение (чрез -m) или сливането ще гласи “Merge branch opera” вместо нещо полезно.

Помнете, че независимо че използвате git merge за тази операция и че сливането вероятно ще е много по-лесно отколкото би било в Subversion (защото Git автоматично ще установи подходящата merge база за вас), това не е стандартен Git merge къмит. Ще трябва да изпратите тези данни към Subversion сървър, който не може да обработва къмит следящ повече от един родител и когато го направите, те ще изглеждат като единичен къмит обединяващ цялата извършена работа от друг клон. След като слеете един клон в друг, не можете лесно да се върнете и да продължите да работите по този клон, както нормално бихте могли в Git. Командата dcommit изтрива всяка информация казваща кой клон е бил слят, така че евентуалните следващи merge-base изчисления ще са погрешни — dcommit прави така, че резултатът от git merge да изглежда като от git merge --squash. За жалост няма добър начин за избягване на такава ситуация — Subversion не може да пази тази информация и винаги ще бъдете ограничавани, когато го използвате като сървър. За да си спестите проблеми, добре е да изтривате локалния клон (в този случай opera) след като го слеете в trunk.

Инструментите на git svn осигуряват множество команди, които подпомагат по-лесното минаване към Git, предоставяйки функционалности подобни на тези в Subversion. Ето няколко команди, които ви дават това, което и Subversion.

Инструментите на git svn са полезни, ако си имате работа със Subversion сървър по една или друга причина. Би следвало да гледате на Subversion като на орязан Git или ще си имате проблеми в превода, предизвикващи объркване у вас и у колегите ви. За да си спестите главоболия, опитайте да спазвате тези правила:

Спазвате ли тези съвети, работата ви със Subversion сървъри би могла да бъде по-поносима. Обаче, ако е налична възможност да преминете към реален Git сървър, това ще даде на екипа ви много повече позитиви.

Първо, трябва да инсталираме git-remote-hg. Практически това се изчерпва с копирането на файла някъде в пътя ви:

…допускаме че ~/bin е включен в пътищата на променливата $PATH. Git-remote-hg има и още една друга зависимост: библиотеката mercurial за Python. Ако имате инсталиран Python, това е лесно:

Ако нямате Python, посетете https://www.python.org/ и го инсталирайте преди това.

Последното нещо, от което се нуждаем, е Mercurial клиента. Изтеглете го и го инсталирайте от https://www.mercurial-scm.org/.

Сега сте готови за работа. Имаме нужда от Mercurial хранилище, в което можем да публикуваме. За късмет, всяко Mercurial хранилище може да работи по такъв начин, така че ще използваме стандартното "hello world", което всички използват за да учат Mercurial:

След като имаме подходящо “server-side” хранилище, можем да преминем през един стандартен работен процес. Както ще видите, тези две системи са доста подобни и не би трябвало да имате големи трудности.

Както винаги с Git, първо клонираме:

Веднага забелязваме, че при работата с Mercurial хранилища се използва стандартната git clone команда. Това е така, понеже git-remote-hg работи на сравнително ниско ниво, използвайки механизъм подобен на този, който Git използва за HTTP/S комуникация (remote helpers). И Git и Mercurial са проектирани така, че всеки клиент да има пълно копие на историята на хранилището и тази команда ви осигурява цялостно клониране, включващо цялата история на проекта — при това сравнително бързо.

Командата log показва два къмита, към последния от които сочи цял куп референции. Оказва се, че някои от тях реално не са там. Нека видим какво действително съдържа директорията .git:

Git-remote-hg се опитва да прави нещата в стила на Git, но зад кулисите тя управлява концептуалното свързване между две леко различаващи се системи. Директорията refs/hg съдържа действителните отдалечени референции. Например, refs/hg/origin/branches/default е Git ref файл, който съдържа SHA-1 започваща с “ac7955c”, което е къмита, към който сочи master. По този начин refs/hg директорията е нещо като фалшива refs/remotes/origin, но също така може да различава bookmarks и branches.

Файлът notes/hg е изходната точка за това как git-remote-hg съотнася хешовете на Git къмитите с changeset идентификаторите на Mercurial. Нека погледнем по-подробно:

И така refs/notes/hg сочи към дърво, което в базата данни с обекти на Git е представено като списък от други обекти с имена. git ls-tree отпечатва режима, типа, хеш стойността и името на файла за елементите в дървото. Ако поразгледаме един от елементите на дървото, откриваме, че вътре има blob наречен “ac9117f” (SHA-1 хеша на къмита, към който сочи master), със съдържание “0a04b98” (което е ID-то на Mercurial changeset-а на върха на клона default).

Добрата новина е, че почти не се налага да се занимаваме с всичко това. Типичният работен процес няма да е много различен от този, при който работим с Git remote.

Трябва да обърнем внимание на още едно нещо преди да продължим, игнориранията. Mercurial и Git използват много подобен механизъм за това, но е вероятно да не искате да публикувате .gitignore файл в Mercurial хранилище. За щастие Git има начин да игнорира файлове, които са локални за хранилище на диска и форматът на Mercurial е съвместим с този на Git, така че просто трябва да копирате съответния файл:

Файлът .git/info/exclude работи точно като .gitignore, но не влиза в къмитите.

Да допуснем, че сме извършили някаква работа в проекта, имаме няколко къмита в клона master и сме готови да публикуваме промените. Ето как изглежда хранилището ни сега:

Нашият master клон е с два къмита напред спрямо origin/master, но те са само на локалната машина. Нека проверим дали някой друг не е публикувал някаква важна промяна междувременно:

Понеже използвахме флага --all, виждаме референциите “notes”, които се използват вътрешно от git-remote-hg, можем да ги игнорираме. Останалото е каквото се очаква; origin/master е обновен с един къмит и историята ни сега е разклонена (diverged). За разлика от другите системи, които преглеждаме в тази глава, Mercurial може да обработва сливания, така че няма да се налага да правим нищо необичайно.

Перфектно. Пускаме си тестовете, те минават добре и сме готови да публикуваме промените си на сървъра:

Това е всичко! Ако погледнете Mercurial хранилището, ще видите че Push операцията е направила каквото се очаква:

Changeset-ът с номер 2 е създаден от Mercurial, а тези с номера 3 и 4 са направени от git-remote-hg, в резултат от публикуването на къмитите от Git.

Git има само един вид клон: референция, която се премества с правенето на къмити. В Mercurial, този тип референция се нарича “bookmark,” и тя се държи почти по същия начин като Git клон.

Концепцията на Mercurial за понятието “branch” е по-различна. Клонът, върху който е създаден changeset се записва с changeset-a, което значи че той винаги ще бъде в историята на хранилището. Ето пример за къмит направен в клона develop:

Забележете реда, който започва с “branch”. Git не може в действителност да пресъздаде това (а и не се нуждае, и двата типа клонове могат да се представят като Git референции), но git-remote-hg трябва да разбира разликата, защото Mercurial ѝ обръща внимание.

Създаването на Mercurial bookmarks е лесно колкото създаването на Git клонове. На Git страната:

Това е всичко по въпроса. От страната на Mercurial това изглежда така:

Забележете новия таг [featureA] на revision 5. Тези работят точно както Git клонове от страната на Git с едно изключение: не можете да изтриете bookmark от страната Git (това е ограничение на remote helpers).

Освен с Mercurial bookmarks, можете да работите и с “heavyweight” Mercurial клонове: просто ги създавате в branches namespace:

Ето как ще изглежда това от страната на Mercurial:

Името на клона “permanent” беше записано с changeset-а маркиран като 7.

От гледна точка на Git, работата с тези два вида клонове е една и съща: превключвате, къмитвате, изтегляте, сливате и публикувате както нормално се прави в Git. Нещо, което трябва да отбележим е, че Mercurial не поддържа презапис на историята, към нея може само да се добавя. Ето как ще изглежда нашето Mercurial хранилище след интерактивно пребазиране последвано от force-push:

Changeset-ите 8, 9, и 10 са създадени и принадлежат към клона permanent, но старите changesets са все още там. Това може да е много смущаващо за колегите ви използващи Mercurial, така че се старайте да го избягвате.

Git и Mercurial са много подобни, така че съвместната им работа е сравнително безболезнена. Ако избягвате да преправяте историята, която публикувате (още веднъж, това е горещо препоръчително), може дори и да не разберете, че от другия край на връзката стои Mercurial система.

Инструментът е лесен за ползване. Достатъчно е да клонирате Bazaar хранилище като му дадете префикс bzr::. Понеже Git и Bazaar правят пълно клониране върху локалния компютър, възможно е да прикачите Git копие към локалното ви Bazaar копие на хранилище, въпреки че това не е препоръчително. Много по-лесно е да закачите вашето Git копие към същото място, към което е закачено Bazaar копието — към централното хранилище.

Приемаме, че работим с отдалечено хранилище на адрес bzr+ssh://developer@mybazaarserver:myproject. Клонираме го така:

На този етап Git хранилището е създадено, но не е оптимизирано за ефективно използване на диска. Ето защо е хубаво да почиствате и compact-вате вашите Git хранилища, особено ако са големи:

Bazaar позволява само да клонирате клонове, но едно хранилище може да има много такива и git-remote-bzr може да ги клонира всички. Например, за да клонирате клон:

За да клонирате цялото хранилище:

Втората команда прави копия на всички клонове в emacs хранилището, но е възможно да укажете и само някои от тях:

Някои отдалечени хранилища не позволяват да показвате клоновете им и в такива случаи трябва да ги укажете ръчно. Въпреки, че можете да го направите в командата за клониране, това може да ви се стори по-лесно:

Понеже работите по Bazaar-контролиран проект, не трябва да създавате .gitignore файл, защото можете по невнимание да го включите в контрола и тогава другите хора работещи с Bazaar ще бъдат объркани. Решението е да създадете .git/info/exclude файл като символна връзка или като нормален такъв. По-късно ще видим как да се справим с това.

Bazaar използва същия модел за игнориране на файлове като Git, но в допълнение има две възможности без еквивалент в Git. Пълното описание може да се намери в документацията. Тези две възможности са:

В резултат на това, възникват две различни ситуации:

Във всички случаи трябва да бъдете внимателни за всяка бъдеща промяна по .bzrignore за да сте сигурни, че .git/info/exclude винаги отразява коректно съдържанието му. Ако .bzrignore се промени и се появят редове започващи с "!!" или "RE:", то Git няма да може да ги интерпретира и ще трябва да адаптирате вашия .git/info/exclude файл да прави същото като .bzrignore. Освен това, ако .git/info/exclude преди това е бил символна връзка, първо ще трябва да я изтриете, да копирате .bzrignore в .git/info/exclude и да го редактирате за коректна адаптация. Обаче, бъдете внимателни със създаването на файла, защото с Git не е възможно да включите повторно файл, ако родителската директория на този файл е изключена.

За издърпване на промени се използват стандартните Git команди. Подразбирайки, че промените ви са в master клона, вие сливате или пребазирате работата си върху origin/master клона:

Bazaar също като Git поддържа концепцията за merge къмити, така че няма да има проблем с публикуването на такива. Можете спокойно да работите по отделен клон, да го слеете в master и след това да публикувате. Създавате клонове, тествате и къмитвате както обикновено. Накрая изпращате работата си в Bazaar хранилището:

Remote helper-ите на Git си имат някои ограничения. По-специално, следните команди не работят:

Моделите на Git и Bazaar си приличат и по тази причина съвместната им работа не е толкова проблемна. Стига да съблюдавате ограниченията и винаги да помните, че отдалеченото хранилище не е реално Git такова, не би следвало да срещате съществени трудности.

Perforce предоставя продукта Git Fusion (наличен на http://www.perforce.com/git-fusion), който синхронизира Perforce сървър с Git хранилища от страна на сървъра.

Git-p4 е двупосочен бридж между Git и Perforce. Той работи изцяло във вашето Git хранилище, така че не ви трябва никакъв достъп до Perforce сървър (като изключим потребителските име и парола, разбира се). Git-p4 не е толкова гъвкаво и пълно решение като Git Fusion, но ви позволява да правите повечето неща, които бихте желали, без да се налага да пипате по сървъра.

Инструментът Git-p4 прави възможно използването на Git работен процес при работа с Perforce сървър и е добър в това. Обаче, важно е да се помни, че Perforce обработва сорс кода и Git се използва само за локална работа. Просто бъдете наистина внимателни при споделяне на Git къмити, ако имате отдалечена референция ползвана и от други хора, не публикувайте никакви къмити, които преди това не са изпратени към Perforce сървъра.

Ако искате свободно да смесвате използването на Perforce и Git като клиенти за сорс контрол и ако успеете да убедите системния ви администратор да го инсталира, то Git Fusion превръща Git в първокласен version-control клиент за Perforce сървър.