Versionskontrollsystem (använde även definitionen av "versionskontrollsystem [1] ", från engelska versionskontrollsystemet, VCS eller Revision Control System ) - programvara för att underlätta arbetet med att ändra information. Versionskontrollsystemet låter dig lagra flera versioner av samma dokument, återgå till tidigare versioner vid behov, bestämma vem som gjorde en ändring och när och mycket mer.
Sådana system används mest i mjukvaruutveckling för att lagra källkoderna för programmet som utvecklas. De kan dock framgångsrikt tillämpas även inom andra områden där det arbetas med ett stort antal kontinuerligt föränderliga elektroniska dokument. I synnerhet används versionskontrollsystem i CAD , vanligtvis som en del av produktdatahanteringssystem ( PDM ). Versionering används i Software Configuration Management Tools .
Wikipedia -programvaran har en revisionshistorik för alla sina artiklar med metoder som liknar de som används i versionskontrollsystem.
Situationen där ett elektroniskt dokument genomgår ett antal förändringar under sin existens är ganska typiskt. I det här fallet är det ofta viktigt att inte bara ha den senaste versionen, utan även flera tidigare. I det enklaste fallet kan du helt enkelt lagra flera versioner av dokumentet, numrera dem därefter. Denna metod är ineffektiv (du måste lagra flera nästan identiska kopior), kräver ökad uppmärksamhet och disciplin och leder ofta till fel, så verktyg har utvecklats för att automatisera detta arbete.
Traditionella versionskontrollsystem använder en centraliserad modell där det finns ett enda dokumentlager som hanteras av en speciell server som utför de flesta versionskontrollfunktionerna. En användare som arbetar med dokument måste först skaffa den version av dokumentet de behöver från arkivet; vanligtvis skapas en lokal kopia av dokumentet, den så kallade "arbetskopian". Den senaste versionen kan erhållas, eller någon av de tidigare, som kan väljas efter versionsnummer eller datum för skapandet, ibland av andra kriterier. Efter att de önskade ändringarna har gjorts i dokumentet placeras den nya versionen i arkivet. Till skillnad från att bara spara en fil, raderas inte den tidigare versionen, utan finns också kvar i förvaret och kan hämtas därifrån när som helst. Servern kan använda den sk. Delta-komprimering är ett sätt att lagra dokument som endast sparar ändringar mellan på varandra följande versioner, vilket minskar mängden lagrad data. Eftersom den senaste versionen av en fil vanligtvis är den mest efterfrågade kan systemet spara hela filen när en ny version sparas, och ersätta den senast tidigare sparade versionen i arkivet med skillnaden mellan denna och den senaste versionen. Vissa system (till exempel ClearCase ) stöder att spara versioner av båda typerna: de flesta versioner sparas som delta, men med jämna mellanrum (genom ett speciellt administratörskommando) sparas alla filer i fullständiga versioner; detta tillvägagångssätt säkerställer den mest fullständiga återställningen av historien i händelse av skada på förvaret .
Ibland utförs skapandet av en ny version omärkligt för användaren (transparent), antingen av ett applikationsprogram som har inbyggt stöd för en sådan funktion, eller genom att använda ett speciellt filsystem . I det här fallet arbetar användaren helt enkelt med filen som vanligt, och när filen sparas skapas automatiskt en ny version.
Det händer ofta att flera personer arbetar med samma projekt samtidigt. Om två personer ändrar samma fil kan en av dem av misstag ångra ändringarna som gjorts av den andre. Versionskontrollsystem håller reda på sådana konflikter och erbjuder verktyg för att lösa dem. De flesta system kan automatiskt slå samman (sammanfoga) ändringar gjorda av olika utvecklare. Sådan automatisk sammanslagning av ändringar är dock vanligtvis endast möjlig för textfiler och förutsatt att olika (icke-överlappande) delar av denna fil har ändrats. Denna begränsning beror på det faktum att de flesta versionskontrollsystem är inriktade på att stödja mjukvaruutvecklingsprocessen, och programkällkoder lagras i textfiler. Om automatisk sammanslagning misslyckas kan systemet erbjuda sig att lösa problemet manuellt.
Det är ofta omöjligt att slå samman antingen automatiskt eller manuellt, till exempel om filformatet är okänt eller för komplext. Vissa versionskontrollsystem ger dig möjlighet att låsa en fil i valvet. Låset hindrar andra användare från att erhålla en arbetskopia eller förhindrar att arbetskopian av en fil ändras (till exempel med hjälp av filsystemet) och ger därmed exklusiv åtkomst endast till den användare som arbetar med dokumentet.
Många versionskontrollsystem har ett antal andra funktioner:
Varje versionskontrollsystem har sina egna specifika funktioner när det gäller kommandouppsättning, användarbeteende och administration. Den allmänna operationsproceduren för de flesta VCS:er är dock helt stereotyp. Det antas här att projektet, vad det än kan vara, redan existerar och att dess arkiv ligger på servern , som utvecklaren får tillgång till.
Den första åtgärden som en utvecklare måste utföra är att kolla in en arbetskopia av projektet eller den del av det som ska bearbetas. Den här åtgärden utförs med kommandot version checkout (vanligtvis checkout eller clone ). Utvecklaren anger vilken version som ska kopieras, som standard kopieras vanligtvis den senaste (eller administratörens val som huvudversion).
Extraktionskommandot upprättar en anslutning till servern, och projektet (eller en del av det - en av katalogerna med underkataloger) kopieras till utvecklarens dator i form av ett träd med kataloger och filer. En vanlig praxis är att duplicera arbetskopian: förutom huvudkatalogen med projektet skrivs ytterligare en kopia av den till den lokala disken (antingen till en separat, speciellt utvald katalog eller till systemunderkatalogerna för huvudprojektet träd). När utvecklaren arbetar med ett projekt ändrar bara filerna i huvudarbetskopian. Den andra lokala kopian lagras som en referens, så att du när som helst, utan att kontakta servern, kan avgöra vilka ändringar som har gjorts i en viss fil eller ett visst projekt som helhet och från vilken version arbetskopian "uppstod"; som regel resulterar varje försök att manuellt modifiera denna kopia i fel i driften av VCS-mjukvaran.
Med vissa variationer, bestämt av funktionerna i systemet och detaljerna i den antagna tekniska processen, är den vanliga cykeln för utvecklarens arbete under arbetsdagen som följer.
Uppdaterar en arbetskopia När ändringar görs i huvudversionen av projektet, blir arbetskopian på utvecklarens dator äldre: dess avvikelse med huvudversionen av projektet ökar. Detta ökar risken för motstridiga förändringar (se nedan ). Därför är det bekvämt att hålla arbetskopian i ett tillstånd så nära den aktuella huvudversionen som möjligt, för vilken utvecklaren utför uppdateringsoperationen för arbetskopian ( uppdatering ) så ofta som möjligt (den faktiska uppdateringsfrekvensen bestäms av frekvensen av ändringar, beroende på utvecklingsaktiviteten och antalet utvecklare, såväl som tiden som spenderas på varje uppdatering - om den är stor, tvingas utvecklaren att begränsa uppdateringsfrekvensen för att inte slösa tid) . Projektändring Utvecklaren ändrar projektet genom att ändra filerna som ingår i det i arbetskopian i enlighet med projektuppgiften. Detta arbete görs lokalt och kräver inga anrop till VCS-servern. Begå förändringar Efter att ha slutfört nästa steg i arbetet med uppgiften, begår utvecklaren sina ändringar, överför dem till servern (antingen till huvudgrenen, om arbetet med uppgiften är helt slutförd, eller till en separat utvecklingsgren av denna uppgift ). VCS kan kräva att utvecklaren uppdaterar arbetskopian innan den utförs. Om systemet stöder uppskjutna ändringar ( hyllor ), kan ändringar överföras till servern utan att binda. Om den godkända arbetspolicyn i VCS tillåter det, kan fixeringen av ändringar utföras inte dagligen, utan endast efter avslutat arbete med uppgiften; i det här fallet sparas alla ändringar associerade med uppgiften endast i den lokala arbetskopian av utvecklaren tills arbetet är klart.Du kan göra mindre korrigeringar i projektet genom att direkt redigera arbetskopian och sedan överföra ändringarna direkt till huvudgrenen (i trunk) på servern. Men när man utför storskaligt arbete blir denna order obekväm: bristen på att fixa mellanliggande ändringar på servern tillåter inte att arbeta med någonting i ett gruppläge, dessutom ökar risken för att förlora ändringar under lokala olyckor och möjligheten att analysera och återgå till tidigare versioner av koden inom ett givet arbete. Därför, för sådana förändringar, är det vanligt att skapa grenar ( gren ), det vill säga "grenar" från stammen i någon version av en ny version av projektet eller en del av det, vars utveckling utförs parallellt med ändringar i huvudversionen. Grenen skapas av ett speciellt kommando. Arbetskopian av en gren kan återskapas på vanligt sätt (med kommandot checka ut arbetskopia, ange adress eller filial-ID), eller genom att byta en befintlig arbetskopia till en given gren.
Den grundläggande arbetscykeln när du använder grenar förblir exakt densamma som i det allmänna fallet: utvecklaren uppdaterar med jämna mellanrum arbetskopian (om mer än en person arbetar på grenen) och förbinder sitt dagliga arbete till det. Ibland stannar en utvecklingsgren på egen hand (när ändringar genererar en ny version av projektet, som sedan utvecklas separat från den huvudsakliga), men oftare, när arbetet som grenen skapades för görs, återintegreras grenen i stammen (huvudgrenen). Detta kan göras med ett sammanfogningskommando (vanligtvis merge ), eller genom att skapa en patch ( patch ) som innehåller ändringarna som gjorts under grenutvecklingen och applicera den patchen på den aktuella huvudversionen av projektet.
Tre typer av operationer som utförs i källkontroll kan resultera i ett behov av att slå samman ändringar. Det:
I alla fall är situationen i grunden densamma och har följande karakteristiska egenskaper:
Det är ganska uppenbart att om villkor (2) inte är uppfyllt (det vill säga om ändringar endast gjordes i originalet eller endast i en kopia), är sammanslagningen elementär - det räcker att kopiera den ändrade delen till där det inte fanns några ändringar. Annars förvandlas sammanslagningsändringar till en icke-trivial uppgift, som i många fall kräver ingripande av utvecklaren. I allmänhet fungerar mekanismen för automatisk sammanslagning av ändringar baserat på följande principer:
I alla fall är basversionen för sammanslagningen den version där uppdelningen av de sammanslagna versionerna gjordes. Om detta är en commit-operation, kommer basversionen att vara versionen av den senaste uppdateringen före commit, om uppdateringen, sedan versionen av den tidigare uppdateringen, om du slår samman grenar, sedan versionen där motsvarande gren skapades. Följaktligen kommer de matchade ändringarna att vara de ändringar som görs från basen till den nuvarande versionen i alla sammanslagna varianter.
De allra flesta moderna versionskontrollsystem är främst inriktade på programvaruutvecklingsprojekt där huvudtypen av filinnehåll är text. Följaktligen är mekanismerna för att automatiskt sammanfoga ändringar inriktade på bearbetning av textfiler, det vill säga filer som innehåller text som består av strängar av alfanumeriska tecken, mellanslag och tabbar, åtskilda av nyrader .
När man fastställer tillåtligheten av att slå samman ändringar inom samma textfil, fungerar en typisk mekanism för rad-för-rad-textjämförelse (ett exempel på dess implementering är GNU diff-systemverktyget), som jämför de sammanslagna versionerna med basversionen och bygger en lista över ändringar, det vill säga tillagda, raderade och ersatta raduppsättningar . Den minsta dataenheten för denna algoritm är en sträng, även den minsta skillnaden gör strängarna olika. Med tanke på att separatortecken i de flesta fall inte bär en semantisk belastning, kan sammanslagningsmotorn ignorera dessa tecken vid jämförelse av strängar.
De hittade uppsättningarna av ändrade strängar som inte skär varandra anses vara kompatibla och deras sammanslagning sker automatiskt. Om det finns ändringar i de sammanslagna filerna som påverkar samma rad i filen leder detta till en konflikt. Sådana filer kan endast slås samman manuellt. Alla andra filer än textfiler är binära ur VCS synvinkel och tillåter inte automatisk sammanslagning.
Situationen när, när flera versioner slås samman, de ändringar som görs i dem korsar varandra, kallas en konflikt . Om det finns en konflikt mellan ändringar kan versionskontrollsystemet inte automatiskt skapa ett sammanslaget projekt och måste kontakta utvecklaren. Som nämnts ovan kan konflikter uppstå i stadierna av att genomföra ändringar, uppdatera eller slå samman grenar. I alla fall, när en konflikt upptäcks, avslutas motsvarande operation tills den är löst.
För att lösa en konflikt erbjuder systemet i allmänhet utvecklaren tre alternativ för motstridiga filer: bas, lokal och server. Motstridiga ändringar visas antingen för utvecklaren i en speciell programmodul för att slå samman ändringar (i det här fallet visas de sammanslagna alternativen och den sammanslagna versionen av filen som dynamiskt ändras beroende på användarens kommandon), eller så är de helt enkelt markerade med specialuppmärkning direkt i texten i den sammanslagna filen (då måste utvecklaren själv bilda den önskade texten på omtvistade platser och behålla den).
Konflikter i filsystemet är lättare att lösa: bara borttagning av en fil kan komma i konflikt med en av de andra operationerna, och ordningen på filerna i katalogen spelar ingen roll, så utvecklaren kan bara välja vilken operation som ska behållas i den sammanslagna versionen .
Låsmekanismen tillåter en av utvecklarna att ta äganderätten till en fil eller grupp av filer för att göra ändringar i dem. Medan filen är låst förblir den skrivskyddad för alla andra utvecklare, och alla försök att göra ändringar i den avvisas av servern. Tekniskt sett kan blockering organiseras på olika sätt. Följande mekanism är typisk för moderna system.
Den massiva användningen av lås, när alla eller de flesta av filerna i ett projekt är låsbara och eventuella ändringar kräver att motsvarande uppsättning filer låses, kallas också strategin "låst utcheckning". [3] Tidiga versionskontrollsystem stödde enbart denna strategi, vilket förhindrade konflikter från att uppstå i början. I modern VCS är användningen av icke-blockerande hämtningar att föredra, medan lås snarare anses vara ett nödvändigt ont som bör begränsas så mycket som möjligt. Nackdelarna med att använda lås är uppenbara:
Å andra sidan, i vissa fall är användningen av lås ganska motiverad. Ett uppenbart exempel är organiseringen av arbetet med binära filer där det inte finns några verktyg för att slå samman ändringar eller en sådan sammanslagning är i grunden omöjlig (som till exempel för bildfiler). Om automatisk sammanslagning inte är möjlig kommer alla parallella ändringar av sådana filer under det normala arbetet att leda till en konflikt. I det här fallet är det mycket bekvämare att göra en sådan fil låsbar för att säkerställa att eventuella ändringar av den endast kommer att göras sekventiellt.
Versionskontrollsystemet ger lagring av alla befintliga varianter av filer och, som ett resultat, alla varianter av projektet som helhet som har ägt rum sedan början av dess utveckling. Men själva begreppet "version" i olika system kan tolkas på två sätt.
Vissa system stöder versionshantering av . Detta innebär att varje fil som visas i projektet får sitt eget versionsnummer (vanligtvis nummer 1, den villkorade "noll"-versionen av filen är en tom fil med samma namn). Varje gång en utvecklare utför ändringar som påverkar en fil, tillämpas lämplig del av de bekräftade ändringarna på filen, och filen får ett nytt, vanligtvis nästa i ordningen, versionsnummer. Eftersom commits vanligtvis bara påverkar en delmängd av filerna i arkivet, varierar versionsnumren för filer som är tillgängliga vid samma tidpunkt över tiden, och projektet som helhet (det vill säga hela uppsättningen filer i arkivet) gör det inte faktiskt ha valfritt "versionsnummer", eftersom det består av många filer med olika versionsnummer. CVS-versionskontrollsystemet fungerar till exempel på liknande sätt.
För andra system hänvisar begreppet "version" inte till en enda fil, utan till hela förvaret . Ett nyskapat tomt arkiv har en version av 1 eller 0, varje commit gör att detta nummer ökar (det vill säga, även om en fil ändras med en byte, anses hela arkivet ändrat och får ett nytt versionsnummer). Versionsnummer behandlas på detta sätt, till exempel av Subversion-systemet. Versionsnumret för en separat fil finns faktiskt inte här, det kan villkorligt betraktas som det aktuella versionsnumret för förvaret (det vill säga det kan antas att med varje ändring som görs i förvaret, ändrar alla dess filer versionen antal, även de som inte har ändrats). Ibland, på tal om "filversionen" i sådana system, menar de versionen av arkivet där filen senast ändrades (fram till det ögonblick vi är intresserade av).
Av praktiska skäl är det oftast inte en enskild fil som spelar roll, utan hela projektet som helhet. I system som stöder versionshantering av enskilda filer kan du använda datum och tid för att identifiera en specifik version av projektet - då kommer projektversionen att bestå av de versioner av filerna som ingår i det som fanns i förvaret vid den angivna punkten i tid. Om versionshanteringen av förvaret som helhet stöds, kan versionsnumret för projektet vara versionsnumret för förvaret. Båda alternativen är dock inte särskilt bekväma, eftersom varken datumet eller versionsnumret för förvaret vanligtvis innehåller information om betydande förändringar i projektet, om hur länge och intensivt de arbetade med det. För att enklare tagga versioner av ett projekt (eller delar av det) stödjer versionskontrollsystem konceptet med taggar .
En tagg är en symbolisk etikett som kan associeras med en viss version av en fil och/eller katalog i ett arkiv. Med hjälp av lämpligt kommando kan alla eller delar av projektfilerna som uppfyller vissa villkor (till exempel inkluderade i huvudversionen av projektets huvudgren vid en viss tidpunkt) tilldelas en given etikett. På detta sätt kan du identifiera versionen av projektet (version "XX.XXX.XXX" är en uppsättning versioner av förvarsfiler med taggen "XX.XXX.XXX"), och därmed fixa dess tillstånd vid något önskat ögonblick. Som regel är taggningssystemet ganska flexibelt och låter dig tagga icke-samtidiga versioner av filer och kataloger med en tagg. Detta gör att du kan bygga en "version av projektet" på vilket godtyckligt sätt som helst. Ur systemets användares synvinkel kan taggning se annorlunda ut. I vissa system visas den exakt som ett märke (en tagg kan skapas, appliceras på vissa versioner av filer och kataloger, tas bort). I andra system (till exempel Subversion) är taggen helt enkelt en separat katalog på filträdet för förvar, där kopior av nödvändiga versioner av filer görs från stammen och grenarna av projektet med hjälp av kommandot kopiera. Så visuellt är en tagg bara en kopia av vissa versioner av förvarsfilerna placerade i en separat katalog. Enligt konventionen är katalogträdet som motsvarar taggen inte tillåtet att utföra ändringar (det vill säga versionen av projektet som representeras av taggen är oförändrad).
Förfarandet för att använda versionskontrollsystemet i varje specifikt fall bestäms av de tekniska föreskrifter och regler som antagits i ett visst företag eller en organisation som utvecklar projektet. De allmänna principerna för korrekt användning av VCS är dock få och desamma för alla utvecklings- och versionskontrollsystem.
Även känt som Distributed Version Control System , DVCS. Sådana system använder en distribuerad modell istället för den traditionella klient-server-modellen. I allmänhet behöver de inte ett centraliserat arkiv: hela historiken för dokumentändringar lagras på varje dator i lokal lagring, och vid behov synkroniseras enskilda fragment av den lokala lagringshistoriken med en liknande lagring på en annan dator. I vissa av dessa system finns lokal lagring direkt i arbetskopiornas kataloger.
När en användare av ett sådant system utför normala åtgärder, såsom att checka ut en specifik version av ett dokument, skapa en ny version och så vidare, arbetar han med sin lokala kopia av förvaret. När ändringar görs börjar lagringsplatser som tillhör olika utvecklare skilja sig åt, och det blir nödvändigt att synkronisera dem. Sådan synkronisering kan utföras genom att byta patchar eller så kallade ändringsuppsättningar mellan användare .
Den beskrivna modellen är logiskt sett nära att skapa en separat gren för varje utvecklare i det klassiska versionskontrollsystemet (i vissa distribuerade system måste du skapa en ny gren innan du arbetar med lokal lagring). Skillnaden är att fram till ögonblicket för synkronisering ser andra utvecklare av denna gren inte. Så länge utvecklaren byter enbart sin egen gren påverkar hans arbete inte andra projektdeltagare och vice versa. Efter slutförandet av en separat del av arbetet slås de ändringar som gjorts i grenarna samman med huvudgrenen (gemensamma). Både vid sammanslagning av grenar och vid synkronisering av olika repositories är versionskonflikter möjliga. I det här fallet tillhandahåller alla system en eller annan metod för att upptäcka och lösa sammanslagningskonflikter.
Ur användarens synvinkel kännetecknas ett distribuerat system av behovet av att skapa ett lokalt arkiv och närvaron av två ytterligare kommandon på kommandospråket: kommandot att ta emot ett arkiv från en fjärrdator (pull) och överföra dess arkiv till en fjärrdator (push). Det första kommandot slår samman ändringarna från de fjärranslutna och lokala arkiven och skickar resultatet till det lokala arkivet; den andra, tvärtom, sammanfogar ändringarna av de två arkiven med resultatet placerat i ett fjärrarkiv. Som regel låter merge-kommandon i distribuerade system dig välja vilka ändringsuppsättningar som ska överföras till eller dras från ett annat arkiv, fixa sammanslagningskonflikter direkt under operationen eller efter att den misslyckas, försöka igen eller återuppta en oavslutad sammanslagning. Vanligtvis lyckas det bara att driva dina ändringar till någon annans arkiv (push) om det inte finns några konflikter. Om konflikter uppstår måste användaren först slå samman versionerna i sitt arkiv (utföra en pull) och först därefter överföra dem till andra.
Det rekommenderas generellt att organisera arbetet med systemet på ett sådant sätt att användarna alltid eller till övervägande del går samman i sitt eget arkiv. Det vill säga, till skillnad från centraliserade system, där användare överför sina ändringar till en central server när de finner det lämpligt, i distribuerade system, är det mer naturligt att slå samman versioner av den som behöver få dess resultat (till exempel en utvecklare som hanterar ett bygge server).
De främsta fördelarna med distribuerade system är deras flexibilitet och mycket större (jämfört med centraliserade system) autonomi för en enskild arbetsplats. Varje utvecklares dator är i själva verket en oberoende och fullfjädrad server, från sådana datorer är det möjligt att bygga ett godtyckligt system i struktur och komplexitet, ställa in (både tekniska och administrativa åtgärder) den önskade synkroniseringsordningen. Samtidigt kan varje utvecklare arbeta självständigt, på ett sätt som är bekvämt för honom, ändra och spara mellanliggande versioner av dokument, använda alla funktioner i systemet (inklusive tillgång till ändringshistoriken) även i frånvaro av en nätverksanslutning till servern. Kommunikation med servern eller andra utvecklare krävs enbart för synkronisering, medan utbytet av uppsättningar av ändringar kan utföras enligt olika scheman.
Nackdelarna med distribuerade system inkluderar en ökning av den nödvändiga mängden diskminne: varje dator måste lagra en fullständig versionshistorik, medan i ett centraliserat system lagras vanligtvis bara en arbetskopia på utvecklarens dator, det vill säga en bit av förvaret vid någon tidpunkt och de ändringar som gjorts. En mindre uppenbar men irriterande nackdel är att det är nästan omöjligt att implementera en del av de funktioner som centraliserade system tillhandahåller i ett distribuerat system. Det:
Vi kan urskilja följande typiska situationer där användningen av ett distribuerat system ger märkbara fördelar:
I traditionell "kontors" projektutveckling, när en grupp av utvecklare är relativt liten och helt lokaliserad på samma territorium, inom ett enda lokalt datornätverk, med servrar ständigt tillgängliga, kan ett centraliserat system vara det bästa valet på grund av dess stelare struktur och närvaron av funktionalitet som saknas i distribuerade system (till exempel det redan nämnda låset). Möjligheten att genomföra förändringar utan att slå samman dem i den centrala grenen under sådana förhållanden implementeras enkelt genom att dela upp pågående arbeten i separata utvecklingsgrenar.
Det finns ingen allmänt accepterad terminologi, olika system kan använda olika namn för samma åtgärder. Nedan är några av de mest använda alternativen. Engelska termer ges, i litteraturen på ryska används en eller annan översättning eller translitteration .
ändra Gör ändringar utan att skapa en ny version - vanligtvis när utvecklaren av misstag commit ( commit ) versionen, men inte laddade upp ( push ) den till servern. skylla Ta reda på vem som gjorde förändringen. gren En gren är en utvecklingsriktning oberoende av andra. En filial är en kopia av en del (vanligtvis en katalog) av förvaret, där du kan göra dina egna ändringar utan att påverka andra filialer. Dokument i olika grenar har samma historik före grenpunkten och olika historik efter den. ändringsuppsättning, ändringslista, aktivitet Uppsättning ändringar. Representerar en namngiven uppsättning redigeringar gjorda på en lokal kopia för något gemensamt syfte. På system som stöder ändringsuppsättningar kan utvecklaren organisera lokala ändringar i grupper och utföra logiskt relaterade ändringar i ett kommando, och specificera den nödvändiga ändringsuppsättningen som en parameter. I det här fallet förblir andra redigeringar ofixade. Ett typiskt exempel: arbete pågår för att lägga till ny funktionalitet och i det ögonblicket upptäcks en kritisk bugg som måste åtgärdas omedelbart. Utvecklaren skapar en uppsättning ändringar för det arbete som redan gjorts och en ny för korrigeringar. När korrigeringen av felet har slutförts, ges kommandot att endast utföra den andra uppsättningen redigeringar. checka in, begå, underkasta sig Skapa en ny version, genomför ändringar. I vissa stadsjeepar ( Subversion ) - överförs den nya versionen automatiskt till dokumentförrådet. utcheckning, klona Hämta ett dokument från lagringen och skapa en arbetskopia. konflikt En konflikt är en situation där flera användare har gjort ändringar i samma avsnitt av ett dokument. En konflikt upptäcks när en användare har genomfört sina ändringar, och den andra försöker utföra sina ändringar, och systemet självt kan inte korrekt slå samman de motstridiga ändringarna. Eftersom programmet kanske inte är smart nog att avgöra vilken ändring som är "korrekt", måste den andra användaren lösa konflikten själv ( resolve ). graft, backport, cherry-plock, transplantation Använd den inbyggda sammanslagningsalgoritmen i VMS för att överföra enskilda ändringar till en annan gren utan att slå samman dem. Till exempel fixade vi en bugg i experimentgrenen - vi gör samma ändringar i den stabila stammen. huvud, bål Huvudversionen är den senaste versionen för filialen/trunken som finns i förvaret. Hur många grenar, så många större versioner. sammansmälta, integration En sammanslagning är en kombination av oberoende ändringar till en enda version av ett dokument. Händes när två personer har ändrat samma fil eller när ändringar flyttas från en gren till en annan. dra, uppdatera Hämta nya versioner från förvaret. I vissa stadsjeepar ( Subversion ) - både pull och switch inträffar , det vill säga ändringar laddas, och sedan förs arbetskopian till det sista tillståndet. Var försiktig , uppdateringen är tvetydig och betyder olika saker i Subversion och Mercurial . tryck Ladda upp nya versioner till förvaret. Många distribuerade VCS:er ( Git , Mercurial ) antar att en commit måste ges varje gång programmeraren har utfört någon avslutad funktion. Och fyll i - när det finns internet och andra vill ha dina ändringar. Commit kräver vanligtvis inte ett användarnamn och lösenord, men push gör det. rebas Använd den inbyggda sammanslagningsalgoritmen i VMS för att flytta grenpunkten (versionen från vilken grenen börjar) till en senare version av trunk. Används oftast i detta scenario: Boris har gjort ändringar och upptäcker att han inte kan driva dem, eftersom Anna tidigare bytt en helt annan plats i koden. Du kan helt enkelt slå samman dem ( sammanfoga ). Men trädet blir linjärt och mer läsbart om du överger din revision, men gör samma ändringar i Annas revision - det här är rebase . Om Anna och Boris arbetar med samma kod, stör varandra och löser konflikter manuellt, rekommenderas inte rebase . förvar, depå Dokumentförrådet är där versionskontrollsystemet lagrar alla dokument tillsammans med deras ändringshistorik och annan serviceinformation. revision Dokumentversion. Versionskontrollsystem särskiljer versioner genom nummer, som tilldelas automatiskt. hylla, förråd Att skjuta upp ändringar. Möjligheten som vissa system ger att skapa en ändringsuppsättning (ändringsuppsättning) och spara den på servern utan att begå (commit'a). En backlog-ändringsuppsättning är läsbar av andra projektmedlemmar, men ingår inte i huvudgrenen förrän ett speciellt kommando. Att skjuta upp supporten tillåter användare att spara pågående arbete på servern utan att skapa separata grenar för detta. squash Ymp- /körsbärsplockningsläge för hela grenen. Med andra ord är hela grenen engagerad som en förändring. Användbar för ändringar som är tillräckligt stora för att ta flera dagar att slutföra och tillräckligt små för att inte ha en fullständig historik över dem. skede Välj vilka ändringar som ska göras ( commit ), och vilka som ska hållas privata eller göra senare. remsa Ta bort en hel gren från förvaret. tagg, etikett En etikett som kan tilldelas en viss version av ett dokument. En etikett är ett symboliskt namn för en grupp av dokument, och etiketten beskriver inte bara en uppsättning filnamn, utan även versionen av varje fil. De versioner av dokumenten som ingår i etiketten kan tillhöra olika tidpunkter. stam, stamledning, mästare Stammen är huvudgrenen i projektutvecklingen. Trunkpolicyn kan skilja sig från projekt till projekt, men generellt sett är det följande: de flesta ändringar görs i stammen; om det krävs en större förändring som kan leda till instabilitet skapas en gren som smälter samman med stammen när innovationen har testats tillräckligt; före releasen av nästa version skapas en gren för den efterföljande releasen, där endast korrigeringar görs. uppdatera, synkronisera, byta Synkronisering av arbetskopian till något specificerat lagringstillstånd. Oftast innebär den här åtgärden att arbetskopian uppdateras till det senaste valvläget. Men om det behövs kan du synkronisera arbetskopian till ett äldre tillstånd än det nuvarande. arbetskopia Arbets (lokal) kopia av dokument.| Versionskontrollsystem ( kategori ) | |
|---|---|
| Endast lokalt | |
| Klient-server | |
| Distribuerad | |