\u00cbsht\u00eb publikuar l\u00ebshimi i projektit mergiraf 0.4, q\u00eb zhvillon nj\u00eb driver p\u00ebr Git me implementimin e mund\u00ebsis\u00eb s\u00eb bashk\u00ebveprimit t\u00eb trefisht\u00eb. Mergiraf mb\u00ebshtet zgjidhjen e llojeve t\u00eb ndryshme t\u00eb konflikteve gjat\u00eb bashkimit dhe mund t\u00eb p\u00ebrdoret p\u00ebr gjuh\u00eb programimi t\u00eb ndryshme dhe formate skedujsh. \u00cbsht\u00eb e mundur nj\u00eb thirrje e ve\u00e7ant\u00eb mergiraf p\u00ebr t\u00eb trajtuar konfliktet q\u00eb shkaktohen gjat\u00eb pun\u00ebs me Git-in standard, si dhe z\u00ebvend\u00ebsimi n\u00eb Git t\u00eb\u5904\u7406 t\u00eb bashkimeve p\u00ebr t\u00eb zgjeruar mund\u00ebsit\u00eb e komandave si merge, revert, rebase dhe cherry-pick. Kodi shp\u00ebrndahet n\u00ebn licenc\u00ebn GPLv3. N\u00eb versionin e ri \u00ebsht\u00eb shtuar mb\u00ebshtetje p\u00ebr gjuh\u00ebt Python, TOML, Scala dhe Typescript, si dhe \u00ebsht\u00eb optimizuar performanca. <\/p>\n
M\u00eb posht\u00eb \u00ebsht\u00eb nj\u00eb p\u00ebrshkrim i detajuar i problemeve q\u00eb zgjidhen me an\u00eb t\u00eb mergiraf: <\/p>\n
Software \u00ebsht\u00eb nj\u00eb shembull i shk\u00eblqyer i nj\u00eb sistemi jasht\u00ebzakonisht t\u00eb komplikuar. Sistemet e komplikuara kan\u00eb nj\u00eb pron\u00ebsi t\u00eb p\u00ebrbashk\u00ebt \u2014 ato jan\u00eb T\u00cb KOMPLIKUARA \u2014 dhe nuk mund t\u00eb prisni q\u00eb sjellja e nevojshme komplekse t\u00eb ndodh\u00eb vetvetiu, rast\u00ebsisht. N\u00eb vend t\u00eb k\u00ebsaj, k\u00ebto sisteme evoluojn\u00eb me kalimin e koh\u00ebs, hap pas hapi, dhe \u00e7do mutacion kontrollohet me kujdes n\u00eb \u00e7do hap. P\u00ebr t\u00eb arritur k\u00ebt\u00eb nevojiten nj\u00eb struktur\u00eb e mir\u00eb e p\u00ebrkufizuar dhe mjetet p\u00ebrkat\u00ebse. Evolucioni i \u00e7do sistemi t\u00eb komplikuar mund t\u00eb vizualizohet si nj\u00eb pem\u00eb me drejtim, ku rr\u00ebnja p\u00ebrfaq\u00ebson nj\u00eb grup t\u00eb zbraz\u00ebt funksionesh, dhe \u00e7do nyje \u2014 p\u00ebrve\u00e7 rr\u00ebnj\u00ebs \u2014 \u00ebsht\u00eb rezultati i p\u00ebrdorimit t\u00eb nj\u00eb mutacioni mbi prindin e saj. <\/p>\n
N\u00eb kontekstin e produkteve, \u00e7do nyje quhet \"version\", q\u00eb p\u00ebrfaq\u00ebson nj\u00eb set t\u00eb caktuar funksionesh dhe anti-funksionesh. \u00c7do ndryshim i k\u00ebtij seti konsiderohet nj\u00eb mutacion, q\u00eb formon nj\u00eb skaj n\u00eb grafiku ton\u00eb me drejtim dhe pa cikle. K\u00ebto funksione p\u00ebr nga natyra jan\u00eb abstrakte; ato nuk reflektojn\u00eb drejtp\u00ebrdrejt m\u00ebnyrat e funksionimit t\u00eb sistemeve fizike, por m\u00eb tep\u00ebr demonstrojn\u00eb si agjent\u00ebt racional\u00eb perceptojn\u00eb p\u00ebrdorshm\u00ebrin\u00eb e k\u00ebtyre sistemeve. P\u00ebr t\u00eb p\u00ebrkthyer idet\u00eb n\u00eb realizimet ekzistuese n\u00eb bot\u00ebn reale, \u00ebsht\u00eb e nevojshme t\u00eb mb\u00ebrtheni m\u00ebng\u00ebt dhe t\u00eb zhytni n\u00eb detaje *mjaft* t\u00eb ul\u00ebta, n\u00eb gjuh\u00ebn e t\u00eb cilave mund t\u00eb shprehni dhe shpjegoni se si funksionon sakt\u00ebsisht gjith\u00e7ka. N\u00eb zhvillimin e softuerit, k\u00ebto nivele t\u00eb ul\u00ebta zakonisht paraqiten si kod burimor. <\/p>\n
P\u00ebr t\u00eb sjell\u00eb gradualisht kodin burimor n\u00eb nj\u00eb gjendje q\u00eb tregon sjelljen e k\u00ebrkuar dhe p\u00ebr t\u00eb dokumentuar se si arrit\u00ebn aty, programuesit e paraqesin pun\u00ebn e tyre n\u00eb terma snapshot-esh dhe changeset-esh. Snapshot-i p\u00ebrfaq\u00ebson nj\u00eb gjendje t\u00eb caktuar t\u00eb produktit me t\u00eb gjitha detajet e nivelit t\u00eb ul\u00ebt, nd\u00ebrsa changeset-i sh\u00ebnon kalimin mes snapshot-esh. N\u00eb p\u00ebrgjith\u00ebsi, snapshot-et krijohen nga changeset-et e vetme p\u00ebr prind\u00ebrit e tyre, prandaj k\u00ebto snapshot-e zakonisht sh\u00ebnohen me at\u00eb q\u00eb b\u00ebjn\u00eb changeset-et q\u00eb i krijuan, k\u00ebshtu q\u00eb k\u00ebto terma shpesh p\u00ebrdoren nd\u00ebrlidhur. <\/p>\n
Ndonj\u00ebher\u00eb ekzistojn\u00eb snapshot-e, t\u00eb marra si rezultat i kalimeve t\u00eb shumta \u2013 bashkimeve t\u00eb komiteteve. Me to \u00ebsht\u00eb e v\u00ebshtir\u00eb t\u00eb punohet, prandaj zakonisht shmangen. Sistemet moderne t\u00eb kontrollit t\u00eb versioneve me burim t\u00eb hapur, si Git, ofrojn\u00eb mund\u00ebsi shum\u00eb t\u00eb bazuara p\u00ebr menaxhimin e proceseve t\u00eb zhvillimit. Ato lejojn\u00eb zhvilluesit t\u00eb organizojn\u00eb snapshot-et si grafika t\u00eb drejtuara aciklike, t'i annotojn\u00eb ato me komente dhe, n\u00ebse \u00ebsht\u00eb e nevojshme, t\u00eb ndryshojn\u00eb rendin e tyre. <\/p>\n
Kjo funksionalitet lejon zhvilluesit t\u00eb shkruajn\u00eb nj\u00eb histori semantikisht dometh\u00ebn\u00ebse t\u00eb projektit, q\u00eb \u00ebsht\u00eb thelb\u00ebsore p\u00ebr debugs dhe p\u00ebr t\u00eb dh\u00ebn\u00eb p\u00ebrgjigje n\u00eb pyetje si 'Pse u fut ky detaj i nivelit t\u00eb ul\u00ebt (p.sh., variabla)?', 'Sa p\u00ebrqind af\u00ebrsisht \u00ebsht\u00eb kontributi im n\u00eb k\u00ebt\u00eb projekt?', 'Kush u komprometua nga implementimi i backdoor dhe kur?', 'Cila ndryshim i nivelit t\u00eb ul\u00ebt thyente k\u00ebt\u00eb funksion (pavar\u00ebsisht se nuk duhej, ne e kontrolluam gjith\u00e7ka!?)' <\/p>\n
Sistemet e kontrollit t\u00eb versioneve e pasurojn\u00eb k\u00ebt\u00eb koncept me deg\u00ebn \u2014 nj\u00eb nocion t\u00eb nivelit t\u00eb ul\u00ebt q\u00eb thjesht do t\u00eb thot\u00eb nj\u00eb fragment vazhdimisht t\u00eb ul\u00ebt t\u00eb historis\u00eb s\u00eb projektit, dometh\u00ebn\u00ebs semantikisht p\u00ebr zhvilluesin. Deg\u00ebt zakonisht p\u00ebrdoren p\u00ebr implementimin specifik t\u00eb funksioneve, ndonj\u00ebher\u00eb krijohen disa deg\u00eb p\u00ebr kandidat\u00eb t\u00eb ndrysh\u00ebm p\u00ebr implementimin e t\u00eb nj\u00ebjtit funksion. Duke p\u00ebrdorur pun\u00ebflukse me deg\u00ebzim (t\u00eb cilat n\u00eb fakt jan\u00eb main stream dhe standard zhvillimi, p\u00ebrdoren kudo), \u00e7do zhvillues individual mund t\u00eb menaxhoj\u00eb me efikasitet shum\u00eb deg\u00eb konfliktuese t\u00eb projektit, secila prej t\u00eb cilave ndryshon n\u00eb nivelin e gatishm\u00ebris\u00eb ose cil\u00ebsis\u00eb. Kjo lejon zhvilluesit t\u00eb kombinojn\u00eb rezultatet e pun\u00ebs s\u00eb tyre dhe t\u00eb t\u00eb tjer\u00ebve pa u ndjer\u00eb nevoja p\u00ebr t\u00eb rinovuar gjith\u00e7ka manualisht \u00e7do her\u00eb. <\/p>\n
Zakonisht krijohet nj\u00eb deg\u00eb kryesore q\u00eb paraqet produktin \"zyrtar\", nga e cila deg\u00ebzohen deg\u00ebt an\u00ebsore p\u00ebr \u00e7do funksion, t\u00eb cilat regulisht (n\u00eb m\u00ebnyr\u00eb ideale \u2014 pas \u00e7do angazhimi) sinkronizohen me deg\u00ebn kryesore, duke i lejuar zhvilluesve t\u00eb punojn\u00eb me versionin m\u00eb t\u00eb fundit t\u00eb produktit dhe nj\u00ebkoh\u00ebsisht t\u00eb integrojn\u00eb funksionet q\u00eb ata po zhvillojn\u00eb aktualisht, duke identifikuar probleme q\u00eb buron nga veprimet e zhvilluesve t\u00eb tjer\u00eb sa m\u00eb her\u00ebt. <\/p>\n
Kur p\u00ebrpiqeni t\u00eb kombinoni funksionet e snapshoteve t\u00eb ndrysh\u00ebm (e cila \u00ebsht\u00eb thjesht gjetja e paraardh\u00ebsit t\u00eb p\u00ebrbashk\u00ebt dhe aplikimi i ndryshimeve q\u00eb i krijojn\u00eb ato, nj\u00ebra mbi tjetr\u00ebn, kjo operacion quhet rebase, nd\u00ebrsa bashkimi \u00ebsht\u00eb thuajse si rebase, thjesht strukturon grafikun e angazhimeve ndryshe, si rezultat i t\u00eb cilave b\u00ebhet e v\u00ebshtir\u00eb p\u00ebr tu manipuluar, prandaj p\u00ebr bashkim zakonisht evitohen n\u00eb favor t\u00eb rebase-ve), shfaqen probleme. Sistemet moderne t\u00eb kontrollit t\u00eb versioneve (VCS) p\u00ebrdorin algoritme t\u00eb brendshme p\u00ebr bashkimin e ndryshimeve, t\u00eb cilat thjesht ndajn\u00eb skedar\u00ebt n\u00eb rreshta t\u00eb ve\u00e7ant\u00eb, konsiderojn\u00eb \u00e7do rresht si nj\u00eb simbol, dhe skedar\u00ebt si sekuenca t\u00eb tyre, dhe pastaj aplikojn\u00eb algoritme p\u00ebr bashkimin e tyre, q\u00eb rrjedhin nga bioinformatika. <\/p>\n
Fatkeq\u00ebsisht, kjo paraqitje rresht pas rreshti e kodit burimor nuk ka asnj\u00eb lidhje me p\u00ebrmbajtjen e tij. Avantazhi i vet\u00ebm \u00ebsht\u00eb se \u00ebsht\u00eb i thjesht\u00eb dhe universale. Mosp\u00ebrputhja \u00e7on n\u00eb konflikte, duke u b\u00ebr\u00eb nj\u00eb burim i vazhduesh\u00ebm shpirti t\u00eb keq p\u00ebr zhvilluesit. Zgjidhja e konflikteve k\u00ebrkon q\u00eb zhvilluesi t\u00eb studioj\u00eb me kujdes t\u00eb dy versionet e kodit, jo vet\u00ebm pjes\u00ebt q\u00eb jan\u00eb sh\u00ebnuar nga algoritmi i krahasimit si \"t\u00eb ndryshuara\" ose \"konfliktuese\", por, ndoshta, edhe t\u00eb gjith\u00eb projektin. <\/p>\n
Zhvilluesi duhet t\u00eb kuptoj\u00eb ndryshimet, t\u00eb shkruaj\u00eb manualisht kodin e bashkuar dhe t\u00eb eliminoj\u00eb \u00e7do mosp\u00ebrputhje. Problemet shtohen shum\u00eb kur instrumenti i rreshtit identifikon gabimisht ndryshimet, gj\u00eb q\u00eb ndodh shpesh n\u00eb rrethana t\u00eb m\u00ebdha, p\u00ebrfshir\u00eb ato triviale, si\u00e7 \u00ebsht\u00eb riformatimi i kodit. N\u00ebse ndryshimet e ardhshme nuk mund t\u00eb aplikohen n\u00eb kodin e bashkuar manualisht, situata shnd\u00ebrrohet n\u00eb nj\u00eb makth t\u00eb plot\u00eb. Pavar\u00ebsisht rasteve t\u00eb tmerrshme, n\u00eb shumic\u00ebn e rasteve algoritmi i rreshtit funksionon, ve\u00e7an\u00ebrisht n\u00ebse zhvilluesit p\u00ebrpiqen aktivisht t\u00eb mos i krijojn\u00eb probleme. Nj\u00eb nga m\u00ebnyrat p\u00ebr t\u00eb minimizuar k\u00ebto probleme \u00ebsht\u00eb k\u00ebrkesa p\u00ebr trajtimin e burimeve nga mjete kanonizimi si black. <\/p>\n
Sigurisht, zgjidhja e sakt\u00eb e rasteve t\u00eb tmerrshme (dhe jo vet\u00ebm p\u00ebr to, algoritmi i rreshtit \u00ebsht\u00eb nj\u00eb heuristik\u00eb, ai mund t\u00eb \u00e7oj\u00eb n\u00eb kod jo funksional, p\u00ebr shembull, nj\u00eb zhvillues e ndryshoi emrin e nj\u00eb variabli, nd\u00ebrsa tjetri shkroi nj\u00eb pjes\u00eb t\u00eb re kodi q\u00eb p\u00ebrdor at\u00eb variab\u00ebl, nuk do t\u00eb ket\u00eb konflikt t\u00eb bashkimit\/ribazimit, por rezultati do t\u00eb b\u00ebhet jo funksional) \u00ebsht\u00eb p\u00ebrdorimi i nj\u00eb modeli t\u00eb brendsh\u00ebm t\u00eb sakt\u00eb. <\/p>\n
Pavar\u00ebsisht se k\u00ebrkimet n\u00eb k\u00ebt\u00eb fush\u00eb jan\u00eb zhvilluar p\u00ebr rreth 30 vjet, dhe kan\u00eb rezultuar n\u00eb krijimin e disa produkteve komerciale pron\u00ebsore, k\u00ebto k\u00ebrkime deri n\u00eb koh\u00ebt e fundit nuk jan\u00eb shnd\u00ebrruar n\u00eb produkte praktikisht t\u00eb aplikueshme me burim t\u00eb hapur. Masa kryesore e zgjidhjeve t\u00eb softuerit t\u00eb lir\u00eb filloi t\u00eb zhvillohej n\u00eb fillim t\u00eb viteve 2010 dhe ishte e fokusuar kryesisht n\u00eb gjuh\u00ebn Java. <\/p>\n
Implementimi m\u00eb i duksh\u00ebm i lir\u00eb i atij periudhe, GumTree, u krijua nga nj\u00eb hulumtues me nj\u00eb sfond akademik, \u00ebsht\u00eb shkruar n\u00eb Java, ka nj\u00eb p\u00ebrfaq\u00ebsim t\u00eb brendsh\u00ebm abstrakt, q\u00eb i p\u00ebrkiste para treesitter, ka backend si ato q\u00eb bazohen n\u00eb treesitter ashtu edhe ato q\u00eb bazohen n\u00eb mjete t\u00eb tjera p\u00ebr analizimin e kodit burimor n\u00eb p\u00ebrfaq\u00ebsime abstrakte. Ky sistem di vet\u00ebm t\u00eb gjeneroj\u00eb (n\u00eb form\u00ebn e nj\u00eb logu t\u00eb ngjarjeve tekstuale, po ashtu ka nj\u00eb API q\u00eb mund t\u00eb thirret leht\u00ebsisht nga \u00e7do gjuh\u00eb programimi q\u00eb ka lidhje me Java) dhe t\u00eb vizualizoj\u00eb ndryshimet. Megjithat\u00eb, p\u00ebr p\u00ebrzierjen e ndryshimeve, po ashtu si p\u00ebr shikimin e skedar\u00ebve diff t\u00eb gjeneruar prej saj, ai \u00ebsht\u00eb i pap\u00ebrshtatsh\u00ebm nga kutia (megjithat\u00eb, \u00ebsht\u00eb e mundur q\u00eb ngarkimi i diffeve mund t\u00eb realizohet p\u00ebrmes API-s\u00eb). <\/p>\n
Nj\u00eb implementim m\u00eb i ri dhe m\u00eb praktik i difftastic, i shkruar n\u00eb Rust, bazohet n\u00eb treesitter, \u00ebsht\u00eb fokusuar n\u00eb gjenerimin e diffeve t\u00eb ndri\u00e7uara n\u00eb konsol\u00eb. Ky sistem gjithashtu \u00ebsht\u00eb i orientuar drejt vizualizimit t\u00eb diffeve dhe n\u00eb p\u00ebrgjith\u00ebsi nuk ka si q\u00ebllim p\u00ebrzierjen e ndryshimeve ose aplikimin e patch-eve. <\/p>\n
Koh\u00ebt e fundit ka dal\u00eb dhe po zhvillohet me intensitet projekti mergiraf. Ky instrument i shkruar n\u00eb Rust (z\u00eb 21 MiB!) gjithashtu \u00ebsht\u00eb i bazuar n\u00eb treesitter, i cili tashm\u00eb \u00ebsht\u00eb shnd\u00ebrruar n\u00eb nj\u00eb standard p\u00ebr analizuesit e gramatikave kontekstualisht t\u00eb lira n\u00eb mjetet zhvillimore, ashtu si\u00e7 \u00ebsht\u00eb b\u00ebr\u00eb LLVM p\u00ebr optimizimin e paraqitjeve t\u00eb ul\u00ebta t\u00eb instruksioneve. N\u00eb dallim nga konkurrent\u00ebt, mergiraf ofron funksione jo p\u00ebr gjenerimin e diffeve, por p\u00ebr zgjidhjen automatike t\u00eb konflikteve t\u00eb p\u00ebrzierjes. N\u00ebn kapu\u00e7, mergiraf p\u00ebrdor p\u00ebr gjenerimin e patch-eve realizimin e algoritmit t\u00eb p\u00ebrdorur n\u00eb GumTree, dhe p\u00ebr aplikimin \u2014 realizimin e algoritmit t\u00eb p\u00ebrdorur n\u00eb spork, t\u00eb p\u00ebrshtatur p\u00ebr strukturat e treesitter. <\/p>\n
Serializimi i patch-eve n\u00eb skedar\u00eb, t\u00eb cilat mund t\u00eb aplikohen m\u00eb von\u00eb, p\u00ebr fat t\u00eb keq, nuk \u00ebsht\u00eb realizuar (por \u00ebsht\u00eb e mundur q\u00eb t\u00eb realizohet p\u00ebrmes analizimit t\u00eb logeve t\u00eb ngjarjeve q\u00eb gjenerohen nga GumTree). Nj\u00eb m\u00ebnyr\u00eb tjet\u00ebr e premtuar p\u00ebr aplikimin e ndryshimeve mund t\u00eb jet\u00eb p\u00ebrdorimi i ndryshimeve jo p\u00ebrmes patch-eve, por p\u00ebrmes funksionalitetit t\u00eb rishikimit t\u00eb server\u00ebve LSP, q\u00eb mund t\u00eb ndihmoj\u00eb n\u00eb identifikimin e konflikteve n\u00eb nivelin e t\u00ebr\u00eb projektit. Vizualizimi mb\u00ebshtetet vet\u00ebm p\u00ebr konfliktet. <\/p>\n
Shembuj pune: paraardh\u00ebsi i p\u00ebrbashk\u00ebt «base.py» (t\u00ebrheqjet me tab, nj\u00eb rresht i tep\u00ebrt n\u00eb fillim) foo = 1 def main(): print(foo + 2 + 3) «a.py» (t\u00ebrheqjet ende me tab, 2 rreshta t\u00eb tep\u00ebrt n\u00eb fillim n\u00eb vend t\u00eb nj\u00eb, p\u00ebr printimin e depurimit \u00ebsht\u00eb p\u00ebrdorur biblioteka icecream, \u00ebsht\u00eb shtuar klasa «baz»: from icecream import ic foo = 1 def main(): ic(foo + 2 + 3) class baz: def __init__(self): «»»baz»»» «b.py» (variabli «foo» \u00ebsht\u00eb rinomuar n\u00eb «bar», \u00ebsht\u00eb p\u00ebrpunuar me «black» pas ndryshimeve, si rezultat, t\u00ebrheqjet jan\u00eb me hap\u00ebsira dhe rreshtat e tep\u00ebrt jan\u00eb hequr): bar = 1 def main(): print(bar + 2 + 3) Thirrja .\\\/mergiraf merge .\\\/base.py .\\\/a.py .\\\/b.py -x a.py -y b.py -s base.py -o .\\\/res.py jep rezultatin e m\u00ebposht\u00ebm from icecream import ic bar = 1 def main(): ic(bar + 2 + 3) class baz: def __init__(self): «»»baz»»» (p\u00ebr printimin e depurimit \u00ebsht\u00eb p\u00ebrdorur biblioteka «icecream», variabli «foo» \u00ebsht\u00eb rinomuar n\u00eb «bar», \u00ebsht\u00eb p\u00ebrpunuar me «black» pas ndryshimeve, si rezultat, t\u00ebrheqjet jan\u00eb me hap\u00ebsira dhe rreshtat e tep\u00ebrt jan\u00eb hequr, kombinim i tabave dhe hap\u00ebsirave p\u00ebr t\u00ebrheqje, por pamja e lejuar). <\/p>\n