Kontrolli i versionit

Kontrolli i versionit (i njohur gjithashtu si kontrolli i rishikimit, kontrolli i burimit dhe menaxhimi i kodit burimor) është një praktikë inxhinierike e softuerit për të kontrolluar, organizuar, dhe për të gjurmuar versione të ndryshme në historinë e skedarëve kompjuterikë ; kryesisht skedarët e tekstit me kod burimor, por në përgjithësi mund të aplikohet për çdo lloj skedari.

Kontrolli i versioneve (versionit) është një pjesë e menaxhimit të konfigurimit të softuerit.

Një sistem i kontrollit të versionit është një mjet softuerik që automatizon kontrollin e versionit. Si alternativë, kontrolli i versionit është i inkorporuar si një veçori e disa sistemeve të ndryshme dhe shumë të rëndësishme, si përpunuesit e tekstit, fletëllogaritësit, dokumentet bashkëpunuese të uebit, dhe sistemet e menaxhimit të përmbajtjes, për shembull, historia e faqeve të Wikipedia-s .

Kontrolli i versionit përfshin shikimin e versioneve të vjetra dhe mundëson rikthimin e një skedari në një version të mëparshëm, i cili poashtu mund të rishikohet.

Vështrim i përgjithshëm

Ndërsa ekipet zhvillojnë softuerin, është e zakonshme që shumë versione të softuerit të përdoren në vende të ndryshme dhe që zhvilluesit të punojnë në mënyrë të pavarur në përditësime. Gabimet ose veçoritë e softuerit shpesh janë të pranishme vetëm në versione të caktuara (për shkak të rregullimit të disa problemeve dhe prezantimit të problemeve tjera ndërsa programi zhvillohet). Prandaj, për qëllime të lokalizimit dhe rregullimit të gabimeve, është shumë e rëndësishme të rikuperoni dhe ekzekutoni versione të ndryshme të softuerit për të përcaktuar se në cilin(at) version(e) shfaqet problemi.Gjithashtu, mund të jetë e nevojshme të zhvillohen dy versione të softuerit njëkohësisht: për shembull, ku një version ka përmirësuar gabime, por nuk ka veçori të reja (dega ), ndërsa versioni tjetër është ai ku punohet për shtimin e veçorive të reja (trunk ).

Në nivelin më të thjeshtë, zhvilluesit thjesht mund të krijojnë dhe mbajnë kopje të ndryshme të versioneve të programit dhe t'i etiketojnë ato në mënyrë të duhur. Kjo qasje është përdorur në shumë projekte të mëdha softuerike,por ka disa kufizime. Ndërsa kjo metodë mund të funksionojë, ajo është joefikase pasi duhen mbajtur shumë kopje pothuajse identike të programit. Kjo kërkon shumë disiplinë nga ana e zhvilluesve dhe shpesh çon në gabime. Pasi që baza e kodit është e njëjtë, ajo gjithashtu kërkon dhënien e lejes për lexim-shkrim-ekzekutim për një grup zhvilluesish dhe kjo shton presionin e dikujt që menaxhon lejet për të siguruar që baza e kodit të mos komprometohet, çka shton më shumë kompleksitet. Si pasojë, janë zhvilluar sisteme për automatizimin e disa pjesëve ose të gjithë procesin e kontrollit të rishikimit. Kjo siguron që menaxhimi i shumicës së hapave të kontrollit të versioneve të jetë i fshehur pas skenave.

Për më tepër, në zhvillimin e softuerit, praktikat ligjore dhe të biznesit dhe në mjedise të tjera, është bërë gjithnjë e më e zakonshme që një dokument i vetëm ose një pjesë kodi të redaktohet nga një ekip i vetëm, ku anëtarët e tij mund të jenë të shpërndarë gjeografikisht dhe mund të ndjekin interesa të ndryshme dhe madje edhe interesa të kundërta. Kontrolli i sofistikuar i rishikimit, i cili ndjek dhe regjistron pronësinë e ndryshimeve në dokumente dhe kode mund të jetë jashtëzakonisht i dobishëm, madje edhe i domosdoshëm në situata të tilla, pothuajse të njëjta.

Kontrolli i rishikimit mund të ndjekë gjithashtu ndryshimet në skedarët e konfigurimit, si ata që zakonisht ruhen në /etc ose /usr/local/etc në sistemet Unix. Kjo u jep administratorëve të sistemit një mënyrë tjetër për të ndjekur lehtësisht ndryshimet e bëra dhe gjithashtu një mënyrë për t'i kthyer në versionet e mëparshme nëse domosdoshmërisht është e nevojshme.

Shumë sisteme të kontrollit të versioneve e identifikojnë versionin e një skedari (file) si një numër ose shkronjë, i quajtur numri i versionit, versioni, numri i revizionit, revizioni ose niveli i reverzionit. Për shembull, versioni i parë i një skedari mund të jetë versioni 1..Kur skedari ndryshohet, versioni tjetër është versioni 2. Çdo version shoqërohet me një shenjë kohore (timestamp) dhe personin që ka bërë ndryshimin. Rishikimet ose revizionet mund të krahasohen, të rikthehen dhe, me disa lloje skedarësh, mund të bashkohen (merge).

Historia

Mjeti i përditësimit të softuerit IEBUPDTE OS/360 i IBM e ka origjinën në vitin 1962, mund të konsiderohet si një paraardhës i mjeteve të sistemit të kontrollit të versionit. Dy paketa të menaxhimit të burimit dhe kontrollit të versionit që janë përdorur shumë nga instalimet e IBM 360/370 ishin The Librarian dhe Panvalet.

