Versionskontrolsystem (brugte også definitionen af "versionskontrolsystem [1] ", fra det engelske Version Control System, VCS eller Revision Control System ) - software til at lette arbejdet med at ændre information. Versionskontrolsystemet giver dig mulighed for at gemme flere versioner af det samme dokument, vende tilbage til tidligere versioner, hvis det er nødvendigt, bestemme, hvem der har foretaget en ændring og hvornår, og meget mere.
Sådanne systemer er mest udbredt i softwareudvikling til at gemme kildekoderne til det program, der udvikles. De kan dog også med succes anvendes på andre områder, hvor der arbejdes med en lang række løbende skiftende elektroniske dokumenter. Især versionskontrolsystemer bruges i CAD , normalt som en del af produktdatastyringssystemer ( PDM ). Versionering bruges i Software Configuration Management Tools .
Wikipedia -softwaren opretholder en revisionshistorik for alle sine artikler ved hjælp af metoder, der ligner dem, der bruges i versionskontrolsystemer.
Den situation, hvor et elektronisk dokument undergår en række ændringer under sin eksistens, er ret typisk. I dette tilfælde er det ofte vigtigt at have ikke kun den nyeste version, men også flere tidligere. I det enkleste tilfælde kan du blot gemme flere versioner af dokumentet og nummerere dem i overensstemmelse hermed. Denne metode er ineffektiv (du skal gemme flere næsten identiske kopier), kræver øget opmærksomhed og disciplin og fører ofte til fejl, så der er udviklet værktøjer til at automatisere dette arbejde.
Traditionelle versionskontrolsystemer bruger en centraliseret model, hvor der er et enkelt dokumentlager, der administreres af en speciel server , der udfører de fleste versionskontrolfunktioner. En bruger, der arbejder med dokumenter, skal først hente den version af dokumentet, de har brug for, fra lageret; normalt oprettes en lokal kopi af dokumentet, den såkaldte "arbejdskopi". Den seneste version kan fås, eller en hvilken som helst af de tidligere, som kan vælges efter versionsnummer eller oprettelsesdato, nogle gange efter andre kriterier. Efter at de ønskede ændringer er foretaget i dokumentet, placeres den nye version i depotet. I modsætning til blot at gemme en fil, slettes den tidligere version ikke, men forbliver også i depotet og kan hentes derfra til enhver tid. Serveren kan bruge den såkaldte. Delta-komprimering er en måde at gemme dokumenter på, som kun gemmer ændringer mellem successive versioner, hvilket reducerer mængden af lagrede data. Da den seneste version af en fil normalt er den mest efterspurgte, kan systemet gemme hele filen, når der gemmes en ny version, og erstatte den sidst tidligere gemte version i repository med forskellen mellem denne og den seneste version. Nogle systemer (f.eks. ClearCase ) understøtter lagring af versioner af begge typer: de fleste versioner gemmes som deltaer, men med jævne mellemrum (ved speciel administratorkommando) gemmes alle filer i fulde versioner; denne tilgang sikrer den mest fuldstændige gendannelse af historien i tilfælde af skade på depotet .
Nogle gange udføres oprettelsen af en ny version umærkeligt for brugeren (gennemsigtigt), enten af et applikationsprogram, der har indbygget understøttelse af en sådan funktion, eller ved at bruge et specielt filsystem . I dette tilfælde arbejder brugeren blot med filen som normalt, og når filen er gemt, oprettes der automatisk en ny version.
Det sker ofte, at flere personer arbejder på det samme projekt på samme tid. Hvis to personer ændrer den samme fil , kan en af dem ved et uheld fortryde de ændringer, den anden har foretaget. Versionskontrolsystemer holder styr på sådanne konflikter og tilbyder værktøjer til at løse dem. De fleste systemer kan automatisk flette (flette) ændringer foretaget af forskellige udviklere. En sådan automatisk sammenlægning af ændringer er dog normalt kun mulig for tekstfiler og forudsat at forskellige (ikke-overlappende) dele af denne fil er blevet ændret. Denne begrænsning skyldes det faktum, at de fleste versionskontrolsystemer er fokuseret på at understøtte softwareudviklingsprocessen, og programkildekoder er gemt i tekstfiler. Hvis den automatiske fletning mislykkes, kan systemet tilbyde at løse problemet manuelt.
Det er ofte umuligt at flette hverken automatisk eller manuelt, for eksempel hvis filformatet er ukendt eller for komplekst. Nogle versionskontrolsystemer giver dig mulighed for at låse en fil i boksen. Låsen forhindrer andre brugere i at få en arbejdskopi eller forhindrer, at arbejdskopien af en fil bliver ændret (f.eks. ved hjælp af filsystemet) og giver dermed eksklusiv adgang til kun den bruger, der arbejder med dokumentet.
Mange versionskontrolsystemer har en række andre funktioner:
Hvert versionskontrolsystem har sine egne specifikke funktioner med hensyn til kommandosæt, brugeradfærd og administration. Imidlertid er den generelle betjeningsprocedure for de fleste VCS'er fuldstændig stereotyp. Det antages her, at projektet, hvad end det måtte være, allerede eksisterer, og dets repository er hostet på serveren , som udvikleren får adgang til.
Den første handling, som en udvikler skal udføre, er at tjekke en arbejdskopi af projektet eller den del af det, der skal arbejdes på. Denne handling udføres ved hjælp af version checkout-kommandoen (normalt checkout eller clone ). Udvikleren angiver den version, der skal kopieres, som standard kopieres den seneste (eller administratorens valg som hoved) version normalt.
Udtrækningskommandoen etablerer en forbindelse til serveren, og projektet (eller en del af det - en af mapperne med undermapper) kopieres til udviklerens computer i form af et træ af mapper og filer. En almindelig praksis er at duplikere arbejdskopien: ud over hovedbiblioteket med projektet skrives en anden kopi af den yderligere til den lokale disk (enten til en separat, specielt udvalgt mappe eller til hovedprojektets systemundermapper træ). Mens han arbejder på et projekt, ændrer udvikleren kun filerne i hovedarbejdskopien. Den anden lokale kopi gemmes som en reference, hvilket giver dig mulighed for til enhver tid, uden at kontakte serveren, hvilke ændringer der er foretaget i en bestemt fil eller et bestemt projekt som helhed, og fra hvilken version arbejdskopien blev "opstået"; som regel resulterer ethvert forsøg på manuelt at ændre denne kopi i fejl i driften af VCS-softwaren.
Med nogle variationer, bestemt af funktionerne i systemet og detaljerne i den vedtagne teknologiske proces, er den sædvanlige cyklus af udviklerens arbejde i løbet af arbejdsdagen som følger.
Opdatering af en arbejdskopi Efterhånden som der foretages ændringer i hovedversionen af projektet, bliver arbejdskopien på udviklerens computer ældre: dens uoverensstemmelse med hovedversionen af projektet øges. Dette øger risikoen for modstridende ændringer (se nedenfor ). Derfor er det praktisk at holde arbejdskopien i en tilstand så tæt som muligt på den aktuelle hovedversion, for hvilken udvikleren udfører opdateringsoperationen af arbejdskopien ( opdatering ) så ofte som muligt (den faktiske hyppighed af opdateringer bestemmes efter hyppigheden af ændringer, afhængigt af udviklingsaktiviteten og antallet af udviklere, samt den tid, der bruges på hver opdatering - hvis den er stor, er udvikleren tvunget til at begrænse hyppigheden af opdateringer for ikke at spilde tid) . Projektændring Udvikleren ændrer projektet ved at ændre de filer, der er inkluderet i det i arbejdskopien i overensstemmelse med projektopgaven. Dette arbejde udføres lokalt og kræver ikke opkald til VCS-serveren. Forpligte ændringer Efter at have afsluttet næste fase af arbejdet med opgaven, forpligter udvikleren ( forpligter ) sine ændringer, overfører dem til serveren (enten til hovedgrenen, hvis arbejdet med opgaven er fuldstændig fuldført, eller til en separat udviklingsgren af denne opgave ). VCS kan kræve, at udvikleren opdaterer arbejdskopien, før den forpligter sig. Hvis systemet understøtter udskudte ændringer ( reoler ), kan ændringer overføres til serveren uden at forpligte sig. Hvis den godkendte arbejdspolitik i VCS tillader det, kan fastsættelse af ændringer ikke udføres dagligt, men kun efter afslutningen af arbejdet med opgaven; i dette tilfælde gemmes alle ændringer forbundet med opgaven kun i den lokale arbejdskopi af udvikleren, indtil arbejdet er afsluttet.Du kan lave mindre rettelser i projektet ved direkte at redigere arbejdskopien og derefter overføre ændringerne direkte til hovedgrenen (i stammen) på serveren. Men når der udføres stort arbejde, bliver denne ordre ubelejlig: manglen på at rette mellemliggende ændringer på serveren tillader ikke at arbejde på noget i en gruppetilstand, desuden øges risikoen for at miste ændringer under lokale ulykker, og evnen til at analysere og vende tilbage til tidligere versioner af koden inden for et givet værk. Derfor er det almindelig praksis for sådanne ændringer at oprette grene ( filial ), det vil sige "forgrening" fra stammen i en eller anden version af en ny version af projektet eller en del af det, hvis udvikling udføres parallelt med ændringer i hovedversionen. Grenen oprettes af en speciel kommando. Arbejdskopien af en filial kan genskabes på den sædvanlige måde (med kommandoen check out working copy, specificering af adressen eller filial-ID), eller ved at skifte en eksisterende arbejdskopi til en given filial.
Den grundlæggende arbejdscyklus ved brug af filialer forbliver nøjagtig den samme som i det generelle tilfælde: udvikleren opdaterer med jævne mellemrum arbejdskopien (hvis mere end én person arbejder på filialen) og forpligter deres daglige arbejde til det. Nogle gange forbliver en udviklingsgren alene (når ændringer genererer en ny version af projektet, som så udvikler sig adskilt fra den primære), men oftere, når det arbejde, som filialen blev oprettet til er udført, genintegreres grenen i stammen (hovedgrenen). Dette kan gøres med en merge-kommando (normalt merge ), eller ved at oprette en patch ( patch ), der indeholder de ændringer, der er foretaget under grenudvikling, og anvende denne patch til den aktuelle hovedversion af projektet.
Tre typer operationer udført i kildekontrol kan resultere i behovet for at flette ændringer. Det:
I alle tilfælde er situationen grundlæggende den samme og har følgende karakteristiske træk:
Det er helt indlysende, at hvis betingelse (2) ikke er opfyldt (det vil sige, hvis der kun blev foretaget ændringer i originalen eller kun til en kopi), er sammenlægningen elementær - det er nok at kopiere den ændrede del til, hvor der ikke var nogen ændringer. Ellers bliver fletning af ændringer til en ikke-triviel opgave, der i mange tilfælde kræver indgriben fra udvikleren. Generelt fungerer mekanismen til automatisk sammenlægning af ændringer baseret på følgende principper:
I alle tilfælde er basisversionen for fletningen den version, hvor opdelingen af de flettede versioner blev foretaget. Hvis dette er en commit-operation, så vil basisversionen være versionen af den sidste opdatering før commit, hvis opdateringen, så versionen af den forrige opdatering, hvis du fusionerer brancher, så den version, hvor den tilsvarende gren blev oprettet. Følgelig vil de matchede ændringssæt være de ændringssæt, der er foretaget fra basis til den aktuelle version i alle flettede varianter.
Langt de fleste moderne versionskontrolsystemer er primært fokuseret på softwareudviklingsprojekter, hvor hovedtypen af filindhold er tekst. Følgelig er mekanismerne til automatisk fletning af ændringer orienteret mod behandlingen af tekstfiler, det vil sige filer, der indeholder tekst bestående af strenge af alfanumeriske tegn, mellemrum og tabulatorer, adskilt af nye linjer .
Når det skal afgøres, om det er tilladt at flette ændringer inden for den samme tekstfil, fungerer en typisk linje-for-linje-tekstsammenligningsmekanisme (et eksempel på dens implementering er GNU diff-systemværktøjet), som sammenligner de flettede versioner med basisversionen og bygger en liste over ændringer, det vil sige tilføjede, slettede og erstattede sæt af linjer . Minimumsenheden af data for denne algoritme er en streng, selv den mindste forskel gør strengene forskellige. Da separatortegn i de fleste tilfælde ikke bærer en semantisk belastning, kan flettemotoren ignorere disse tegn, når strenge sammenlignes.
De fundne sæt af ændrede strenge, der ikke krydser hinanden, betragtes som kompatible, og deres sammenfletning sker automatisk. Hvis der er ændringer i de flettede filer, der påvirker den samme linje i filen, fører dette til en konflikt. Sådanne filer kan kun flettes manuelt. Alle andre filer end tekstfiler er binære set fra VCS's synspunkt og tillader ikke automatisk sammenfletning.
Den situation, hvor de ændringer, der er foretaget i dem, krydser hinanden, når flere versioner slås sammen, kaldes en konflikt . Hvis der er en konflikt mellem ændringer, kan versionskontrolsystemet ikke automatisk oprette et fusioneret projekt og skal kontakte udvikleren. Som nævnt ovenfor kan der opstå konflikter i stadierne af begå ændringer, opdatering eller sammenlægning af filialer. I alle tilfælde, når en konflikt opdages, afsluttes den tilsvarende handling, indtil den er løst.
For at løse en konflikt tilbyder systemet generelt udvikleren tre muligheder for modstridende filer: base, lokal og server. Modstridende ændringer vises enten til udvikleren i et specielt programmodul til fletning af ændringer (i dette tilfælde vises de flettede muligheder og den flettede version af filen, der dynamisk ændrer sig afhængigt af brugerens kommandoer), eller de er blot markeret med speciel markup direkte i teksten i den flettede fil (så skal udvikleren selv danne den ønskede tekst på omstridte steder og beholde den).
Konflikter i filsystemet er nemmere at løse: kun sletning af en fil kan være i konflikt med en af de andre operationer, og rækkefølgen af filerne i mappen er ligegyldig, så udvikleren kan kun vælge, hvilken handling der skal beholdes i den flettede version .
Låsemekanismen giver en af udviklerne mulighed for at tage ejerskab af en fil eller gruppe af filer for at foretage ændringer i dem. Mens filen er låst, forbliver den skrivebeskyttet for alle andre udviklere, og ethvert forsøg på at foretage ændringer i den afvises af serveren. Teknisk set kan blokering organiseres på forskellige måder. Følgende mekanisme er typisk for moderne systemer.
Den massive brug af låse, når alle eller de fleste af filerne i et projekt er låsbare, og eventuelle ændringer kræver, at det tilsvarende sæt filer er låst, kaldes også "locked checkout"-strategien. [3] Tidlige versionskontrolsystemer understøttede udelukkende denne strategi, hvilket forhindrede konflikter i at opstå i opløbet. I moderne VCS foretrækkes brugen af ikke-blokerende hentning, mens låse snarere betragtes som et nødvendigt onde, der bør begrænses så meget som muligt. Ulemperne ved at bruge låse er indlysende:
På den anden side er brugen af låse i nogle tilfælde ganske berettiget. Et oplagt eksempel er organiseringen af arbejdet med binære filer, hvor der ikke er værktøjer til at flette ændringer eller en sådan sammenlægning er fundamentalt umulig (som f.eks. for billedfiler). Hvis automatisk sammenfletning ikke er mulig, vil enhver parallel ændring af sådanne filer i det normale arbejde føre til en konflikt. I dette tilfælde er det meget mere praktisk at gøre en sådan fil låsbar for at sikre, at eventuelle ændringer af den kun vil blive foretaget sekventielt.
Versionsstyringssystemet giver lagring af alle eksisterende varianter af filer og som følge heraf alle varianter af projektet som helhed, der har fundet sted siden begyndelsen af dets udvikling. Men selve begrebet "version" i forskellige systemer kan fortolkes på to måder.
Nogle systemer understøtter versionering af . Det betyder, at enhver fil, der vises i projektet, modtager sit eget versionsnummer (normalt nummer 1, den betingede "nul" version af filen er en tom fil med samme navn). Hver gang en udvikler foretager ændringer, der påvirker en fil, anvendes den passende del af de forpligtede ændringer til filen, og filen får et nyt, normalt næste i rækkefølge, versionsnummer. Da commits normalt kun påvirker en delmængde af filerne i depotet, afviger versionsnumre af filer, der er tilgængelige på samme tidspunkt, over tid, og projektet som helhed (det vil sige hele sættet af filer i depotet) gør det ikke faktisk have et hvilket som helst "versionsnummer", fordi det består af mange filer med forskellige versionsnumre. CVS-versionskontrolsystemet fungerer for eksempel på lignende måde.
For andre systemer refererer begrebet "version" ikke til en enkelt fil, men til hele depotet . Et nyoprettet tomt lager har en version på 1 eller 0, enhver commit får dette tal til at stige (det vil sige, selvom en fil ændres med en byte, betragtes hele depotet som ændret og modtager et nyt versionsnummer). Versionsnumre behandles på denne måde, for eksempel af Subversion-systemet. Versionsnummeret for en separat fil eksisterer faktisk ikke her, det kan betinget betragtes som sådan det aktuelle versionsnummer for depotet (det vil sige, det kan antages, at med hver ændring, der foretages i depotet, ændrer alle dets filer versionen nummer, også dem, der ikke er ændret). Nogle gange, når vi taler om "filversionen" i sådanne systemer, betyder de den version af lageret, hvor filen sidst blev ændret (indtil det øjeblik, vi er interesserede i).
Af praktiske årsager er det normalt ikke en enkelt fil, der betyder noget, men hele projektet som helhed. I systemer, der understøtter versionering af individuelle filer, kan du bruge dato og klokkeslæt til at identificere en specifik version af projektet - så vil projektversionen bestå af de versioner af filerne, der er inkluderet i det, som var i depotet på det angivne tidspunkt i tid. Hvis versioneringen af depotet som helhed er understøttet, kan projektets versionsnummer være versionsnummeret på depotet. Begge muligheder er dog ikke særlig bekvemme, da hverken datoen eller versionsnummeret på depotet normalt indeholder oplysninger om væsentlige ændringer i projektet, om hvor længe og intensivt de arbejdede på det. For mere bekvemt at tagge versioner af et projekt (eller dele af det), understøtter versionskontrolsystemer konceptet med tags .
Et tag er en symbolsk etiket, der kan knyttes til en bestemt version af en fil og/eller et bibliotek i et lager. Ved at bruge den passende kommando kan alle eller en del af projektfilerne, der opfylder visse betingelser (f.eks. inkluderet i hovedversionen af projektets hovedgren på et bestemt tidspunkt) tildeles en given etiket. På denne måde kan du identificere versionen af projektet (version "XX.XXX.XXX" er et sæt versioner af repository-filer med tagget "XX.XXX.XXX"), og dermed rette dens tilstand på et ønsket tidspunkt. Som regel er tagging-systemet ret fleksibelt og giver dig mulighed for at tagge ikke-samtidige versioner af filer og mapper med ét tag. Dette giver dig mulighed for at bygge en "version af projektet" på enhver vilkårlig måde. Fra systemets brugers synspunkt kan tagging se anderledes ud. I nogle systemer vises det nøjagtigt som et mærke (et tag kan oprettes, anvendes på visse versioner af filer og mapper, fjernes). I andre systemer (for eksempel Subversion) er tagget simpelthen en separat mappe på depotfiltræet, hvor kopier af de nødvendige versioner af filer laves fra stammen og grene af projektet ved hjælp af kopieringskommandoen. Så visuelt er et tag blot en kopi af visse versioner af depotfilerne placeret i en separat mappe. Ifølge konventionen må bibliotekstræet, der svarer til tagget, ikke foretage ændringer (det vil sige, at den version af projektet, der repræsenteres af tagget, er uændret).
Proceduren for brug af versionskontrolsystemet i hvert enkelt tilfælde er bestemt af de tekniske forskrifter og regler, der er vedtaget i en bestemt virksomhed eller organisation, der udvikler projektet. De generelle principper for korrekt brug af VCS er dog få og de samme for alle udviklings- og versionskontrolsystemer.
Også kendt som Distributed Version Control System , DVCS. Sådanne systemer bruger en distribueret model i stedet for den traditionelle klient-server-model. Generelt har de ikke brug for et centraliseret lager: hele historikken for dokumentændringer gemmes på hver computer i lokal lagring, og om nødvendigt synkroniseres individuelle fragmenter af den lokale lagringshistorik med en lignende lagring på en anden computer. I nogle af disse systemer ligger lokal lagring direkte i mapperne med arbejdskopi.
Når en bruger af et sådant system udfører normale handlinger, såsom at tjekke en specifik version af et dokument ud, oprette en ny version og så videre, arbejder han med sin lokale kopi af depotet. Efterhånden som der foretages ændringer, begynder depoter, der tilhører forskellige udviklere, at adskille sig, og det bliver nødvendigt at synkronisere dem. En sådan synkronisering kan udføres ved at udveksle patches eller såkaldte ændringssæt mellem brugere .
Den beskrevne model er logisk tæt på at skabe en separat gren for hver udvikler i det klassiske versionskontrolsystem (i nogle distribuerede systemer skal du oprette en ny gren, før du arbejder med lokal lagring). Forskellen er, at indtil tidspunktet for synkronisering kan andre udviklere af denne gren ikke se. Så længe bygherren kun ændrer sin egen gren, påvirker hans arbejde ikke andre projektdeltagere og omvendt. Efter afslutning af en særskilt del af arbejdet sammenlægges ændringerne i grenene med hovedgrenen (fælles). Både ved sammenlægning af grene og ved synkronisering af forskellige repositories er versionskonflikter mulige. I dette tilfælde giver alle systemer en eller anden metode til at detektere og løse flettekonflikter.
Fra brugerens synspunkt er et distribueret system kendetegnet ved behovet for at oprette et lokalt lager og tilstedeværelsen af to yderligere kommandoer på kommandosproget: kommandoen til at modtage et lager fra en fjerncomputer (pull) og overføre dets lager til en fjerncomputer (push). Den første kommando fletter ændringerne fra de eksterne og lokale arkiver og skubber resultatet til det lokale arkiv; den anden, tværtimod, slår ændringerne af de to depoter sammen med resultatet placeret i et fjernlager. Som regel giver flettekommandoer i distribuerede systemer dig mulighed for at vælge, hvilke ændringssæt der skal overføres til eller trækkes fra et andet lager, rette flettekonflikter direkte under operationen eller efter at den mislykkes, prøve igen eller genoptage en ufærdig fletning. Normalt lykkes det kun at skubbe dine ændringer til en andens lager (push), hvis der ikke er nogen konflikter. Hvis der opstår konflikter, skal brugeren først flette versionerne i sit lager (udføre et pull), og først derefter overføre dem til andre.
Det anbefales generelt at organisere arbejdet med systemet på en sådan måde, at brugere altid eller overvejende flettes ind i deres eget lager. Det vil sige, i modsætning til centraliserede systemer, hvor brugere overfører deres ændringer til en central server, når de finder det passende, i distribuerede systemer, er det mere naturligt at flette versioner af den, der skal have dets resultat (f.eks. en udvikler, der administrerer en build server).
De vigtigste fordele ved distribuerede systemer er deres fleksibilitet og meget større (sammenlignet med centraliserede systemer) autonomi på en individuel arbejdsplads. Hver udviklers computer er i virkeligheden en uafhængig og fuldt udstyret server, fra sådanne computere er det muligt at bygge et vilkårligt system i struktur og kompleksitet, der indstiller (både tekniske og administrative foranstaltninger) den ønskede synkroniseringsrækkefølge. Samtidig kan hver udvikler arbejde uafhængigt, på en måde, der er praktisk for ham, ændre og gemme mellemliggende versioner af dokumenter ved at bruge alle funktionerne i systemet (inklusive adgang til ændringshistorikken), selv i mangel af en netværksforbindelse til serveren. Kommunikation med serveren eller andre udviklere kræves udelukkende for synkronisering, mens udvekslingen af sæt ændringer kan udføres i henhold til forskellige skemaer.
Ulemperne ved distribuerede systemer omfatter en stigning i den nødvendige mængde diskhukommelse: hver computer skal gemme en komplet versionshistorik, mens der i et centraliseret system normalt kun er en arbejdskopi gemt på udviklerens computer, det vil sige et udsnit af depotet på et tidspunkt og de ændringer, der er foretaget. En mindre åbenlys, men irriterende ulempe er, at det er næsten umuligt at implementere noget af den funktionalitet, som centraliserede systemer leverer i et distribueret system. Det:
Vi kan skelne mellem følgende typiske situationer, hvor brugen af et distribueret system giver mærkbare fordele:
I traditionel "kontor" projektudvikling, når en gruppe af udviklere er relativt lille og helt placeret på samme område, inden for et enkelt lokalt computernetværk, med servere konstant tilgængelige, kan et centraliseret system være det bedste valg på grund af dets mere stive struktur og tilstedeværelsen af funktionalitet, der mangler i distribuerede systemer (for eksempel den allerede nævnte lås). Muligheden for at foretage ændringer uden at flette dem ind i den centrale filial under sådanne forhold implementeres let ved at opdele igangværende arbejde i separate udviklingsgrene.
Der er ingen almindeligt accepteret terminologi; forskellige systemer kan bruge forskellige navne til de samme handlinger. Nedenfor er nogle af de mest brugte muligheder. Engelske termer er givet, i litteratur på russisk bruges en eller anden oversættelse eller translitteration .
ændre Foretag ændringer uden at oprette en ny version - normalt når udvikleren ved en fejl har begået ( commit ) versionen, men ikke uploadede ( push ) den til serveren. bebrejde Find ud af, hvem der har foretaget ændringen. afdeling En gren er en udviklingsretning uafhængig af andre. En filial er en kopi af en del (normalt én mappe) af depotet, hvor du kan foretage dine egne ændringer uden at påvirke andre filialer. Dokumenter i forskellige afdelinger har den samme historie før forgreningspunktet og forskellig historie efter det. ændringssæt, ændringsliste, aktivitet Sæt af ændringer. Repræsenterer et navngivet sæt redigeringer, der er lavet til en lokal kopi til et fælles formål. På systemer, der understøtter ændringssæt, kan udvikleren organisere lokale ændringer i grupper og foretage logisk relaterede ændringer i én kommando, og angive det nødvendige ændringssæt som en parameter. I dette tilfælde forbliver andre redigeringer ubetinget. Et typisk eksempel: arbejdet er i gang med at tilføje ny funktionalitet, og i det øjeblik opdages en kritisk fejl, som skal rettes med det samme. Udvikleren opretter et sæt ændringer til det allerede udførte arbejde og et nyt til rettelser. Efter fuldførelse af rettelsen af fejlen, gives kommandoen til kun at udføre det andet sæt redigeringer. check-in, begå, indsende Opret en ny version, forpligt ændringer. I nogle SUV'er ( Subversion ) - overføres den nye version automatisk til dokumentlageret. check-out, klon Hent et dokument fra lageret og opret en arbejdskopi. konflikt En konflikt er en situation, hvor flere brugere har foretaget ændringer i den samme del af et dokument. En konflikt detekteres, når en bruger har foretaget sine ændringer, og den anden forsøger at forpligte sig, og systemet selv kan ikke flette de modstridende ændringer korrekt. Da programmet måske ikke er smart nok til at afgøre, hvilken ændring der er "korrekt", skal den anden bruger selv løse konflikten ( resolve ). graft, backport, cherry-pick, transplantation Brug den indbyggede flettealgoritme i VMS til at skubbe individuelle ændringer til en anden gren uden at flette dem. For eksempel har vi rettet en fejl i forsøgsgrenen - vi foretager de samme ændringer i den stabile stamme. hoved, bagagerum Hovedversionen er den seneste version for grenen/stammen, der er i depotet. Hvor mange grene, så mange større versioner. sammensmelte, integration En fletning er en kombination af uafhængige ændringer til en enkelt version af et dokument. Er sket, når to personer har ændret den samme fil, eller når ændringer flyttes fra en gren til en anden. trække, opdatere Hent nye versioner fra depotet. I nogle SUV'er ( Subversion ) - forekommer både pull og switch , det vil sige ændringer indlæses, og derefter bringes arbejdskopien til den sidste tilstand. Vær forsigtig , opdatering er tvetydig og betyder forskellige ting i Subversion og Mercurial . skubbe Upload nye versioner til depotet. Mange distribuerede VCS'er ( Git , Mercurial ) antager, at der skal gives en commit , hver gang programmøren har udført en eller anden fuldført funktion. Og udfyld - når der er internet og andre ønsker dine ændringer. Commit kræver normalt ikke et brugernavn og adgangskode, men push gør det. rebase Brug den indbyggede flettealgoritme i VMS til at flytte forgreningspunktet (den version, hvorfra forgreningen starter) til en senere version af stammen. Oftest brugt i dette scenarie: Boris har lavet ændringer og finder ud af, at han ikke kan skubbe dem, fordi Anna tidligere har ændret et helt andet sted i koden. Du kan blot flette dem ( flette ). Men træet vil være lineært og mere læsbart, hvis du opgiver din revision, men foretager de samme ændringer i Annas revision - dette er rebase . Hvis Anna og Boris arbejder på det samme stykke kode, forstyrrer hinanden og løser konflikter manuelt, anbefales rebase ikke. depot, depot Dokumentlageret er det sted, hvor versionskontrolsystemet gemmer alle dokumenter sammen med deres ændringshistorik og andre serviceoplysninger. revision Dokumentversion. Versionskontrolsystemer skelner versioner ved numre, som tildeles automatisk. hylde, stash Udsættelse af ændringer. Muligheden fra nogle systemer til at oprette et ændringssæt (changeset) og gemme det på serveren uden at forpligte sig (commit'a). Et backlog-ændringssæt kan læses af andre projektmedlemmer, men inkluderes ikke i hovedgrenen før en speciel kommando. Udsættelse af support giver brugerne mulighed for at gemme igangværende arbejde på serveren uden at oprette separate filialer til dette. squash Pode/kirsebær-pluk- tilstand for hele grenen. Med andre ord er hele grenen forpligtet som én ændring. Nyttigt til ændringer, der er store nok til at tage flere dage at gennemføre, og små nok til ikke at have en fuldstændig historik over dem. scene Vælg hvilke ændringer der skal foretages ( commit ), og hvilke der skal holdes private eller foretages senere. strimmel Slet en hel gren fra lageret. tag, etiket En etiket, der kan tildeles en bestemt version af et dokument. En etiket er et symbolsk navn for en gruppe dokumenter, og etiketten beskriver ikke kun et sæt filnavne, men også versionen af hver fil. De versioner af dokumenterne, der er inkluderet på etiketten, kan tilhøre forskellige tidspunkter. stamme, hovedlinje, mester Stammen er hovedgrenen af projektudviklingen. Trunkpolitikken kan være forskellig fra projekt til projekt, men generelt er det som følger: De fleste ændringer er lavet på stammen; hvis der kræves en større ændring, der kan føre til ustabilitet, skabes en gren , der går sammen med stammen, når innovationen er tilstrækkeligt afprøvet; inden udgivelsen af næste version oprettes en gren til den efterfølgende udgivelse, hvor der kun foretages rettelser. opdatere, synkronisere, skifte Synkronisering af arbejdskopien til en bestemt lagringstilstand. Oftest betyder denne handling at opdatere arbejdskopien til den seneste vault-tilstand. Om nødvendigt kan du dog synkronisere arbejdskopien til en ældre tilstand end den nuværende. arbejdskopi Arbejds (lokal) kopi af dokumenter.| Versionskontrolsystemer ( kategori ) | |
|---|---|
| Kun lokalt | |
| Klient-server | |
| Uddelt | |