On v\u00e4lja antud mergiraf projekti versioon 0.4, mis arendab Git'i draiverit, v\u00f5imaldades kolme k\u00fclje \u00fchendamist. Mergiraf toetab erinevate konfliktit\u00fc\u00fcpide lahendamist \u00fchendamisel ning v\u00f5ib olla kasutusel erinevate programmeerimiskeelte ja failivormingute jaoks. On v\u00f5imalik, et mergiraf kutsub eraldi esile konfliktide t\u00f6\u00f6tlemiseks, mis tekivad tavalise Git'iga t\u00f6\u00f6tades, samuti asendab Git'i \u00fchendamise k\u00e4itlejat, et laiendada selliste k\u00e4su nagu merge, revert, rebase ja cherry-pick v\u00f5imalusi. Kood on saadaval GPLv3 litsentsi alusel. Uues versioonis on lisatud tugi keelte Python, TOML, Scala ja TypeScript jaoks ning viidatud on j\u00f5udluse optimeerimisele. <\/p>\n
Allpool on toodud \u00fcksikasjalik kirjeldus probleemidest, mida mergiraf aitab lahendada: <\/p>\n
Tarkvara on s\u00e4rav n\u00e4ide \u00e4\u00e4rmiselt keerulisest s\u00fcsteemist. Keerulistel s\u00fcsteemidel on \u00fcks \u00fchine omadus \u2014 need on KEERULISED \u2014 ja te ei saa oodata, et vajalik keeruline k\u00e4itumine tekib iseenesest, juhuslikult. Selle asemel areneb see s\u00fcsteem ajas, samm-sammult, ja iga mutatsioon kontrollitakse hoolikalt igal sammul. Selle saavutamiseks on vajalik h\u00e4sti m\u00e4\u00e4ratletud struktuur ja vastavad t\u00f6\u00f6riistad. Iga keerulise s\u00fcsteemi evolutsioon on visualiseeritav suunatud puuna, kus juur esindab t\u00fchjalt funktsioonide kogumit, ja iga s\u00f5lm \u2014 v\u00e4lja arvatud juur \u2014 on tulemus mutatsiooni rakendamisest oma vanemale. <\/p>\n
Toodete kontekstis nimetatakse iga s\u00f5lme 'versiooniks', mis esindab kindlat funktsioonide ja antifunktsioonide kogumit. Iga selle kogumi muudatus loetakse mutatsiooniks, mis loob serva meie suunatud suletud graafikus. Need funktsioonid on oma olemuselt abstraktsed; need ei kajasta otseselt f\u00fc\u00fcsiliste s\u00fcsteemide toimimise viise, vaid n\u00e4itavad, kuidas m\u00f5istlikud agendid tajuvad nende s\u00fcsteemide kasulikkust. Ideede t\u00f5lkimiseks olemasolevatesse reaalses maailmas rakendustesse on vajalik k\u00e4\u00e4rid \u00fcles rullida ja sukelduda *piisavalt* madalatesse detailidesse, milles saab v\u00e4ljendada ja selgitada, kuidas k\u00f5ik t\u00e4pselt t\u00f6\u00f6tab. Tarkvaraarenduses on need madala taseme detailid tavaliselt esindatud l\u00e4htekoodiga. <\/p>\n
Ettepanekute j\u00e4rkj\u00e4rgulise parandamise saavutamiseks ja selle dokumenteerimiseks, kuidas nad sinna j\u00f5udsid, esitavad programmeerijad oma t\u00f6\u00f6d snapshot'ide ja changeset'ide terminoloogias. Snapshot esindab toote kindlat olekut koos k\u00f5igi madalatelt tasemetelt detailidega, samas kui changeset t\u00e4histab \u00fcleminekut snapshot'ide vahel. T\u00fc\u00fcpiliselt tekivad snapshot'id \u00fcksikute changeset'ide kaudu nende vanematele, seet\u00f5ttu on need snapshot'id enamasti t\u00e4histatud muutustega, mis need l\u00f5id, mist\u00f5ttu kasutatakse neid termineid tihti vaheldumisi. <\/p>\n
M\u00f5nikord eksisteerivad pildid, mis on saadud mitme \u00fclemineku tulemusena \u2014 commitide \u00fchendamine. Nendega on keeruline t\u00f6\u00f6tada, seet\u00f5ttu neid tavaliselt v\u00e4ltida. Kaasaegsed avatud l\u00e4htekoodiga versioonihalduss\u00fcsteemid, nagu Git, pakuvad \u00fcsna p\u00f5hilisi v\u00f5imalusi arendusprotsesside haldamiseks. Need v\u00f5imaldavad arendajatel korraldada pilte suunatud suletud graafikutena, m\u00e4rkida need kommentaaridega ja vajadusel muuta nende j\u00e4rjekorda. <\/p>\n
See funktsionaalsus v\u00f5imaldab arendajatel kirjutada semantiliselt olulist projekti lugu, mis on kriitilise t\u00e4htsusega t\u00f5rgete t\u00f5rkeotsimiseks ja k\u00fcsimustele vastamiseks, nagu n\u00e4iteks: \u201eMiks see madala taseme detail (nt muutuja) sisse viidi?\u201d, \u201eKui suur on minu panus sellesse projekti?\u201d, \u201eKeda on tagakiusatud, kui ja millal?\u201d ja \u201eMilline madala taseme muudatus katkestas selle funktsiooni (kuigi tunned, et see ei pidanud, me kontrollisime k\u00f5ike!?)\u201d <\/p>\n
Versioonihalduss\u00fcsteemid t\u00e4iendavad seda haru m\u00f5istega \u2014 madala taseme m\u00f5isted, mis lihtsalt t\u00e4histavad pidevat madala taseme projekti ajalugu, semantiliselt olulised arendajale. Harud kasutatakse tavaliselt funktsioonide konkreetse rakenduse jaoks, m\u00f5nikord luuakse mitmeid harusid erinevate kandidaatide jaoks sama funktsiooni rakendamiseks. Kasutades harude t\u00f6\u00f6vooge (mis on tegelikult peavool ja arendamise standard, mida kasutatakse igal pool), saab iga individuaalne arendaja t\u00f5husalt hallata mitmeid konflikteeruvaid projektiharusid, millest iga\u00fcks erineb valmiduse v\u00f5i kvaliteedi astme poolest. See v\u00f5imaldab arendajatel omavahel kombineerida oma ja teiste t\u00f6\u00f6d, ilma et nad peaksid iga kord kogu protsessi uuesti k\u00e4sitsi l\u00e4bi tegema. <\/p>\n
Tavaliselt luuakse peamine haru, mis esindab \u201eametlikku\u201d toodet, millest hargnevad k\u00fclgharud iga funktsiooni jaoks, mis regulaarselt (ideaalis \u2014 p\u00e4rast iga commit'i) s\u00fcnkroniseeritakse peamise haruga, v\u00f5imaldades arendajatel t\u00f6\u00f6tada k\u00f5ige v\u00e4rskema toote versiooniga ja samal ajal rakendada funktsioone, mida nad hetkel arendavad, tuvastades probleeme, mis tulenevad teiste arendajate tegevusest, nii vara kui v\u00f5imalik. <\/p>\n
Erinevate snapshot-ide funktsioonide kombineerimine (mis on lihtsalt \u00fchise vanema leidmine ja muutuste kogumite rakendamine j\u00e4rjekindlalt teise kohal, seda operatsiooni nimetatakse rebase'iks; sulandumine on peaaegu nagu rebase, lihtsalt struktureerib commitide graafi teistmoodi, mist\u00f5ttu on sellega keeruline manipuleerida, seet\u00f5ttu p\u00fc\u00fctakse sulandumisest loobuda rebase'i kasuks) tekitab probleeme. Kaasaegsed versioonihalduss\u00fcsteemid (VCS) kasutavad sisemisi muudatuste \u00fchendamise algoritme, mis lihtsalt jagavad failid eraldi ridadeks, k\u00e4sitlevad iga rea s\u00fcmbolina ja faile kui nende j\u00e4rjestusi ning seej\u00e4rel rakendavad algoritme nende \u00fchendamiseks, mis on p\u00e4rit bioinformaatikast. <\/p>\n
Kahjuks pole selline ridade kaupa esitus koodist midagi \u00fchist selle sisuga. Tema ainus eelis on see, et see on lihtne ja universaalne. Ebak\u00f5la toob kaasa konflikte, mis on pidev peavalu arendajatele. Konfliktide lahendamine n\u00f5uab arendajalt p\u00f5hjalikku uurimist m\u00f5lema koodiversiooni, sealhulgas mitte ainult ridade osade, mida read v\u00f5rreldes muutustena v\u00f5i konfliktidena m\u00e4\u00e4ratlevad, vaid v\u00f5ib-olla ka kogu projekti \u00fcle. <\/p>\n
Arendaja peab muutuseid m\u00f5istma, k\u00e4sitsi kirjutama \u00fchendatud koodi ja lahendama k\u00f5ik ebak\u00f5lad. Probleemide arv suureneb, kui ridade kaupa t\u00f6\u00f6riist tuvastab muutused valesti, mis juhtub sageli ulatuslike muudatuste puhul, sealhulgas triviaalsete, nagu koodi \u00fcmberformateerimine. Kui edasised muudatused ei \u00f5nnestu k\u00e4sitsi \u00fchendatud koodile rakendada, muutub olukord t\u00e4ielikuks \u00f5uduseks. Hirmu\u00e4ratavatest juhtumitest hoolimata t\u00f6\u00f6tab ridade kaupa algoritm enamikul juhtudel, eriti kui arendajad aktiivselt p\u00fc\u00fcavad v\u00e4ltida probleemide tekitamist. \u00dcks viis selliste probleemide minimeerimiseks on n\u00f5uda, et l\u00e4htekoodid t\u00f6\u00f6deldaks kanoniseerimise t\u00f6\u00f6riistadega, nagu black. <\/p>\n
Muidugi on \u00f5ige lahendus kohutavate olukordade jaoks (ja mitte ainult nende jaoks, rida-rida algoritm - see on heuristika, mis v\u00f5ib triviaalsete viiside kaudu viia mittet\u00f6\u00f6tava koodini, n\u00e4iteks nimetas \u00fcks arendaja muutuja \u00fcmber, samas kui teine kirjutas uut koodi, mis kasutas seda muutujat; sulandumise\/taaspaigutamise konflikti siin ei tule, kuid tulemusest saab mittet\u00f6\u00f6tav) - see on \u00f5ige sisemise mudeli kasutamine. <\/p>\n
Hoolimata asjaolust, et selle valdkonna uurimist\u00f6\u00f6d on tehtud juba ligi 30 aastat ja need on viinud mitmete patenteeritud kaubanduslike toodete loomise, ei ole neid uuringute tulemusi viimase ajani muundatud praktiliseks rakenduseks avatud l\u00e4htekoodiga toodetes. Enamus avatud l\u00e4htekoodiga lahendusi hakkasid arenema 2010. aastate alguses ja keskendusid peamiselt Java keelele. <\/p>\n
Selle perioodi k\u00f5ige silmapaistvam avatud rakendus, GumTree, on loodud akadeemilise taustaga teadlase poolt, kirjutatud Java keeles, omab oma abstraktset sisemist representatsiooni, mis eelneb treesitter'ile, ning tal on nii treesitter'ile kui ka teistele t\u00f6\u00f6riistadele p\u00f5hinevad tagaplaanid, mis teisendavad allika koodi abstraktseteks representatsioonideks. See s\u00fcsteem suudab ainult genereerida (s\u00fcndmustest tekstilise logina, samuti on olemas API, mida saab lihtsalt kutsuda mis tahes programmeerimiskeelest, mis omab Java binde) ja visualiseerida muudatusi. Siiski ei sobi see s\u00fcsteem muudatuste \u00fchinemiseks ega genereeritud diff-failide vaatamiseks, kuigi t\u00f5en\u00e4oliselt saab diff'e API kaudu \u00fcles laadida. <\/p>\n
Noorem ja praktiliselt rakendatav versioon difftastic on kirjutatud Rust keeles, p\u00f5hineb treesitter'il ja keskendub v\u00e4rviliste diff'ide genereerimisele konsoolis. See s\u00fcsteem on samuti suunatud diff'ide visualiseerimisele ja ei p\u00fc\u00fcdle muudatuste integreerimise v\u00f5i patch'ide rakendamise poole. <\/p>\n
Hiljuti ilmus ja aktiivselt areneb projekt mergiraf. See Rustis kirjutatud t\u00f6\u00f6riist (mahub 21 MiB!) p\u00f5hineb samuti treesitteril, mis on saanud sama standardiks kontekstivabade grammatikate parseritele arendust\u00f6\u00f6riistades, nagu LLVM on madala taseme k\u00e4suj\u00f5udude optimeerimiseks. Erinevalt konkurentidest pakub mergiraf funktsioone mitte diff-ide genereerimiseks, vaid sulandumiskonfliktide automaatseks lahendamiseks. Mergiraf kasutab allpool pat\u0161ide genereerimiseks GumTree algoritmi rakendust ja rakendamiseks sporki algoritmi rakendust, mis on kohandatud treesitteri struktuuride jaoks. <\/p>\n
Kahjuks ei ole patch'ide serialiseerimine failidesse, mida saaks hiljem rakendada, teostatud (kuid on t\u00f5en\u00e4oline, et seda v\u00f5iks teostada GumTree genereeritud s\u00fcndmuslogide anal\u00fc\u00fcsi kaudu). Teine perspektiivikas viis erinevuste rakendamiseks v\u00f5iks olla nende rakendamine mitte patch'ide kaudu, vaid LSP-serverite refaktoreerimisfunktsionaalsuse kaudu, mis v\u00f5iks aidata konflikte tuvastada kogu projekti tasandil. Visualiseerimine toetatakse ainult konfliktide korral. <\/p>\n
T\u00f6\u00f6 n\u00e4ide: \u00fchine esiisa \u00abbase.py\u00bb (tabidega sisestamine, \u00fcleliigne rida alguses) foo = 1 def main(): print(foo + 2 + 3) \u00aba.py\u00bb (sisestamine on endiselt tabidega, 2 \u00fcleliigset rida alguses, silumiste printimiseks on kasutatud j\u00e4\u00e4kme raamatut, lisatud klass \u00abbaz\u00bb: from icecream import ic foo = 1 def main(): ic(foo + 2 + 3) class baz: def __init__(self): \u00ab\u00bbbaz\u00ab\u00bb \u00ab\u00ab \u00abb.py\u00bb (muutuja \u00abfoo\u00bb on \u00fcmber nimetatud \u00abbar\u00bb-iks, t\u00f6\u00f6deldud kasutades \u00abblack\u00bb p\u00e4rast muudatusi, tulemuseks on sisestamine - t\u00fchikud ja \u00fcleliigsed read on eemaldatud): bar = 1 def main(): print(bar + 2 + 3) Kutsumine .\/mergiraf merge .\/base.py .\/a.py .\/b.py -x a.py -y b.py -s base.py -o .\/res.py annab j\u00e4rgmise tulemuse from icecream import ic bar = 1 def main(): ic(bar + 2 + 3) class baz: def __init__(self): \u00ab\u00bbbaz\u00ab\u00bb (silumiste printimiseks on kasutatud j\u00e4\u00e4kme raamatut, muutuja \u00abfoo\u00bb on \u00fcmber nimetatud \u00abbar\u00bb-iks, t\u00f6\u00f6deldud kasutades \u00abblack\u00bb p\u00e4rast muutusi, tulemuseks on sisestamine - t\u00fchikud ja \u00fcleliigsed read on eemaldatud, tabide ja t\u00fchikute segu sisestamiseks, kuid lubatud vorm). <\/p>\n