Një sistem i plotë i dizajnuar për kontrollin e kodit burimor filloi në vitin 1972, i quajtur Sistemi i Kontrollit të Kodit Burimor për të njëjtin sistem (OS/360). Prezantimi i Sistemit të Kontrollit të Kodit Burimor, i publikuar më 4 dhjetor 1975, historikisht nënkuptohet se ishte sistemi i parë i kontrollit të rishikimit të qëllimshëm. RCS erdhi menjëherë pas tij, duke pasuar me versionin e tij të rrjetit Sistemi i versioneve të njëkohshme .Gjenerata tjetër pas Sistemit të Versioneve të Njëkohshme ishe e dominuar nga Subversion, pasuar nga ngritja e mjeteve të kontrollit të rishikimeve të shpërndara si Git.

Struktura

Kontrolli i rishikimit menaxhon ndryshimet në një grup të dhënash gjatë kohës. Këto ndryshime mund të jenë të organizuara ose të strukturuara në forma të ndryshme.

Shpesh të dhënat mendohen si një koleksion i shumë artikujve individualë, siq janë skedarët ose dokumentet, dhe ndryshimet në skedarë individualë janë të gjurmuara. Kjo përputhet me intuitat rreth skedarëve të veçantë, por shkakton probleme kur ndryshon identiteti; siq ndodh gjatë riemërtimit, ndarjes ose bashkimit të skedarëve. Prandaj, disa sisteme si Git, në vend të kësaj, e konsiderojnë ndryshimin e të dhënave në tërësi, që është më pak i kuptueshëm për ndryshime të thjeshta, por thjeshton ndryshime më të ndërlikuara.

Kur të dhënat që janë nën kontrollin e rishikimeve modifikohen, pas tërheqjes së tyre duke i kontrolluar, këto ndryshime nuk reflektohen menjëherë në sistemin e kontrollit të rishikimit (në depo ), por duhet të kontrollohen ose të angazhohen. Një kopje jashtë kontrollit të rishikimit është e njohur si "kopje pune" (working copy). Si një shembull i thjeshtë, kur redaktohet (editohet) një skedar kompjuterik, të dhënat e ruajtura në memorie nga programi i redaktimit janë kopje e punës, e cila kryhet duke e ruajtur. Konkretisht, dikush mund të printojë një dokument, ta editojë me dorë dhe më vonë të futë në mënyrë manuale ndryshimet në një kompjuter dhe ta ruajë. Për kontrollin e kodit burimor, kopja e punës është një kopje e të gjithë skedarëve në një rishikim të caktuar, e ruajtur lokalisht në kompjuterin e zhvilluesit; në këtë rast ruajtja e skedarit ndikon vetëm në kopjen e punës dhe kontrollimi në depo është një hap i veçantë.

Nëse disa persona janë duke punuar në të njëjtën të dhënë ose dokument, ata automatikisht krijojnë dega të të dhënave (në kopjet e tyre të punës), dhe kështu lindin çështje për lidhjen e ndryshimeve, siç do të diskutohet më poshtë. Për redaktimin e thjeshtë të dokumenteve nv mënyrë bashkëpunuese, kjo mund të parandalohet duke përdorur bllokimin e skedarëve ose thjesht duke shmangur punën në të njëjtin dokument me të cilin ëhtë duke punuar dikush tjetër.

Sistemet e kontrollit të revizioneve shpesh janë të centralizuara, me një depo të vetme autoritative të të dhënave, dhe veprimet e tërheqjes së skedarëve bëhen me referencë nga kjo depo qendrore Përndryshe, në kontrollin e rishikimeve të shpërndara, nuk ka depo të vetme autoritative dhe të dhënat mund të ngarkohen dhe shkarkohen në çdo depo. Kur bëhet kontrollomi në një depo tjetër, kjo interpretohet si një bashkim ose korrigjim (patch).

Struktura e grafikut

Shembull i grafikut historik të një projekti të kontrolluar nga rishikimi; trungu është në të gjelbër, degët në të verdhë, dhe grafiku nuk është një pemë për shkak të pranisë së bashkimeve (shigjetat e kuqe).

Në terma të teorisë së grafikëve, rishikimet zakonisht mendohet se janë një linjë zhvillimi (trungu) me degë që dalin prej saj, duke formuar një pemë të drejtuar, e vizualizuar si një ose më shumë linja paralele të zhvillimit ("pikat kryesore" të degëve) që degëzohen nga trungu. Në realitet struktura është më e ndërlikuar, duke formuar një graf jociklik të drejtuar, por për shumë qëllime "pema me bashkime" është një përafrim adekuat.

