9.1 Ang Git at iba pang mga Sistema - Git bilang isang Kliyente

Ang base na utos sa Git para sa lahat ng Subversion na pagtutulay na mga utos ay ang git svn. Ito ay kumukuha ng ilang mga utos, kaya ipapakita natin ang madalas na karaniwan habang pumupunta sa iilang simpleng workflow.

Importanteng tandaan na kapag ikaw ay gumagamit ng git svn, ikaw ay nakikipag-ugnayan sa Subversion, na isang sistema na sobrang kakaibang gumagana mula sa Git. Bagaman maaari kang gumawa ng lokal na pag-branch at pag-merge, ito ay pangkalahatang pinakamahusay upang panatilihin ang iyong kasaysayan bilang linear hangga’t maaari sa pamamagitan ng pag-rebase ng iyong trabaho, at iiwasan ang paggawa ng mga bagay katulad ng sabay-sabay na pakikipag-ugnayan sa isang Git na remote na repositoryo.

Huwag muling isulat ang iyong kasaysayan at subukang mag-push muli, at huwag mag-push sa isang kahilera na Git na repositoryo upang makipagtulungan kasama ang kapwa mga developer ng Git sa parehong pagkakataon. Ang Subversion ay maaaring magkaroon lamang ng isang linear na kasaysayan, at madali itong ikalito. Kung ikaw ay nagtatrabaho sa isang koponan, at ang ilan ay gumagamit ng SVN at ang iba ay gumagamit ng Git, siguraduhing ang lahat ay gumagamit ng SVN na server upang makipagtulungan – ang paggawa nito ay gagawing mas madali ang iyong buhay.

Upang ipakita ang functionality na ito, kailangan mo ng isang tipikal na SVN na repositoryo na kung saan mayroon kang access sa pagsulat. Kung gusto mong kopyahin ang mga halimbawang ito, kailangan mong gumawa ng isang nasusulatang kopya ng isang SVN na test na repositoryo. Upang madaling gawin ito, maaari mong gamitin ang isang kasangkapan na tinatawag na svnsync na dumarating kasama ang Subversion.

Upang sumunod, una mong kailangang gumawa ng isang bagong lokal na Subversion na repositoryo.

Pagkatapos, paganahin lahat ang mga user upang baguhin ang mga revprop – ang madaling paraan ay ang pagdagdag ng isang pre-revprop-change na iskrip na palaging naglalabas ng 0:

Maaari mo na ngayong i-sync ang proyektong ito sa iyong lokal na makina sa pamamagitan ng pagtawag ng svnsync init gamit ang patungo at mula na mga repositoryo.

Itinatakda nito ang mga katangian upang patakbuhin ang sync. Maaari mo na ring i-clone ang code sa pamamagitan ng pagpapatakbo ng

Bagaman ang operasyong ito ay tumatagal lamang ng ilang mga minuto, kung susubukan mong kopyahin ang orihinal na mga repositoryo sa ibang remote na repositoryo sa halip ng isang lokal, ang proseso ay tatagal ng halos isang oras, kahit bagaman mayroong mas mababa kaysa sa 100 na mga commit. Ang Subversion ay kailangang mag-clone ng isang rebisyon sa isang pagkakataon at pagkatapos ay i-push ito pabalik sa ibang repositoryo – ito ay nakakatawang hindi mabisa, ngunit ito lamang ang madaling paraan upang gawin ito.

Ngayon na mayroon ka nang isang Subversion na repositoryo kung saan ikaw ay may access sa pagsulat, maaari ka nang tumahak sa isang tipikal na workflow. Magsisimula ka sa git svn clone na utos, na nag-i-import ng isang buong Subversion na repositoryo sa isang lokal na Git na repositoryo. Tandaan na kung ikaw ay nag-i-import mula sa isang tunay na naka-host na Subversion na repositoryo, dapat mong palitan ang file:///tmp/test-svn dito gamit ang URL ng iyong Subversion na repositoryo:

Ito ay nagpapatakbo ng katumbas na dalawang mga utos – ang git svn init na sinusundan ng git svn fetch – sa URL na iyong ibinigay. Ito ay maaaring magtagal ng ilang saglit. Kung, halimbawa, ang pagsubok na proyekto ay mayroon lamang halos 75 na mga commit at ang codebaase ay hindi ganon kalaki, ang Git gayunpaman ay dapat mag-check out sa bawat bersyon, iisa sa bawat pagkakataon, at mag-commit nito nang indibidwal. Para sa isang proyekto na may daan-daan o libo-libong mga commit, ito ay maaaring literal na tatagal ng ilang mga oras o kahit mga araw upang matapos.

Ang -T trunk -b branches -t tags na parte ay sasabihan ang Git na itong Subversion na repositoryo ay sumusunod sa batayan ng pag-branch at pag-tag na mga kombensyon. Kung kakaiba mong papangalanan ang iyong trunk, mga branch, o mga tag, maaari mong baguhin ang mga opsyon na ito. Dahil ito ay sobrang karaniwan, maaari mong palitan ang buong parte gamit ang -s, na nangangahulugang pamantayan na layout at nagpapahiwatig ng lahat ng mga opsyon na iyon. Ang sumusunod na uto ay katumbas:

Sa puntong ito, dapat kang magkaroon ng isang balidong Git na repositoryo na nag-import ng iyong mga branch at mga tag:

Tandaan kung paano namamahala ang kasangkapang ito sa Subversion na mga tag bilang remote na mga ref. Tingnan natin ng malapitan gamit ang Git plumbing na utos na show-ref:

Hindi ito gagawin ng Git kapag ito ay nagko-clone mula sa isang Git na server; narito ang kung ano ang hitsura ng repositoryo na may mga tag pagkatapos ng isang preskong clone:

Ang Git ay direktang magpi-fetch ng mga tag sa refs/tags, sa halip ng pagtrato sa kanila bilang remote na mga branch.