Rishikimet ndodhin në një rend kronologjik dhe, për këtë arsye, mund të renditen sipas numrit të rishikimit ose numrit të kohës. Rishikimet janë të bazuara në ato të mëparshme, megjithatë mund të ndodhin raste kur një revizion i hershëm mund të zëvendësohet pjesërisht ose plotësisht, si për shembull "fshi gjithë tekstin ekzistues dhe shto tekst të ri". Në rastin më të thjeshtë, pa degë ose kthime, çdo rishikim është i bazuar vetëm në rishikimin e tij të menjëhershëm dhe ato formojnë një linjë të drejtpërdrejtë, me një version të fundit, i cili njihet si revizioni HEAD (koka). Në termat e teorisë së grafikëve, duke tërhequr çdo rishikim si një pikë dhe çdo marrëdhënie si "rishikim i nxjerrë" si një shigjetë (që zakonisht shënon nga më i vjetri tek më i riu, në drejtim të njëjtë me kohën), është një grafik linear. Nëse ekzistojnë degëzime, ku shumë rishikime të ardhshme bazohen në një rishikim të kaluar ose anasjelltas, kështu që një rishikim mund të varet nga një rishikim më i vjetër se paraardhësi i tij i menjëhershëm, atëherë grafiku që rezulton është një pemë e drejtuar (direkte) (çdo nyje mund të ketë më shumë se një fëmijë), dhe ka këshilla të shumta, që korrespondojnë me rishikimet pa fëmijë ("rishikimi i fundit në secilën degë"). Parimisht, pema që rezulton nuk ka nevojë të ketë një majë të preferuar (rishikimi "kryesor" i fundit) - vetëm rishikime të ndryshme - por në praktikë një majë e pemës definohet si HEAD (kokë). Kur një rishikim i ri bazohet në HEAD, ai ose identifikohet si HEAD i ri, ose konsiderohet si një degë e re. Lista e rishikimeve nga fillimi deri në HEAD (në termat e teorisë së grafeve, rruga unike në pemë, e cila formon një graf linear si më parë) është trungu ose linja kryesore. Kjo ndodh më shpesh kur ndryshimet ndodhin në shumë degë (zakonisht dy, por është e mundur edhe më shumë), të cilat më pas bashkohen në një degë të vetme e cila përfshin të dy ndryshimet. Nëse këto ndryshime mbivendosen (përputhen), mund të jetë e vështirë ose e pamundur t'i bashkohen,dhe këtu paraqitet nevoja për intervenim manual apo rishkrim.

Në prani të bashkimeve (merges), grafi që rezulton nuk është më një pemë, pasi nyjet mund të kenë më shumë se një prind, por bëhet një graf aciklik i drejtuar me rrënjë (DAG). Grafi është aciklik, pasi prindërit janë gjithmonë të prapambetur, dhe të rrënjëzuar, pasi ekziston një version më i vjetër. Duke supozuar që ka një trung, bashkimet nga degët mund të konsiderohen si "të jashtme" për pemën – ndryshimet në degë paketohen si një patch dhe aplikohen në HEAD (të trungut), duke krijuar një rishikim të ri pa ndonjë referencë të drejtpërdrejtë ndaj degës, dhe duke ruajtur strukturën e pemës. Pra, ndërsa marrëdhëniet aktuale midis versioneve formojnë një DAG, kjo mund të konsiderohet si një pemë plus bashkime, dhe trungu vetë është një linjë.

Në kontrollin e rishikimeve të shpërndara, kur ka më shumë se një depo, këto mund të bazohen në një version origjinal të vetëm (një rrënjë të pemës), por nuk është e nevojshme që të ekzistojë një rrënjë origjinale e vetme – çdo depo mund të ketë një rrënjë të veçantë (rishikimin më të vjetër). Kjo mund të ndodhë, për shembull, në rastin kur dy persona fillojnë të punojnë veçmas në të njëjtin projekt. Po ashtu, kur ka grupe të shumta të të dhënave (projektesh të shumta) që shkëmbejnë ose bashkohen mes tyre, nuk ka një rrënjë të vetme, edhe pse për thjeshtësi, një projekt mund të konsiderohet si projekt kryesor, ndërsa tjetri si dytësor, të bashkuar me të parin me ose pa historinë e tij të rishikimeve.

Strategji të specializuara

Kontrolli i rishikimit inxhinierik, i zhvilluar nga proceset e formalizuara, bazohej në gjurmimin e planeve të hershme ose linjave blu </link>. Ky sistem i kontrollit lejonte automatikisht kthimin në një version të mëparshëm të hartimit, në rastet kur arrihej një pengesë inxhinierike gjatë zhvillimit të dizajnit. Përdorej një tabelë rishikimi për të regjistruar ndryshimet e realizuara. Për më tepër, zonat e modifikuara të vizatimit ishin theksuar duke përdorur shenjën e retës së rishikimit.

Në Biznes dhe Drejtësi

Kontrolli i versionit është i përdorur gjerësisht në biznes dhe ligj. Në fakt, "vija e kuqe e kontratës" dhe "vija e zezë ligjore" janë disa nga format më të hershme të kontrollit të rishikimit, dhe ende përdoren në biznes dhe ligj me nivele të ndryshme të sofistikimit.Këto metoda historike kanë ndihmuar në menaxhimin e ndryshimeve dhe sigurinë e dokumenteve të rëndësishme, veçanërisht në krijimin dhe rishikimin e kontratave ligjore dhe marrëveshjeve të biznesit. Teknikat më të sofistikuara po fillojnë të përdoren për gjurmimin elektronik të ndryshimeve në skedarët CAD (shih menaxhimin e të dhënave të produktit ), duke zëvendësuar zbatimin elektronik "manual" të kontrollit tradicional të rishikimit.</link>

Modelet e menaxhimit të burimit

Sistemet tradicionale të kontrollit të rishikimit përdorin një model të centralizuar, ku të gjitha funksionet e kontrollit të rishikimit ndodhin në një server të përbashkët. Ky model mund të krijojë probleme nëse dy zhvillues përpiqen të ndryshojnë të njëjtin skedar në të njëjtën kohë, pa një metodë për menaxhimin e aksesit, duke bërë që ata të mund të mbishkruajnë punën e njëri-tjetrit. Nëse dy zhvillues përpiqen të ndryshojnë të njëjtin skedar në të njëjtën kohë, pa një metodë për menaxhimin e aksesit, zhvilluesit mund të përfundojnë duke mbishkruar punën e njëri-tjetrit. Sistemet e kontrollit të rishikimit të centralizuar e zgjidhin këtë problem përmes dy modeleve të ndryshme të "menaxhimit të burimit" : bllokimi i skedarëve dhe bashkimi i versioneve.

Operacionet atomike

Një operacion quhet atomik nëse, edhe në rast ndërprerjeje, sistemi mbetet në një gjendje konsistente. Operacionet e detyrimeve janë zakonisht më të rëndësishmet në këtë kuptim. Detyrimet (Commits) janë sinjalizime për sistemin e kontrollit të rishikimit që një grup ndryshimesh ka përfunduar dhe është i disponueshëm për përdoruesit e tjerë. Megjithatë, jo të gjitha sistemet e kontrollit të rishikimit e mbështesin këtë lloj atomikiteti; për shembull, Sistemi i Versioneve të Njëkohshme nuk ofron këtë funksionalitet.

Mbyllja e skedarit

Një metodë e thjeshtë për të shmangur problemet e " qasjes së njëkohshme " përfshin mbylljen e skedarëve në mënyrë që vetëm një zhvillues në të njëjtën kohë të ketë akses për shkrim në një kohë të caktuar në kopjen qendrore " depo " të atyre skedarëve. Kur një zhvillues "kontrollon" një skedar, të tjerët mund ta lexojnë atë, por askush tjetër nuk mund ta modifikojë derisa zhvilluesi të ketë "kontrolluar" versionin e përditësuar ose të heqë dorë nga ndryshimet.

Bllokimi i skedarit ka avantazhe dhe disavantazhe. Ai mund të ofrojë një mbrojtje të vlefshme kundër konflikteve të vështira të bashkimit, sidomos kur një përdorues po bën ndryshime të thella në disa pjesë të një skedari të madh (ose një grup skedarësh). Megjithatë, nëse skedarët mbahen të kyçur për një periudhë të gjatë, zhvilluesit e tjerë mund të ndihen të shtyrë të anashkalojnë sistemin e kontrollit të rishikimit dhe të bëjnë ndryshime lokale, çka mund të sjellë nevojën për një bashkim të vështirë manual kur ndryshimet e tjera të jenë regjistruar. Në organizatat e mëdha, mund të ndodhë që skedarët të mbeten të "kontrolluar" dhe të kyçen për një kohë të gjatë, duke i lënë zhvilluesit të kalojnë nga një projekt në tjetrin, dhe ndonjëherë është e vështirë të përcaktohet se kush e ka "kontrolluar" një skedar.

Bashkimi i versionit

Shumica e sistemeve të kontrollit të versionit mundësojnë që disa zhvillues të bëjnë ndryshime në të njëjtin skedar në të njëjtën kohë. Zhvilluesi i parë që "kontrollon" ndryshimet në depot qendrore do të ketë gjithmonë sukses. Sistemi mund të ofrojë mundësi për të bashkuar të bashkuar ndryshime të tjera në depot qendrore dhe për të ruajtur ndryshimet e zhvilluesit të parë ndërkohë që zhvilluesit e tjerë regjistrohen ndryshimet e tyre.

Bashkimi i dy skedarëve mund të jetë një operacion i ndjeshëm dhe zakonisht është i mundur vetëm nëse struktura e të dhënave është e thjeshtë, siç është rasti me skedarët e tekstit. Rezultati i bashkimit të dy skedarëve të imazhit mund të mos rezultojë fare në një skedar imazhi. Zhvilluesi i dytë që kontrollon kodin do të duhet të kujdeset gjatë bashkimit, për t'u siguruar që ndryshimet të jenë të përputhshme dhe që operacioni i bashkimit nuk fut gabimet e veta logjike brenda skedarëve tjerë. Këto sfida kufizojnë përdorimin e operacioneve automatike ose gjysmë-automatike të bashkimit kryesisht në dokumente të thjeshta tekstualë, përveçse kur ka shtesa specifike shtojcë për bashkimin e llojeve tjera të skedarit.

Koncepti i një redaktimi të rezervuar mund të ofrojë një mundësi shtesë për të kyçur një skedar për qasje ekskluzive në shkrim, edhe në situatat kur është i mundur bashkimi i ndryshimeve.

Pikat e referimit,shënime dhe etiketat

Shumica e mjeteve të kontrollit të rishikimit (revizionit) do të përdorin vetëm një nga këto terma të ngjashëm (pikë referimi, shënim, etiketë) për të përshkruar veprimin e identifikimit të një fotografie të çastit ("etiketo projektin") ose regjistrimin e një momenti të caktuar ("provoje me pikë referimi X "). Zakonisht vetëm një nga termat pikë referimi, shënim ose etiketë përdoret në dokumentacion ose diskutime </link> ; ato mund të konsiderohen sinonime.

Në shumicën e projekteve, disa momente të caktuara janë më të rëndësishme se të tjerat, si ato që përdoren për të treguar publikimet, degët ose pikë-kalimet.

Kur të dy termat pikë referimi dhe etiketë ose shënim përdoren së bashku në të njëjtin kontekst, shënimi dhe etiketa zakonisht i referohen mekanizmit brenda mjetit të identifikimit ose regjistrimit të një momenti të caktuar, dhe pika e referimit tregon rëndësinë e shtuar të çdo etiketeje ose shënimi të caktuar.

Në shumicën e diskutimeve formale rreth menaxhimit të konfigurimit përdoret termi <i>pik</i>ë referimi.