Ngayon na mayroon ka nang isang gumaganang direktoryo, maaari ka nang gumawa ng ilang trabaho at i-push ang iyong mga commit pabalik sa upstream, ang epektibong paggamit ng Git bilang isang SVN na kliyente. Kung ikaw ay nag-edit ng isa sa mga file at nag-commit nito, mayroon kang isang commit na lokal na umiiral sa Git na hindi umiiral sa Subversion na server:

Susunod, kailangan mong i-push ang iyong pagbabago sa upstream. Pansinin kung paano nito binabago ang paraan ng iyong pagtatrabaho sa Subversion – maaari kang gumawa ng iilang mga commit habang naka-offline at pagkatapos ay i-push lahat ang mga ito nang sabay-sabay sa Subversion na server. Upang mag-push sa isang Subversion na server, patakbuhin mo ang git svn dcommit na utos:

Kinukuha nito lahat ng mga commit na ginawa mo sa itaas ng Subversion na server na code, gagawa ng isang Subversion na commit sa bawat isa, at pagkatapos ay susulatang muli ang iyong lokal na Git na commit upang magsama ng isang natatanging identifier. Ito ay importante dahil ito ay nangangahulugan na ang lahat ng SHA-1 na mga checksum para sa iyong mga commit na pagbabago. Bahagyang para sa dahilang ito, ang pagtatrabaho sa Git na nakabase na remote na mga bersyon ng iyong mga proyekto kasabay nito ang isang Subversion na server ay hindi isang magandang ideya. Kung titingnan mo ang huling commit, maaari mong tingnan ang bagong git-svn-id na naidagdag:

Pansinin na ang SHA-1 na checksum na orihinal na nagsimula sa 4af61fd kapag ang iyong na-commit ngayon ay nagsisimula sa 95e0222. Kung gusto mong mag-push sa kapwa isang Git na server at isang Subversion na server, kailangan mo munang mag-push (dcommit) sa Subversion na server, dahil ang aksyong iyon ay bumubago sa iyong commit na datos.

Kung ikaw ay nagtatrabaho kasama ang ibang mga developer, pagkatapos sa ilang punto isa sa inyo ay mag-push, at ang isa pa ay susubukang mag-push ng isang pagbabago na magkasalungat. Ang pagbabagong iyon ay hindi tatanggapin hanggang magmi-merge ka sa kanilang trabaho. Sa git svn, ito ay magmumukhang ganito:

Upang malutas ang sitwasyong ito, maaari mong patakbuhin ang git svn rebase, na magpu-pull ng anumang mga pagbabago sa server na hindi pa nasa iyo at iri-rebase ang anumang trabaho na nasa iyo sa itaas ng anumang nasa server:

Ngayon, lahat ng iyong trabaho ay nasa itaas ng kung ano ang nasa Subversion na server, kaya maaari kang matagumpay na mag-dcommit:

Tandaan na hindi tulad ng Git, na nangangailangan sa iyo na mag-merge sa upstream na trabaho na hindi pa nasa iyo sa lokal bago ka maka-push, ang git svn ay ipapagawa lamang ito sa iyo kung ang mga pagbabago ay magkasalungat (masyadong katulad ng kung paano gumagana ang Subversion). Kung may ibang tao na nagpu-push ng pagbabago sa isang file at pagkatapos ay nag-push ka ng isang pagbabago sa ibang file, ang iyong dcommit ay gagana ng maayos.

Ito ay importanteng tandaan, dahil ang kinalalabasan ay isang estado ng proyekto na hindi umiiral sa alinman sa iyong mga kompyuter kapag ikaw ay nag-push. Kung ang mga pagbabago ay hindi tugma ngunit walang magkasalungat, maaari mong makuha ang mga isyu na mahirap na suriin. Ito ay magkaiba kaysa sa paggamit ng isang Git na server – sa Git, maaari mong ganap na subukan ang estado sa iyong kliyente na sistema bago i-ambag ito, samantalang sa SVN, hindi mo kailanmang madaling matiyak na ang mga estado bago sa commit at pagkatapos sa commit ay magkakahawig.

Kailangan mo ring patakbuhin ang utos na ito upang i-pull papasok ang mga pagbabago mula sa Subversion na server, kahit na kung ikaw ay hindi pa handang sariling mag-commit. Maaari mong patakbuhin ang git svn fetch upang kunin ang bagong datos, ngunit ang git svn rebase ay gagawa sa fetch at pagkatapos ay ia-update ang iyong lokal na mga commit.

Ang pagpapatakbo ng git svn rebase sa bawat pagkakataon ay sinisiguradong ang iyong code ay palaging napapanahon. Kailangan mong siguraduhin na ang iyong tinatrabahong direktoryo ay malinis kapag ikaw ay nagpatakbo nito, bagaman. Kung mayroon kang lokal na mga pagbabago, kailangan mong alinmang i-stash ang iyong trabaho o pansamantalang i-commit ito bago patakbuhin git svn rebase – kung hindi man, ang utos ay hihinto kung nakikita nito na ang rebase ay magreresulta ng isang merge na salungatan.

Kapag ikaw ay naging komportable na sa isang Git workflow, malamang ikaw ay makakalikha ng paksa na mga branch, gumawa ng trabaho sa mga ito, at pagkatapos ay papasok na i-merge ang mga ito. Kung ikaw ay nag-push sa isang Subversion na server sa pamamagitan ng git svn, malamang gusto mong i-rebase ang iyong trabaho sa isang solong branch sa bawat oras sa halip na sama-samang i-merge ang mga branch. Ang dahilan upang gustuhin ang pag-rebase ay ang Subversion ay may isang linear na kasaysayan at hindi nakikitungo katulad ng Git, kaya ang git svn ay sumusunod lamang sa unang magulang kapag pinapalitan ang mga snapshot sa Subversion na mga commit.

Ipagpalagay na ang iyong kasaysayan ay magmumukhang katulad ng sumusunod: lumikha ka ng isang experiment na branch, gumawa ng dalawang mga commit, at pagkatapos ay na-merge ang mga ito pabalik sa master. Kapag ikaw ay nag-dcommit, makikita mo ang awtput na katulad nito:

Ang pagpapatakbo ng dcommit sa isang branch na may na-merge na kasaysayan ay gagana ng maayos, maliban kapag ikaw ay tumingin sa iyong kasaysayan ng Git na proyekto, hindi nito sinulatang muli ang alinman sa mga commit na ginawa mo sa experiment na branch – sa halip, ang lahat ng mga pagbabagong iyon ay magpapakita sa SVN na bersyon ng solong merge na commit.

Kapag may ibang tao na magko-clone ng trabahong iyon, lahat ng makikita nila ay ang merge na commit kasama ang lahat na trabahong naisiksik sa iyon, kagaya ng pagpatakbo mo ng git merge --squash; hindi nila makikita ang commit na datos tungkol sa kung saan ito nanggaling o kailan ito na-commit.

Ang pag-branch sa Subversion ay hindi pareho sa pag-branch sa Git; kung maaari mong maiwasan ang paggamit nito nang masyado, iyon na marahil ang pinakamahusay. Gayunpaman, maaari kang bumuo at mag-commit sa mga branch sa Subversion gamit ang git svn.

Upang lumikha ng isang panibagong branch sa Subversion, patakbuhin mo ang git svn branch [new-branch]:

Ginagawa nito ang katumbas ng svn copy trunk branches/opera na utos sa Subversion at tumatakbo sa Subversion na server. Importanteng tandaan na ito ay hindi nagchi-check out sa iyo sa branch na iyon; kung ikaw ay nag-commit sa puntong ito, ang commit na iyon ay pupunta sa trunk sa server, hindi sa opera.

Inaalam ng Git kung anong branch pupunta ang iyong mga dcommit sa pamamagitan ng paghahanap ng dulo ng anuman sa iyong Subversion na mga branch sa iyong kasaysayan – dapat kang magkaroon ng isa lamang, at ito dapat ang huli na may isang git-svn-id sa iyong kasalukuyang kasaysayan ng branch.

Kung gusto mong magtrabaho sa higit pa sa isang branch nang sabay-sabay, maaari kang magtakda ng lokal na mga branch sa dcommit sa isang tiyak na Subversion na mga branch sa pamamagitan ng pagsisimula sa kanila sa na-import na Subversion na commit para sa branch na iyon. Kung gusto mo ng isang opera na branch na maaari mong trabahuin na magkahiwalay, maaari mong patakbuhin ang

Ngayon, kung gusto mong i-merge ang iyong opera na branch sa trunk (iyong master na branch), maaari mong gawin ito gamit ang isang normal na git merge. Ngunit kailangan mong magbigay ng isang deskriptibong commit na mensahe (gamit ang -m), o ang merge ay magsasabing “Merge branch opera” sa halip ng isang bagay na kapaki-pakinabang.

Tandaan na kahit ikaw ay gumagamit ng git merge upang gumawa ng operasyong ito, at ang merge malamang ay higit na mas madali kaysa sa Subversion (dahil ang Git ay awtomatikong tutuklas ng angkop na merge na base para sa iyo), ito ay hindi isang normal na Git merge na commit. Kailangan mong i-push ang datos pabalik sa isang Subversion na server na hindi nangangasiwa ng isang commit na sumusubaybay ng higit pa sa isang magulang; kaya, pagkatapos mong i-push pataas ito, magmumukha itong isang solong commit na nagsasanib ng lahat ng trabaho ng ibang branch sa ilalim ng isang solong commit. Pagkatapos mong i-merge ang isang branch patungo sa iba, hindi ka madaling makakabalik at magpatuloy sa pagtatrabaho sa branch na iyon, na normal mong nagagawa sa Git. Ang dcommit na utos na iyong pinatakbo ay nagbubura ng anumang impormasyon na nagsasabi kung anong branch ang papasok na na-merge, kaya ang kasunod na mga pag-kalkula ng merge-base ay magiging mali – ang dcommit ay ginagawa iyong git merge na resulta na magmukhang iyong pinatakbo ang git merge --squash. Sa kasamaang palad, walang magandang paraan upang maiwasan ang sitwasyong ito – ang Subversion ay hindi kayang mag-imbak ng impormasyong ito, kaya palagi kang nalulumpo sa mga limitasyon nito habang ikaw ay gumagamit nito bilang iyong server. Upang maiwasan ang mga isyu, kailangan mong burahin ang lokal na branch (sa kasong ito, opera) pagkatapos mong i-merge ito sa iyong trunk.

Ang git svn na hanay ng kasangkapan ay nagbibigay ng iilang mga utos upang tulungang padaliin ang transisyon sa Git sa pamamagitan ng pagbibigay ng ilang functionality na katulad sa kung ano ang mayroon ka sa Subversion. Narito ang kaunting mga utos na nagbibigay sa iyo kung ano ang Subversion dati.

Ang git svn na mga kasangkapan ay kapaki-pakinabang kung ikaw ay nananatili sa isang Subversion na server, o kaya ay nasa isang development na environment na nangangailangan ng pagpapatakbo ng isang Subversion na server. Dapat mong isaalang-alang na ito ay sumalanta sa Git, gayunpaman, o makakasalubong ka ng mga isyu sa pagsasalin na maaaring lumito sa iyo at iyong mga katulong. Upang makaiwas sa gulo, subukang sundin ang mga patnubay na ito:

Kung susundin mo ang mga patnubay na iyon, ang pagtatrabaho gamit ang isang Subversion server ay maaaring maging mas mapagtitiisan. Gayunpaman, kung ito ay posibleng ilipat sa isang tunay na Git server, ang paggawa nito ay maaaring higit pang maging pakinabang sa iyong koponan.

Una, kailangan mong mag-install ng git-remote-hg. Ito ay talagang nagtatadhana sa pagpapahulog sa file nito saanman sa iyong landas, katulad nito:

…ipagpalagay na ang ~/bin ay nasa iyong $PATH. Ang git-remote-hg ay may iba pang dependensya: ang mercurial na library para sa Python. Kung ikaw ay mayroon nang Python na naka-install, ito ay kasing simple ng:

(Kung wala ka pang Python na naka-install, bisitahin ang https://www.python.org/ at unang kunin ito.)

Ang huling bagay na kakailanganin mo ay ang Mercurial na kliyente. Pumunta sa https://www.mercurial-scm.org/ at i-install ito kung hindi mo pa nagawa.

Ngayon handa ka nang gumiwang. Lahat ng kailangan mo ay isang Mercurial na repositoryo kung saan ka magpu-push. Sa kabutihang palad, ang bawat Mercurial na repositoryo ay maaaring kumilos sa ganitong paraan, kaya gagamitin lang nating ang "hello world" na repositoryo na ginagamit ng lahat upang matuto ng Mercurial:

Ngayon na mayroon na tayong isang angkop na “server-side” na repositoryo, maaari tayong tumahak sa isang tipikal na workflow. Batay sa iyong makikita, ang dalawang mga sistemang ito ay sapat na magkatulad nang walang masyadong alitan.

As always with Git, first we clone:

Mapapansin mo na ang pagtatrabaho gamit ang isang Mercurial na repositoryo ay gumagamit ng standard na git clone na utos. Ito ay dahil ang git-remote-hg ay nagtatrabaho sa isang patas na mababang antas, na gumagamit ng isang katulad na mekanismo sa kung paano ang HTTP/S protocol ng Git ay napatupad (remote na mga katulong). Dahil ang Git at Mercurial ay parehong nakadisenyo para sa bawat kliyente upang magkaroong mga isang buong kopya ng kasaysayan ng repositoryo, ang utos na ito ay gumagawa ng isang buong clone, kasama ang lahat ng kasaysayan ng proyekto, at ito ay patas na madali.

Ang log na utos ay nagpapakita ng dalawang mga commit, ang pinakabago sa mga ito ay itinuro ng buong slew ng mga ref. Kinalalabasan na ang ilan sa mga ito ay hindi aktwal na nandoon. Tingnan natin ang kung ano ang aktwal na nandoon sa .git na direktoryo:

Ang git-remote-hg ay sinusubukang gawin ang mga bagay na mas salawikaing katulad ng Git, ngunit sa ilalim nito ito ay namamahala sa konseptwal na pag-map sa pagitan ng dalawa na bahagyang magkaibang mga sistema. Ang refs/hg na direktoryo ay kung saan ang aktwal na remote na mga ref ay nakaimbak. Halimbawa, ang refs/hg/origin/branches/default ay isang Git ref na file na naglalaman ng SHA-1 na nagsisimula sa “ac7955c”, na ang commit na tinuturo ng master. Kaya ang refs/hg na direktoryo ay medyo katulad ng isang pekeng refs/remotes/origin, ngunit ito ay may nakadagdag na pagkakaiba sa pagitan ng mga bookmark at mga branch.

Ang notes/hg na file ay ang panimulang punto para sa kung paano magmapa ang git-remote-hg ng Git commit na mga hash sa mga ID ng Mercurial na changeset. Magsiyasat tayo ng kaunti:

Kaya ang refs/notes/hg ay tumuturo sa isang tree, na ang Git object na database ay isang listahan ng ibang mga object na may mga pangalan. Ang git ls-tree ay naglalabas ng mode, type, object hash, at filename para sa mga item sa loob ng isang tree. Kapag tayo ay maghuhukay sa isa sa mga item ng tree, makikita natin na ang nasa loob nito ay isang blob na nakapangalang “ac9117f” (ang SHA-1 na hash ng commit na itinuro ng master), na may mga nilalaman na “0a04b98” (na ID ng Mercurial na changeset sa dulo ng default na branch).

Ang magandang balita ay kadalasan hindi na natin kailangang mag-alala tungkol sa lahat ng mga ito. Ang tipikal na daloy ng trabaho ay hindi masyadong magkaiba mula sa pagtatrabaho sa isang Git na remote.

May isa pang bagay na dapat nating harapin bago tayo magpatuloy: mga ignore. Ang Mercurial at Git ay gumagamit ng isang sobrang katulad na mekanismo para dito, ngunit malamang na hindi mo gustong aktwal na mag-commit ng isang .gitignore na file sa isang Mercurial na repositoryo. Sa kabutihang palad, ang Git ay may isang paraan upang hindi pumansin ng mga file na lokal sa isang on-disk na repositoryo, at ang Mercurial na format ay katugma sa Git, kaya kailangan mo lang itong kopyahin:

Ang .git/info/exclude na file ay kumikilos katulad ng isang .gitignore, ngunit hindi kasama ang mga commit.

Ipagpalagay natin na nakagawa tayo ng ilang trabaho at gumawa ng ilang mga commit sa master na branch, at ikaw ay handa nang i-push ito sa remote na repositoryo. Narito ang kung ano ang hitsura ng nasa ating repository ngayon:

Ang ating master na branch ay nauuna ng dalawang mga commit kaysa sa origin/master, ngunit ang mga commit na iyon ay umiiral lamang sa ating lokal na makina. Tingnan natin kung may iba pa na gumagawa ng importanteng trabaho sa parehong panahon:

Dahil nagamit natin ang --all na flag, nakikita natin ang “notes” na mga ref na panloob na ginamit ng git-remote-hg, ngunit maaari nating hindi pansinin ang mga ito. Ang iba ay katulad ng ating inaakala; ang origin/master ay lumamang ng isang commit, at ang ating kasaysayan ay humiwalay na ngayon. Hindi katulad ng ibang mga sistema na ating natrabaho sa kabanatang ito, ang Mercurial ay may kakayahang mag-asikaso ng mga merge, kaya hindi na tayo gagawa ng anumang magarbo.

Perpekto. Pinatakbo natin ang mga pagsubok at ang lahat ay pumasa, kaya handa na tayong mamahagi ng ating trabaho sa natitirang bahagi ng koponan:

Ayan yun! Kung titingnan mo ang Mercurial na repositoryo, makikita mo na ito ay gumawa ng ating inaasahan:

Ang changeset na nakanumerong 2 ay ginawa ng Mercurial, at ang mga changeset na nakanumerong 3 at 4 ay ginawa ng git-remote-hg, sa pamamagitan ng pag-push ng mga commit na ginawa gamit ang Git.

Ang Git ay mayroon lamang isang uri ng branch: isang reperensya na gumagalaw kapag nagawa ang mga commit. Sa Mercurial, ang uri ng reperensyang ito ay tinatawag na isang “bookmark,” at ito ay kumikilos sa masyadong parehong paraan sa isang Git na branch.

Ang konsepto ng Mercurial sa isang “branch” ay mas mabigat. Ang branch na gumawa ng isang changeset ay naitala kasama ang changeset, na nangangahulugang ito ay palaging nasa kasaysayan ng repositoryo. Narito ang isang halimbawa ng isang commit na nagawa sa develop na branch:

Tandaan ang linya na nagsisimula sa “branch”. Ang Git ay hindi talaga maaaring magkopya nito (ay hindi na kailangan; ang parehong mga uri ng branch ay irepresenta bilang isang Git ref), ngunit ang git-remote-hg ay kailangang maunawaan ang pagkakaiba, dahil ang Mercurial ay nagmamalasakit.

Ang paggawa ng Mercurial na mga bookmark ay kasing dali ng paglikha ng Git na mga branch. Sa panig ng Git:

Iyon lang lahat ang nandoon. Sa panig ng Mercurial, ito ay magmumukhang katulad nito:

Tandaan na ang bagong [featureA] na tag sa revision 5. Ang mga ito ay kumikilos na eksaktong katulad ng Git na mga branch sa panig ng Git, na may isang pagbubukod: hindi mo maaaring burahin ang isang bookmark mula sa panig ng Git (ito ay isang limitasyon ng remote na mga katulong).

Maaari ka ring magtrabaho ng isang “heavyweight” na Mercurial na branch: maglagay lamang ng isang branch sa branches na namespace:

Narito ang kung ano ang hitsura nito sa panig ng Mercurial:

Ang pangalan ng branch na “permanent” ay naitala gamit ang changeset na nakamarkang 7.

Mula sa panig ng Git, ang pagtatrabaho sa alinmang mga estilo ng branch na ito ay pareho: mag-checkout, commit, fetch, merge, pull, at push katulad ng normal mong ginagawa. Isang bagay na dapat mong malaman ay ang Mercurial ay hindi sumusuporta sa pagsusulat muli sa kasaysayan, pagdagdag lamang nito. Narito ang kung ano ang hitsura ng ating repositoryo ng Mercurial pagkatapos ng isang interactive na rebase at isang force-push:

Ang mga changeset na 8, 9, at 10 ay nilikha at nabibilang sa permanent na branch, ngunit ang lumang mga changeset ay nandoon pa rin. Ito ay maaaring maging sobrang nakakalito para sa iyong mga kasamahan sa koponan na gumagamit ng Mercurial, kaya subukang iwasan ito.

Ang Git at Mercurial ay sapat na magkatulad na ang pagtatrabaho sa kabuuang hangganan ay patas na hindi masakit. Kung iiwasan mo ang pagbabago ng kasaysayan na naiwan sa iyong makina (bilang pangkalahatang inirekomenda), marahil maaaring hindi mo pa alam na ang kabilang dulo ay Mercurial.

Ito ay simpleng gamitin. Sapat lamang na mag-clone ng isang Bazaar na repositoryo at ipi-prefix ito gamit ang bzr::. Dahil ang Git at Bazaar ay parehong gumagawa ng buong mga clone sa iyong makina, posibleng mag-attach ng isang Git clone sa iyong lokal na Bazaar clone, ngunit hindi ito rekomendado. Mas madaling direktang i-attach ang iyong Git na clone sa isang kaparehong lugar kung saan naka-attach ang iyong Bazaar na clone ‒ ang sentral na repositoryo.

Ipagpalagay natin na ikaw ay nakapagtrabaho sa isang remote na repositoryo kung saan nasa address na bzr+ssh://developer@mybazaarserver:myproject.

Sa puntong ito, ang iyong Git na repositoryo ay nabuo ngunit hindi nakasiksik para sa paggamit ng optimal disk. Kaya nga kailangan mo ring linisin at isiksik ang iyong Git na repositoryo, lalo na kung ito ay malaki:

Ang Bazaar ay nagpapahintulot lamang sa iyo na mag-clone ng mga branch, ngunit ang isang repositoryo ay maaaring maglaman ng iilang mga branch, at ang git-remote-bzr ay maaaring mag-clone ng pareho. Halimbawa, upang mag-clone ng isang branch:

At upang mag-clone ng buong repositoryo:

Ang pangalawang utos ay iko-clone ang lahat ng mga branch na nilalaman sa emacs na repositoryo; gayunpaman posibleng tumuro sa ilang mga branch:

Ilang remote na mga repositoryo ay hindi nagpapahintulot sa iyo na maglista ng kanilang mga branch, sa kasong manu-mano mong tukuyin ang mga iyon, at kahit na maaari mong tukuyin ang kompigurasyon sa pag-clone na utos, maaaring mas madali ito para sa iyo:

Dahil ikaw ay nagtatrabaho sa isang proyekto na pinamamahalaan ng Bazaar, hindi ka dapat gumawa ng isang .gitignore na file dahil maaari mong aksidenteng matakda ito sa ilalim ng version control at ang ibang mga tao na nagtatrabaho gamit ang Bazaar ay magagambala. Ang solusyon ay ang paglikha ng .git/info/exclude na file alinman bilang isang simbolikong link o bilang isang regular na file. Tingnan natin mamaya kung paano lutasin ang tanong na ito.

Ang Bazaar ay gumagamit ng parehong modela sa Git upang hindi magpansin ng mga file, ngunit mayroon ding dalawang mga tampok na walang isang katumbas sa Git. Ang kumpletong deskripsyon ay maaaring matagpuan sa the documentation. Ang dalawang mga tampok ay:

Bilang isang kalalabasan, mayroong dalawang magkaibang mga sitwasyon na isaalang-alang:

Kahit ano pa ang kaso, kailangan mong manatiling mapagbantay laban sa anumang pagbabago ng .bzrignore upang siguraduhin na ang .git/info/exclude na file ay palaging sumasalamin sa .bzrignore. Sa katunayan, kung ang .bzrignore na file ay magbabago at naglalaman ng isa o higit pang mga linya na nagsisimula ng "!!" o "RE:", ang Git na hindi kayang interpretahin ang mga linyang ito, kailangan mong iangkop ang iyong .git/info/exclude na file upang hindi pansinin ang parehong mga file bilang mga hindi pinansin gamit ang .bzrignore. Bukod dito, kung ang .git/info/exclude na file ay isang simbolikong link, kailangan mo munang burahin ang simbolikong link, kopyahin ang .bzrignore sa .git/info/exclude at pagkatapos ay iangkop ang huli. Gayunpaman, mag-ingat sa paglikha nito dahil gamit ang Git ito ay imposibleng muling isama ang isang file kung ang isang magulang na direktoryo sa file na iyon ay hindi kasama.

Upang mag-fetch ng mga pagbabago ng remote, magpu-pull ka ng mga pagbabago tulad ng dati, gamit ang Git na mga utos. Kung kaya ang iyong mga pagbabago ay nasa master na branch, i-merge o i-rebase ang iyong trabaho sa origin/master na branch:

Dahil ang Bazaar rin ay may konsepto ng merge na mga commit, walang problema kung ikaw ay mag-push ng isang merge na commit. Kaya maaari kang magtrabaho sa isang branch, i-merge ang mga pagbabago sa master at i-push ang iyong trabaho. Pagkatapos, gumawa ka ng iyong mga branch, subukan at i-commit mo ang iyong trabaho gaya ng dati. Sa huli ay i-push mo ang iyong trabaho sa Bazaar na reporsitoryo:

Ang balangkas ng mga remote-helper ng Git ay may ilang mga limitasyon na nalalapat. Sa partikular, ang mga utos na ito ay hindi gagana:

Dahil katulad ang mga modelo ng Git at Bazaar, may hindi medyo maraming paglalaban kapag nagtatrabaho sa kabuuan ng hangganan. Hangga’t ikaw ay nagmamasid para sa mga limitasyon, at palaging may kamalayan na ang remote na repositoryo ay hindi katutubong Git, ikaw ay magiging maayos lamang.

Ang Perforce ay nagbibigay ng isang produkto na tinatawag na Pagsasanib ng Git (makukuha sa http://www.perforce.com/git-fusion), na pinagsasabay ang isang Perforce na server sa Git na mga repositoryo sa panig ng server.

Ang Git-p4 ay isang dalawang-daanan na tulay sa pagitan ng Git at Perforce. Ito ay buong tumatakbo sa loob ng iyong Git na repositoryo, kaya hindi ka na mangangailangang mag-access pa sa Perforce na server (iba kaysa sa user na mga kredensyal, syempre). Ang Git-p4 ay hindi mas umaangkop o kukumpleto sa isang solusyon kagaya ng Git Fusion, ngunit hindi nito pinapayagang gumawa ka pa ng karamihan sa kung ano ang gusto mong gawin nang hindi nagsasalakay sa server na environment.

Ang Git-p4 ay ginagawang posible ang paggamit ng Git na workflow gamit ang isang Perforce na server, at ito ay medyo magaling nito. Gayunpaman, importanteng tandaan na ang Perforce ay namumuno sa pinagkukunan, at ginagamit mo lang ang Git upang lokal na magtrabaho. Maging talagang maingat lamang tungkol sa pagbabahagi ng Git na mga commit; kung ikaw ay mayroong isang remote na ginagamit ng ibang tao, huwag mag-push ng anumang mga commit na hindi pa nasumite sa Perforce na server.

Kung gusto mong libreng ihalo ang paggamit ng Perforce at Git bilang mga kliyente para sa source control, at maaari mong kumbinsihin ang administrador ng server sa pag-install nito, ang Git Fusion ay ginagawa ang paggamit ng Git na isang primera klaseng version-control na kliyente para sa isang Perforce na server.

Sa katunayan, mayroong dalawa: ang git-tf at git-tfs.

Ang Git-tfs (matatagpuan sa https://github.com/git-tfs/git-tfs) ay isang .NET na proyekto, at (batay sa pagkakasulat nito) ito ay tumatakbo lamang sa Windows. Upang magtrabaho gamit ang mga repositoryo ng Git, ito ay gumagamit ng .NET na mga ugnayan para sa libgit2, isang library-oriented na pagpapatupad ng Git na napakainam sa pagganap at nagpapahintulot ng maraming umaangkop sa bituka ng isang Git na repositoryo. Ang Libgit2 ay hindi isang kompletong pagpapatupad ng Git, kaya upang sakupin ang mga kaibahan ang git-tfs ay talagang tumatawag ng command-line ng Git na kliyente para sa ilang mga operasyon, kaya walang artipisyal na mga hangganan sa kung ano ang maaari nitong gawin sa Git na mga repositoryo. Ang suporta nito sa TFVC na mga tampok ay sobrang gulang, dahil ito ay gumagamit ng Visual Studio na mga pagpupulong para sa mga operasyon sa mga server. Ito ay nangangahulugan na kinakailangan mo ng access sa mga pagpupulong na iyon, na nangangahulugang dapat kang mag-install ng isang kamakailang bersyon ng Visual Studio (anumang edisyon mula sa 2010 na bersyon, na nagsasama ng Express mula sa 2012 na bersyon), o ang Visual Studio na SDK.

Ang Git-tf (na ang tahanan ay nasa https://gittf.codeplex.com) ay isang Java na proyekto, at dahil dito ay tumatakbo sa anumang kompyuter kasama ang isang Java runtime na enviroment. Nag-i-interface ito gamit ang Git na mga repostoryo sa pamamagitan ng JGit (isang JVM na pagpapatupad ng Git), na nangangahulugan na ito ay may birtwal na walang mga limitasyon sa termino ng mga function ng Git. Samantala, ang suporta nito para sa TFVC ay limitado kaysa sa kung ano ang mayroon ng git-tfs – hindi ito sumusuporta ng mga branch, halimbawa.

Kaya bawat kasangkapan ay mayroong mga kalamangan at kahinaan, at mayroong maraming mga sitwasyon na pabor sa isa kaysa sa isa pa. Sasakupin natin ang mga paunang paggamit nitong dalawa sa librong ito.

Ang unang bagay na gagawin mo, katulad ng anumang Git na proyekto, ay mag-clone. Narito ang kung ano ang hitsura katulad ng nasa git-tf:

Ang unang argumento ay ang URL ng isang TFVC na koleksyon, ang pangalawa ay ang URL nakapormang $/project/branch, at ang pangatlo ay ang landas patungo sa lokal na repositoryo ng Git na lilikhain (ang panghuli ay opsyonal). Ang Git-tf ay maaari lamang magtrabaho sa isang branch sa isang pagkakataon; kung gusto mong gumawa ng isang bagong clone mula sa branch na iyon.

Ito ay gumagawa ng isang buong functional na repositoryo ng Git:

Ito ay tinatawag na isang mababaw na clone, na nangangahulugan na ang napapanahong hanay ng pagbabago lamang ang na-download. Ang TFVC ay hindi nakadesinyo para sa bawat kliyente upang magkaroon ng isang buong kopya ng kasaysayan, kaya ang git-tf na mga default ay kumukuha lamang ng napapanahong bersyon, na higit pang mas mabilis.

Kung mayroon kang ilang oras, marahil ito ay sulit upang i-clone ang buong kasaysayan ng proyekto, gamit ang --deep na opsyon:

Pansinin ang mga tag na may mga pangalan katulad ng TFS_C35189; ito ay isang tampok na tumutulong sa iyo upang malaman kung anong Git na mga commit ang nauugnay sa TFVC na mga hanay ng pagbabago. Ito ay isang magandang paraan upang irepresenta ito, dahil maaari mong tingnan gamit ang isang simpleng log na utos kung ano ang iyong mga commit na nauugnay sa isang snapshot na umiiral din sa TFVC. Sila ay hindi na kinakailangan (at sa katunayan maaari mong i-off ang mga ito gamit ang git config git-tf.tag false) – ang git-tf ay pinapanatili ang tunay na commit-changeset na mga pagmapa sa .git/git-tf na file.

Ang Git-tfs na pag-clone ay kumikilos ng medyo may kaibahan. Suriin:

Pansinin ang --with-branches na flag. Ang Git-tfs ay may kakayahang sa pagmapa ng TFVC na mga branch patungo sa Git na mga branch, at ang flag na ito ay sinasabihan ito na mag-set up ng isang lokal na Git na branch para sa bawat TFVC na branch. Ito ay labis na inirerekomenda kung ikaw ay kailanmang nag-branch o nag-merge sa TFS, ngunit ito ay hindi gagana sa isang mas lumang server kaysa sa TFS 2010 – bago ang release na iyon, ang “mga branch” ay mga folder lamang, kaya ang git-tfs ay hindi makakapagsabi sa kanila mula sa regular na mga folder.

Tingnan natin ang resulta na repositoryo ng Git:

May dalawang lokal na mga branch, ang master at featureA, na nagrerepresenta ng paunang panimulang punto ng clone (Trunk sa TFVC) at isang child na branch (featureA sa TFVC). Maaari mo ring makita na ang tfs na “remote” ay mayroon ding pares ng refs: ang default at featureA, na kumakatawan sa TFVC na mga branch. Ang Git-tfs ay magmamapa ng branch na kung saan ka nag-clone patungo sa tfs/default, at ang mga iba pa ay kukuha ng kanilang sariling mga pangalan.

Iba pang bagay na pansinin ay ang git-tfs-id: na mga linya sa commit na mga mensahe. Sa halip na mga tag, ang git-tfs ay gumagamit ng mga marka na ito upang iugnay ang TFVC na mga hanay ng pagbabago sa Git na mga commit. Ito ay may implikasyon na ang iyong Git na mga commit ay magkakaroon ng isang naiibang SHA-1 na hash bago at pagkatapos sila na-push sa TFVC.

Ang halatang susunod na bagay na gugustuhin mong gawin ay ang pagtrabaho sa proyekto. Ang TFVC at TFS ay may iilang mga tampok na maaaring magdagdag ng pagkakumplikado sa iyong daloy ng trabaho:

Sa interes ng kaigsian, ang ating sasakupin dito ay ang masayang landas, na mga sidestep o nag-iiwas ng halos ng mga isyung ito.

Sabihin nating natapos mo ang ilang trabaho, gumawa ng ilang Git na mga commit sa master, at handa ka nang ibahagi ang iyong pag-unlad sa TFVC na server. Narito ang ating Git na repositoryo:

Gusto nating kumuha ng snapshot na nasa 4178a82 na commit at i-push paitaas ito sa TFVC na server. Unang mga bagay na nauuna: tingnan natin kung anuman sa ating mga kasama sa koponan ay gumawa ng anuman mula nung huli tayong kumonekta:

Mukhang may ibang nagtatrabaho, rin, at ngayon mayroon na tayong magkakaibang kasaysayan. Ito ay kung saan kumikinang ang Git, ngunit mayroon tayong dalawang pagpipilian kung paano magpatuloy:

Ang pagpili ay nasa iyo. Para sa halimbawang ito, iri-rebase natin ang: For this example, we’ll be rebasing:

Ngayon handa na tayong gumawa ng isang checkin sa TFVC na server. Ang git-tf ay nagbibigay sa iyo ng pagpipilian sa paggawa ng isang solong hanay ng pagbabago na nagrerepresenta ng lahat ng mga pagbabago mula nung huli (--shallow, na ang default) at gumagawa ng isang panibagong hanay ng pagbabago para sa bawat Git na commit (--deep). Para sa halimbawang ito, gagawa lang tayo ng isang hanay ng pagbabago:

Mayroong isang bagong TFS_C35348 na tag, na nagpapakita na ang TFVC ay nag-iimbak ng eksaktong magkaparehong snapshot sa 5a0e25e na commit. Importanteng tandaan na hindi bawat Git na commit ay nangangailangang magkaroon ng eksaktong kopya sa TFVC; ang 6eb3eb5 na commit, halimbawa, ay hindi umiiral saanman sa server.

Ito ay ang pangunahing daloy ng trabaho. Mayroong iilang ibang konsiderasyon na gugustuhin mong isaisip:

Maglakad tayo sa parehong senaryo sa paggamit ng git-tfs. Narito ang bagong mga commit na ginawa natin sa master na branch sa ating Git na repositoryo:

Ngayon tingnan natin kung may ibang tao na nakagawa ng trabaho habang tayo nagha-hack sa malayo:

Oo, lumalabas na ang ating kasama sa trabaho ay nagdagdag ng isang bagong TFVC na hanay ng pagbabago, na magpapakita bilang bagong aea74a0 na commit, at ang tfs/default na remote na branch ay lumipat.

Tulad ng git-tf, mayroon tayong dalawang pangunahing mga opsyon para sa kung paano lutasin itong magkakaibang kasaysayan:

Sa kasong ito, tayo ay gagawa ng isang “malalim” na checkin, kung saan ang bawat Git na commit ay magiging isang TFVC na hanay ng pagbabago, kaya gusto nating mag-rebase.

Ngayon tayo ay handa nang kumpletuhin ang ating pag-ambag sa pamamagitan ng pagtsi-check in ng ating code sa TFVC na server. Gagamitin natin ang rcheckin na utos dito upang lumikha ng isang TFVC na hanay ng pagbabago para sa bawat Git na commit sa landas mula sa HEAD patungo sa unang tfs na remote na branch na natagpuan (ang checkin na utos ay lilikha lamang ng isang hanay ng pagbabago, tulad ng pagpipi ng Git na mga commit).

Pansinin kung paano pagkatapos ng bawat matagumpay na checkin sa TFVC na server, ang git-tfs ay nagre-rebase ng natitirang trabaho sa kung ano ang ginawa nito. Iyon ay dahil nagdaragdag ito ng git-tfs-id na field sa ilalim ng commit na mga mensahe, na nagbabago sa SHA-1 na mga hash. Ito ay eksaktong batay sa pagkakadisenyo, at walang dapat ipangamba, ngunit dapat mong bigyang alam na ito ay nangayayri, lalo na kung ikaw ay namamahagi ng mga Git na commit sa iba.

Ang TFS ay may maraming mga tampok na sumasama sa sistema na version control nito, katulad ng mga item ng trabaho, itinalagang mga taga-review, naka-gate na mga checkin, at iba pa. Maaaring masalimuot na magtrabaho sa mga tampok na ito gamit lamang ang isang command-line na kasangkapan, ngunit sa kabutihang palad ang git-tfs ay hahayaan kang maglunsad ng isang grapikal na checkin na kasangkapan nang sobrang dali:

Nagmumukha itong medyo ganito:

Ito ay magmumukhang pamilyar sa mga gumagamit ng TFS, dahil ito ay magkapareho ng diyalogo sa nailunsad mula sa loob ng Visual Studio.

Ang Git-tfs din ay hahayaang kang mag-kontrol ng TFVC na mga branch mula sa iyong Git na repositoryo. Bilang isang halimbawa, gumawa tayo ng isa:

Ang paggawa ng isang branch sa TFVC ay nangangahulungan sa pagdaragdag ng isang hanay ng pagbabago kung saan ang branch na iyon ay umiiral na ngayon, at ito ay nakapanukala bilang isang Git na commmit. Tandaan din na ang git-tfs ay gumawa ng tfs/featureBee na remote na branch, ngunit ang HEAD ay nakaturo pa rin sa master. Kung gusto mong magtrabaho sa preskong pagkakagawa na branch, gugustuhin mong magbase ng iyong bagong mga commit sa 1d54865 na commit, marahil sa pamamagitan ng paggawa ng isang paksa na branch mula sa commit na iyon.

Ang Git-tf at Git-tfs ay parehong dakilang mga kasangkapan para sa pag-interface na may isang TFVC na server. Pinapayagan ka nilang lokal na gamitin ang kapangyarihan ng Git, umiwas sa patuloy na pagkakaroon ng papunta at pabalik sa sentral na TFVC na server, at gawing sobrang mas madali ang iyong buhay bilang isang developer, na hindi pinipilit ang iyong buong koponan na lumipat sa Git. Kung ikaw ay nagtatrabaho sa Windows (na pwede kung ang iyong koponan ay gumagamit ng TFS), marahil gugustuhin mong gumamit ng git-tfs, dahil ang hanay tampok nito ay mas kumpleto, ngunit kung ikaw ay nagtatrabaho sa ibang plataporma, gagamitin mo ang git-tf, na mas limitado. Sa kadalasang mga kasangkapan sa kabanatang ito, dapat kang pumili ng isa sa mga sistema ng version-control na ito upang maging makanoniko, at gamitin ang iba pang isa na nasa isang pantulong na anyo – alinman sa Git o TFVC ang dapat maging sentro ng kolaborasyon, hindi ang dalawa.