Kontrolli i rishikimit të shpërndarë

Sistemet e kontrollit të rishikimit të shpërndarë (DRCS) marrin një qasje peer-to-peer, ndryshe nga qasja klient-server e sistemeve të centralizuara. Në vend që të ketë një depo qendrore ku klientët sinkronizohen, çdo kopje e punës e një anëtari të ekipit të zhvillimit është një depo e mirëbesimit. Kontrolli i rishikimeve të shpërndara realizon sinkronizimin duke shkëmbyer patches (ndryshime-set) nga peer-to-peer. Kjo rezulton në disa dallime të rëndësishme nga një sistem i centralizuar:

• Asnjë kopje kanonike, referuese e bazës së kodit nuk ekziston si parazgjedhje; vetëm kopjet e punës.
• Operacionet e zakonshme (siç janë kryerjet, shikimi i historisë dhe kthimi i ndryshimeve) janë të shpejta, sepse nuk ka nevojë të komunikoni me një server qendror.

Përkundrazi, komunikimi është i nevojshëm vetëm kur dërgohen ose tërhiqen ndryshime tek ose nga partnerët e tjerë.

• Çdo kopje e punës funksionon në mënyrë efektive si një kopje rezervë e largët e bazës së kodeve dhe e historisë së saj të ndryshimeve, duke siguruar mbrojtje të qenësishme kundër humbjes së të dhënave.

Praktikat më të mira

Për të shfrytëzuar plotësisht përfitimet e kontrollit të versionit, është e nevojshme të ndiqen praktikat më të mira. Këto praktika mund të ndryshojnë në varësi të mjetit të kontrollit të versionit dhe fushës ku zbatohet. Disa praktika të miratuara gjerësisht në zhvillimin e softuerit përfshijnë: bërjen e ndryshimeve në rritje, të vogla; kryerja e kompetencave duke siguruar që kodi të funksionojë dhe të mos dëmtojë funksionalitetin ekzistues; përdorimin e degëzimit për të zhvilluar funksionalitetin përpara se të bëhet lëshimi; shkrimi i mesazheve angazhimi të qarta dhe përshkrues për të shpjeguar arsyen dhe përmbajtjen e ndryshimeve; dhe përdorimi i një strategjie të qëndrueshme për menaxhimin e degëve.. Praktikat e tjera më të mira të zhvillimit të softuerit, si rishikimi i kodit dhe testimi i automatizuar i regresionit, mund të ndihmojnë në ndjekjen e praktikave më të mira të kontrollit të versionit.

Kostot dhe përfitimet

Kostot dhe përfitimet mund të ndryshojnë në varësi të mjetit të kontrollit të versionit të përdorur dhe fushës ku ai zbatohet. Ky seksion trajton fushën e zhvillimit të softuerit, ku kontrolli i versioneve është i përdorur gjerësisht.

Kostot

Përveç kostove të licencimit të softuerit të kontrollit të versionit, përdorimi i tij kërkon kohë dhe mund. Duhet të kuptohen konceptet themelore të kontrollit të versionit dhe të merren njohuri mbi të dhënat teknike të nevojshme për përdorimin e softuerit të zgjedhur. Praktikat më të mira të kontrollit të versionit duhet të mësohen dhe të përfshihen në proceset ekzistuese të zhvillimit të softuerit të organizatës. Po ashtu, mund të kërkohet përpjekje nga menaxhimi për të siguruar që praktikat më të mira të ndiqen, duke siguruar kështu përfitime të dobishme.

Përfitimet

Lejimet për rikthimin e ndryshimeve

Një përfitim kryesor është mundësia për të ruajtur historikun e ndryshimeve dhe për të rikthyer versionet e mëparshme, duke i mundësuar zhvilluesit të anulojë lehtësisht ndryshimet. Kjo u ofron zhvilluesve mundësi më të mëdha për të eksperimentuar, duke hequr frikën nga mundësia e dëmtimit të kodit ekzistues.

Degëzimi thjeshton vendosjen, mirëmbajtjen dhe zhvillimin

Degëzimi ndihmon në procesin e vendosjes. Degëzimi dhe bashkimi, prodhimi, paketimi dhe etiketimi i arnimeve të kodit burimor dhe aplikimi i lehtë i këtyre arnimeve në bazat e kodit, e bën më të thjeshtë mirëmbajtjen dhe zhvillimin paralel të kodeve të shumta që lidhen me fazat e ndryshme të procesit të vendosjes, siç janë zhvillimi, testimi, staging dhe prodhimi

Zbutja e dëmit, llogaridhënia dhe përmirësimi i procesit dhe dizajnit

Kontrolli i versionit mund të ofrojë përfitime të ndryshme, si zbutja e dëmit, llogaridhënie më të mirë, përmirësim të proceseve dhe dizajnit, si dhe mundësinë për të mbajtur gjurmët e aktiviteteve – si kush bëri çfarë, kur, përse dhe si.

Kur ndodhin defekte, njohja e ndryshimeve të bëra ndihmon në zbutjen dhe rikuperimin e dëmeve, duke lejuar identifikimin e problemeve ekzistuese, kohën kur janë shfaqur dhe përcaktimin e përmasave dhe mundësive për zgjidhje. Versionet e mëparshme mund të instalohen dhe testohen për të verifikuar përfundimet e arritura nga ekzaminimi i kodit dhe mesazhet e kryerjes.

Thjeshtëson korrigjimin e gabimeve

Kontrolli i versionit mund të lehtësojë ndjeshëm procesin e korrigjimit. Duke aplikuar një testim në versione të ndryshme, mund të identifikohet shpejt ndryshimi që ka shkaktuar një gabim. Zhvilluesi nuk ka nevojë të jetë i njohur me të gjithë bazën e kodit dhe në vend të kësaj mund të fokusohet në kodin që ka paraqitur problemin.

Përmirëson bashkëpunimin dhe komunikimin

Kontrolli i versionit përmirëson bashkëpunimin në shumë aspekte. Duke qenë se ai mund të identifikojë ndryshimet që shkaktojnë konflikte, si për shembull ndryshime të papajtueshme në të njëjtat linja kodi, kërkesa për koordinim mes zhvilluesve zvogëlohet.

Paketimi i angazhimeve, degëve, mesazheve të kryera dhe etiketave të versioneve të lidhura përmirëson komunikimin ndërmjet zhvilluesve, si gjatë procesit ashtu edhe në periudha të ndryshme në kohë. Komunikimi më i efektshëm, qoftë në kohë reale apo i shtyrë, mund të përmirësojë proceset e rishikimit të kodit, testimit dhe aspekte të tjera të rëndësishme të zhvillimit të softuerit.

Integrimi

Disa nga mjetet më të avancuara të kontrollit të rishikimit ofrojnë mundësi shtesë, duke mundësuar integrim më të thellë me mjete të tjera dhe procese të ndryshme të inxhinierisë së softuerit.

Mjedisi i integruar i zhvillimit

Shtojcat shpesh ofrohen për IDE të ndryshme, si Oracle JDeveloper, IntelliJ IDEA, Eclipse, Visual Studio, Delphi, NetBeans IDE, Xcode dhe GNU Emacs (nëpërmjet vc.el). Prototipat e avancuar të kërkimit krijojnë mesazhe angazhimi të përshtatshme.

Terminologji e zakonshme

Terminologjia mund të variojë nga një sistem në tjetrin, por disa terma të përdorur gjerësisht përfshijnë:

Pika e referimit (Baseline)

  Një version i miratuar i një dokumenti ose skedari burimor në të cilin mund të realizohen ndryshime të ndryshme të ardhshme. Shikoni vijat bazë, labels dhe etiketat .

Blame

Një hetim për autorin dhe një rishikim që ndryshoi për herë të fundit një rresht të caktuar.Kjo ndihmon në ruajtjen e transparencës dhe menaxhimin e efikasitetit të bashkëpunimit në një projekt.

Dega

Një grup skedarësh që janë nën kontrollin e versionit mund të ndahet ose të degëzohet në një pikë të caktuar kohore, duke lejuar që, pas asaj kohe, dy kopje të atyre skedarëve të zhvillohen në mënyra të ndryshme dhe në ritme të ndryshme, pa pasur nevojë të varen nga njëra-tjetra.

Ndryshimi (Change)

Një ndryshim (ose diff, ose delta) definohet si një modifikim specifik në një dokument nën kontrollin e versionit. Kufizimi i asaj që konsiderohet si ndryshim mund të ndryshojë në varësi të sistemit të kontrollit të versionit që po përdoret.

Change List

Në shumë sisteme të kontrollit të versioneve që mbështesin kryerje atomike me shumë ndryshime, një listë ndryshimesh (ose CL ), grup ndryshimesh, përditësime ose patch identifikon një grup ndryshimesh të bëra në një veprim të vetëm. Kjo gjithashtu mund të paraqesë një version të kodit burimor, duke mundësuar ekzaminimin e tij si një ID e veçantë për secilën listë ndryshimesh.

Kontrollimi (Checkout)

Kontrollimi (ose "checkout") do të thotë të krijosh një kopje lokale të punës nga depoja. Përdoruesi mund të zgjedhë një rishikim specifik ose të marrë versionin më të fundit. Termi "checkout" mund të përdoret gjithashtu për të përshkruar kopjen e punës të marrë. Kur një skedar është kontrolluar nga një server skedari i përbashkët, ai nuk mund të redaktohet (modifikohet) nga përdorues të tjerë. Mund ta mendoni si një hotel: kur largoheni, humbni qasjen në shërbimet e tij.

Klonimi (Clone)

Klonimi i referohet krijimit të një depoje që përmban rishikimet nga një depo tjetër. Ky proces është i barabartë me shtyrjen ose tërheqjen në një depo të zbrazët (të sapo krijuar). Kur përdoret si emër, dy depo mund të thuhet se janë klone nëse mbahen të sinkronizuara dhe përmbajnë të njëjtat rishikime.

Commit (emër)

Një ndryshim (anglisht: changeset) në sistemet e kontrollit të versioneve i referohet një grupi ndryshimesh (p.sh., skedarë të shtuar, modifikuar ose fshirë) të bashkuara në një njësi të vetme. Një ndryshim përshkruan diferencat e sakta midis dy versioneve të njëpasnjëshme në një depo (repository). Në shumicën e sistemeve të kontrollit të versioneve, ndryshimet trajtohen si një njësi atomike, pra një grup që nuk mund të ndahet më tej. Kjo është një mënyrë sinkronizimi që ndihmon në ruajtjen e saktësisë dhe integritetit të historisë së projektit.

Commit (folje)

Për të kryer (ose për të kontrolluar, "ci" ose, më rrallë, instaloni, dorëzoni ose regjistroni) do të thotë të shkruash ose bashkoni ndryshimet e bëra në kopjen e punës përsëri në depo. Një commit përfshin metadata, zakonisht informacionin e autorit dhe një mesazh që shpjegon ndryshimin e bërë.

Commit message

Një shënim i shkurtër, i shkruar nga zhvilluesi dhe i ruajtur me commit, që shpjegon commit-in. Idealisht, ai përshkruan arsyen për modifikimin, ndikimin ose qëllimin e tij dhe aspekte të tjera të dukshme të mënyrës se si funksionon ndryshimi.

Konflikti (Conflict)

Një konflikt ndodh kur dy ose më shumë palë bëjnë ndryshime në të njëjtin dokument dhe sistemi nuk arrin të bashkojë ndryshimet. Përdoruesi duhet ta zgjidhë konfliktin duke kombinuar ndryshimet, ose duke zgjedhur një variant përpara tjetrit.

Kompresimi delta (Delta compression)

Shumica e programeve të kontrollit të rishikimit përdorin kompresimin delta, i cili ruan vetëm ndryshimet midis dy versioneve të njëpasnjëshme të skedarëve. Kjo mundëson ruajtjen më efikase të disa versioneve të ndryshme të skedarëve.

Rrjedha dinamike (Dynamic stream)

Një rrjedhë në të cilën disa ose të gjitha versionet e skedarëve janë pasqyrë e versioneve të rrjedhës prind.

Eksporti (Export)

Eksportimi është akti i marrjes së skedarëve nga depoja. Ai është i ngjashëm me kontrollin, përveç se krijon një strukturë direktoriumi të pastër pa metadatat e kontrollit të versionit që përdoren në një kopje pune. Kjo zakonisht përdoret para publikimit të përmbajtjes, për shembull:

Fetch

Shih pull .

Integrimi përpara (Forward integration)

Procesi i integrimit të ndryshimeve të bëra në degën kryesore nga një degë zhvillimi (p.sh., veçori ose ekipi).

Head

I njohur ndonjëherë si "tip", kjo i referohet angazhimit më të fundit, qoftë në trung ose në një degë. Si trungu, ashtu edhe çdo degë kanë kokën e tyre, megjithatë, ndonjëherë termi "HEAD" përdoret në mënyrë të përgjithshme për të përshkruar trungun.

Importi

Importimi është procesi i kopjimit të një strukture drejtorish lokale (që aktualisht nuk është një kopje funksionale) në depo për herë të parë.

Inicializimi

Për të krijuar një depo të re, bosh.

Delta të ndërthurura (Interleaved deltas)

Disa software për kontrollin e rishikimeve përdorin deltat Interleaved, një metodë që mundëson ruajtjen e historikut të skedarëve të bazuar në tekst në një mënyrë më efikase krahasuar me kompresimin Delta .

Pikat e referimit, etiketat dhe shënimet

Shih etiketën .

Mbyllja (Locking)

Kur një zhvillues bllokon një skedar, asnjë përdorues tjetër nuk mund ta modifikojë atë skedar derisa të lirohet. Bllokimi mund të mbështetet nga sistemi i kontrollit të versionit, ose mund të realizohet përmes komunikimeve joformale mes zhvilluesve (aka social locking ).

Linja kryesore (Mainline)

Ngjashëm me trungun, por secila degë mund të ketë linjën e saj kryesore.

Bashkimi (Merge)

Një bashkim ose integrim është një proces ku dy grupe ndryshimesh aplikohen në një skedar ose në një grup skedarësh. Disa shembuj të mundshëm të këtij procesi janë si në vijim:

• Një përdorues, që punon në një grup skedarësh, përditëson ose sinkronizon kopjen e tij të punës me ndryshimet e bëra dhe të kontrolluara në depo nga përdorues të tjerë.
• Një përdorues përpiqet të kontrollojë skedarët që janë përditësuar nga të tjerët që kur skedarët janë kontrolluar dhe softueri i kontrollit të rishikimit bashkon automatikisht skedarët (zakonisht, pasi i kërkon përdoruesit nëse duhet të vazhdojë me bashkimin automatik, dhe në disa raste vetëm duke e bërë këtë nëse bashkimi mund të zgjidhet qartë dhe në mënyrë të arsyeshme).
• Krijohet një degë, kodi në skedarë redaktohet në mënyrë të pavarur dhe dega e përditësuar më vonë inkorporohet në një trunk të vetëm, të unifikuar.
• Një grup skedarësh është i degëzuar, një problem që ekzistonte përpara se degëzimi të rregullohej në njërën degë, dhe rregullimi më pas shkrihet në degën tjetër. (Ky lloj bashkimi selektiv nganjëherë njihet si një zgjedhje qershie për ta dalluar atë nga bashkimi i plotë në rastin e mëparshëm.)

Promovimi (Promote)

Promovimi definohet si akti i kopjimit të përmbajtjes së skedarit nga një vend më pak i kontrolluar në një vend më të kontrolluar. Për shembull, nga hapësira e punës e një përdoruesi në një depo, ose nga një ngarkesë te depoja kryesore.

Tërhiqe, shtyje (Pull, push)

Kopjimi i rishikimeve nga një depo në një tjetër. Tërheqja fillohet nga depoja që merr të dhënat, ndërsa shtytja niset nga depoja burimore. Përdorimi i termit "fetch" mund të nënkuptojë tërheqjen ose një tërheqje që pason me një përditësim.

Kërkesa për tërheqje (Pull request)

Artikulli kryesor: Baseline (configuration management)

Kontributet në një depo të kodit burimor që përdor një sistem të shpërndarë të kontrollit të versioneve zakonisht bëhen përmes një kërkese tërheqjeje (pull request), e njohur gjithashtu si kërkesë bashkimi (merge request). Kontributori kërkon që mirëmbajtësi i projektit të "tërheqë" ndryshimin e bërë në kodin burimor, prandaj dhe quhet "kërkesë tërheqjeje". Mirëmbajtësi duhet të bashkojë (merge) këtë kërkesë që kontributi të bëhet pjesë e bazës së kodit burimor. Zhvilluesi krijon një kërkesë tërheqjeje për të njoftuar mirëmbajtësit për një ndryshim të ri; secila kërkesë tërheqjeje ka një seksion komentesh të lidhur me të. Kjo mundëson diskutime të fokusuara mbi ndryshimet në kod. Kërkesat e paraqitura janë të dukshme për këdo që ka akses në depo. Një kërkesë tërheqjeje mund të pranohet ose të refuzohet nga mirëmbajtësit. Pasi kërkesa të rishikohet dhe të miratohet, ajo bashkohet me depon. Në varësi të rrjedhës së punës të përcaktuar, kodi mund të ketë nevojë të testohet përpara se të përfshihet në versionin zyrtar. Për këtë arsye, disa projekte kanë një degë të veçantë për të bashkuar kërkesat e tërheqjes që nuk janë testuar ende. Projekte të tjera përdorin një paketë testimi të automatizuar për çdo kërkesë tërheqjeje, duke përdorur një mjet të integrimit të vazhdueshëm (continuous integration), dhe rishikuesi sigurohet që kodi i ri të ketë mbulim të përshtatshëm testimi.

Depoja

Në sistemet e kontrollit të versioneve, një depo (repository) është një strukturë të dhënash që ruan metainformacion për një grup skedarësh ose një strukturë direktorie. Në varësi të faktit nëse sistemi i kontrollit të versioneve që përdoret është i shpërndarë, si Git ose Mercurial, apo i centralizuar, si Subversion, CVS ose Perforce, i gjithë grupi i informacionit në depo mund të dublikohet në sistemin e çdo përdoruesi ose mund të ruhet në një server të vetëm. Disa nga metainformacionet që një depo përmban përfshijnë, ndër të tjera: një regjistër historik të ndryshimeve në depo, një grup objektesh commit, dhe një grup referencash për këto objekte commit, të quajtura heads.

Resolve

Akti i ndërhyrjes së përdoruesit për të zgjidhur një konflikt mes ndryshimeve të bëra në të njëjtin dokument.

Integrimi i kundërt

Procesi i integrimit të degëve të ndryshme të ekipeve në trungun kryesor të sistemit të kontrollit të versionit.

Rishikimi dhe versioni

Një version është çdo ndryshim në formë. Në SVK, një Rishikim përfaqëson gjendjen e tërë pemës në depo në një moment të caktuar të kohës.

Shpërndarja

Akti i bërjes së një skedari ose dosjeje të disponueshme në disa degë në të njëjtën kohë. Kur një skedar i përbashkët ndryshohet në një degë, ai përditësohet gjithashtu në degë të tjera.

Stream

Një kontejner për skedarë të degëzuar që ka lidhje të njohura me kontejnerë të tjerë të ngjashëm. Rrjedhat e tij krijojnë një hierarki; çdo transmetim mund të trashëgojë karakteristika të ndryshme (siq janë versionet, hapësira e emrave, rregullat e rrjedhës së punës, abonentët, e të tjerë) nga transmetimi i tij prind.

Etiketë (Tag)

Një etiketë ose label i referohet një fotografie të caktuar në kohë, e cila mbetet e qëndrueshme për shumë skedarë. Këta skedarë në atë moment mund të etiketohen të gjithë me një emër ose numër rishikimi që ka kuptim dhe është i përshtatshëm. Shikoni vijat bazë, labels dhe etiketat .

Trungu

Trungu është linja kryesore e zhvillimit që nuk është një degë. (Ndonjëherë quhet edhe Baza, Linja kryesore ose edhe Master )

Përditësimi

Një përditësim (ose sinkronizim, megjithëse sinkronizimi mund të nënkuptojë gjithashtu një kombinim të shtytjes dhe tërheqjes) bashkon ndryshimet e bëra në depo (nga përdorues të tjerë, për shembull) me kopjen e punës lokale. Përditësimi është gjithashtu termi i përdorur nga disa mjete CM (CM+, PLS, SMS) për të përshkruar paketën e ndryshimeve (shih listën e ndryshimeve). Ky term është sinonim i arkës në sistemet e kontrollit të rishikimit që kërkojnë që çdo depo të ketë një kopje të saktë të punës (e zakonshme në sistemet e shpërndara).

Zhbllokimi

Lëshimi i një bllokimi.

Kopje pune

Kopja e punës është një kopje lokale e skedarëve nga një depo, e ruajtur në një moment apo rishikim të caktuar. Të gjitha ndryshimet që bëhen në skedarët e depoes fillimisht realizohen në një kopje pune, prandaj edhe emri i saj.. Konceptualisht, ajo mund të krahasohet me një sandbox .

Shihni gjithashtu

Artikulli kryesor: Merge (version control)

Linqe të jashtme

Faqja zyrtare (Anglisht )

Referencat

• "Visual Guide to Version Control", Better explained {{citation}}: Mungon ose është bosh parametri |language= (Ndihmë!).
• Sink, Eric, "Source Control", SCM (how-to) {{citation}}: Mungon ose është bosh parametri |language= (Ndihmë!). The basics of version control.

[[Kategoria:Faqe me adresa nga Wayback Machine që përdorin stampën e arkivës së rrjetit]]