Systém pro správu verzí (také používaná definice "version control system [1] ", z anglického Version Control System, VCS nebo Revision Control System ) - software pro usnadnění práce s měnícími se informacemi. Systém správy verzí vám umožňuje uložit více verzí stejného dokumentu, v případě potřeby se vrátit k dřívějším verzím, určit, kdo a kdy provedl změnu, a mnoho dalšího.
Takové systémy se nejvíce používají při vývoji softwaru pro ukládání zdrojových kódů vyvíjeného programu. Lze je však s úspěchem uplatnit i v jiných oblastech, kde se pracuje s velkým množstvím neustále se měnících elektronických dokumentů. V CAD se používají zejména systémy pro správu verzí , obvykle jako součást systémů pro správu produktových dat ( PDM ). Správa verzí se používá v Nástrojích pro správu konfigurace softwaru .
Software Wikipedia udržuje historii revizí pro všechny své články pomocí metod podobných těm, které se používají v systémech správy verzí.
Zcela typická je situace, kdy elektronický dokument během své existence prochází řadou změn. V tomto případě je často důležité mít nejen nejnovější verzi, ale i několik předchozích. V nejjednodušším případě můžete jednoduše uložit několik verzí dokumentu a odpovídajícím způsobem je očíslovat. Tato metoda je neefektivní (musíte uchovávat několik téměř identických kopií), vyžaduje zvýšenou pozornost a disciplínu a často vede k chybám, proto byly vyvinuty nástroje pro automatizaci této práce.
Tradiční systémy správy verzí používají centralizovaný model, kde existuje jediné úložiště dokumentů spravované speciálním serverem , který provádí většinu funkcí správy verzí. Uživatel pracující s dokumenty musí nejprve získat verzi dokumentu, kterou potřebuje, z úložiště; obvykle se vytvoří lokální kopie dokumentu, tzv. „pracovní kopie“. Lze získat nejnovější verzi nebo kteroukoli z předchozích, které lze vybrat podle čísla verze nebo data vytvoření, někdy podle jiných kritérií. Po provedení požadovaných změn v dokumentu je nová verze umístěna do úložiště. Na rozdíl od pouhého uložení souboru se předchozí verze nevymaže, ale také zůstane v úložišti a lze ji odtud kdykoli získat. Server může využívat tzv. Delta komprese je způsob ukládání dokumentů, který ukládá pouze změny mezi po sobě jdoucími verzemi, což snižuje množství uložených dat. Protože nejnovější verze souboru je obvykle nejžádanější, může systém při ukládání nové verze uložit celý soubor a nahradit poslední dříve uloženou verzi v úložišti rozdílem mezi touto a nejnovější verzí. Některé systémy (například ClearCase ) podporují ukládání verzí obou typů: většina verzí se ukládá jako delta, ale pravidelně (pomocí speciálního příkazu správce) jsou všechny soubory ukládány v plných verzích; tento přístup zajišťuje nejúplnější obnovu historie v případě poškození úložiště .
Někdy se vytvoření nové verze provádí pro uživatele nepostřehnutelně (transparentně), buď aplikačním programem , který má vestavěnou podporu pro takovou funkci, nebo pomocí speciálního souborového systému . V tomto případě uživatel jednoduše pracuje se souborem jako obvykle a po uložení souboru se automaticky vytvoří nová verze.
Často se stává, že na stejném projektu pracuje více lidí současně. Pokud dva lidé upraví stejný soubor , jeden z nich může omylem vrátit zpět změny provedené druhým. Systémy pro správu verzí takové konflikty sledují a nabízejí nástroje k jejich řešení. Většina systémů dokáže automaticky sloučit (sloučit) změny provedené různými vývojáři. Takové automatické slučování změn je však obvykle možné pouze u textových souborů a za předpokladu, že byly změněny různé (nepřekrývající se) části tohoto souboru. Toto omezení je způsobeno skutečností, že většina systémů správy verzí je zaměřena na podporu procesu vývoje softwaru a zdrojové kódy programů jsou uloženy v textových souborech. Pokud se automatické sloučení nezdaří, systém může nabídnout řešení problému ručně.
Často je nemožné sloučit automaticky ani ručně, například pokud je formát souboru neznámý nebo příliš složitý. Některé systémy správy verzí vám umožňují zamknout soubor v úschovně. Zámek brání ostatním uživatelům získat pracovní kopii nebo brání úpravě pracovní kopie souboru (např. pomocí souborového systému) a poskytuje tak výhradní přístup pouze uživateli, který s dokumentem pracuje.
Mnoho systémů pro správu verzí poskytuje řadu dalších funkcí:
Každý systém správy verzí má své vlastní specifické funkce, pokud jde o sadu příkazů, chování uživatele a správu. Obecný operační postup pro většinu VCS je však zcela stereotypní. Zde se předpokládá, že projekt, ať už je jakýkoli, již existuje a jeho úložiště je hostováno na serveru , ke kterému má vývojář přístup.
První akcí, kterou musí vývojář provést, je vyzvednutí pracovní kopie projektu nebo jeho části, na které se má pracovat. Tato akce se provádí pomocí příkazu version checkout (obvykle checkout nebo clone ). Vývojář specifikuje verzi, která má být zkopírována, standardně se obvykle zkopíruje nejnovější (nebo administrátorova volba jako hlavní) verze.
Příkaz extrakce naváže spojení se serverem a projekt (nebo jeho část - jeden z adresářů s podadresáři) se zkopíruje do počítače vývojáře ve formě stromu adresářů a souborů. Běžnou praxí je duplikování pracovní kopie: kromě hlavního adresáře s projektem se na lokální disk navíc zapíše jeho další kopie (buď do samostatného, speciálně vybraného adresáře, nebo do systémových podadresářů hlavního projektu strom). Při práci na projektu vývojář pouze mění soubory v hlavní pracovní kopii. Druhá místní kopie je uložena jako reference, což vám umožňuje kdykoli bez kontaktování serveru určit, jaké změny byly provedeny v konkrétním souboru nebo projektu jako celku a ze které verze byla pracovní kopie „vyplozena“; každý pokus o ruční úpravu této kopie má zpravidla za následek chyby v provozu softwaru VCS.
S určitými odchylkami, danými vlastnostmi systému a podrobnostmi převzatého technologického postupu, je obvyklý cyklus práce vývojáře během pracovního dne následující.
Aktualizace pracovní kopie Jak jsou prováděny změny v hlavní verzi projektu, pracovní kopie na počítači vývojáře stárne: zvyšuje se její nesoulad s hlavní verzí projektu. To zvyšuje riziko konfliktních změn (viz níže ). Proto je vhodné udržovat pracovní kopii ve stavu co nejbližším aktuální hlavní verzi, u které vývojář co nejčastěji provádí aktualizační operaci pracovní kopie ( update ) (zjišťuje se skutečná frekvence aktualizací podle četnosti změn v závislosti na vývojové činnosti a počtu vývojářů a také času stráveného na každé aktualizaci - pokud je velká, je vývojář nucen omezit frekvenci aktualizací, aby neztrácel čas) . Úprava projektu Vývojář upraví projekt změnou souborů, které jsou v něm obsaženy v pracovní kopii v souladu s projektovým úkolem. Tato práce se provádí lokálně a nevyžaduje volání serveru VCS. Provádění změn Po dokončení další fáze práce na úloze vývojář potvrdí ( odevzdá ) své změny a přenese je na server (buď do hlavní větve, pokud je práce na úloze zcela dokončena, nebo do samostatné vývojové větve této úlohy ). VCS může vyžadovat, aby vývojář aktualizoval pracovní kopii před potvrzením. Pokud systém podporuje odložené změny ( Shelving ), lze změny přenést na server bez potvrzení. Pokud to schválená pracovní politika ve VCS umožňuje, pak lze opravy změn provádět ne denně, ale pouze po dokončení práce na úkolu; v tomto případě jsou všechny změny spojené s úlohou uloženy pouze v místní pracovní kopii vývojáře, dokud není práce dokončena.Drobné opravy v projektu můžete provést přímou úpravou pracovní kopie a následným odesláním změn přímo do hlavní větve (v kmeni) na serveru. Při provádění rozsáhlých prací se však tato objednávka stává nepohodlnou: nedostatek oprav mezilehlých změn na serveru neumožňuje pracovat na ničem ve skupinovém režimu, navíc se zvyšuje riziko ztráty změn při místních nehodách a schopnost analyzovat a vrátit se k předchozím verzím kódu v rámci daného díla. Proto je pro takové změny běžnou praxí vytvářet větve ( branch ), tedy „větvení“ z kmene v nějaké verzi nové verze projektu nebo jeho části, jejíž vývoj probíhá paralelně. se změnami v hlavní verzi. Větev je vytvořena speciálním příkazem. Pracovní kopii větve lze znovu vytvořit obvyklým způsobem (příkazem check out pracovní kopie s uvedením adresy nebo ID větve) nebo přepnutím existující pracovní kopie na danou větev.
Základní pracovní cyklus při používání větví zůstává úplně stejný jako v obecném případě: vývojář pracovní kopii periodicky aktualizuje (pokud na větvi pracuje více osob) a zavazuje k ní svou každodenní práci. Někdy vývojová větev zůstává sama o sobě (když změny generují novou verzi projektu, která se pak vyvíjí odděleně od hlavní), ale častěji, když je práce, pro kterou byla větev vytvořena, větev znovu začleněna do kmen (hlavní větev). To lze provést pomocí příkazu merge (obvykle merge ), nebo vytvořením opravy ( patch ) obsahující změny provedené během vývoje větve a aplikováním této opravy na aktuální hlavní verzi projektu.
Tři typy operací prováděných v řízení zdroje mohou vést k nutnosti sloučit změny. To:
Ve všech případech je situace v zásadě stejná a má následující charakteristické rysy:
Je zcela zřejmé, že pokud není splněna podmínka (2) (tedy pokud byly provedeny změny pouze na originálu nebo pouze na kopii), je sloučení elementární - stačí zkopírovat změněnou část tam, kde nebyly Změny. V opačném případě se sloučení změn změní v netriviální úkol, který v mnoha případech vyžaduje zásah vývojáře. Obecně platí, že mechanismus automatického slučování změn funguje na základě následujících principů:
Ve všech případech je základní verzí pro sloučení verze, ve které bylo provedeno rozdělení sloučených verzí. Pokud se jedná o operaci odevzdání, pak bude základní verzí verze poslední aktualizace před odevzdáním, pokud aktualizace, pak verze předchozí aktualizace, pokud sloučí větve, pak verze, ve které byla vytvořena odpovídající větev. V souladu s tím budou odpovídajícími sadami změn sady změn provedené od základní po aktuální verzi ve všech sloučených variantách.
Naprostá většina moderních systémů pro správu verzí je zaměřena především na projekty vývoje softwaru, ve kterých je hlavním typem obsahu souborů text. V souladu s tím jsou mechanismy pro automatické slučování změn orientovány na zpracování textových souborů, tedy souborů obsahujících text složený z řetězců alfanumerických znaků, mezer a tabulátorů, oddělených novými řádky .
Při určování přípustnosti slučování změn v rámci stejného textového souboru funguje typický mechanismus porovnávání textu řádek po řádku (příkladem jeho implementace je systémová utilita GNU diff), která porovnává sloučené verze se základní a vytváří seznam změn, tedy přidaných, odstraněných a nahrazených sad řádků . Minimální jednotkou dat pro tento algoritmus je řetězec, i ten nejmenší rozdíl způsobuje, že se řetězce liší. Vzhledem k tomu, že oddělovací znaky ve většině případů nenesou sémantickou zátěž, slučovací stroj může tyto znaky při porovnávání řetězců ignorovat.
Nalezené množiny změněných řetězců, které se vzájemně neprotínají, jsou považovány za kompatibilní a jejich slučování se provádí automaticky. Pokud jsou ve sloučených souborech změny, které ovlivňují stejný řádek souboru, vede to ke konfliktu. Takové soubory lze sloučit pouze ručně. Jakékoli jiné soubory než textové jsou z pohledu VCS binární a neumožňují automatické slučování.
Situace, kdy se při sloučení několika verzí vzájemně prolínají změny v nich provedené, se nazývá konflikt . Pokud dojde ke konfliktu změn, systém správy verzí nemůže automaticky vytvořit sloučený projekt a musí kontaktovat vývojáře. Jak bylo uvedeno výše, konflikty mohou nastat ve fázích provádění změn, aktualizace nebo slučování větví. Ve všech případech, kdy je zjištěn konflikt, je odpovídající operace ukončena, dokud není vyřešen.
K vyřešení konfliktu systém obvykle nabízí vývojáři tři možnosti pro konfliktní soubory: základní, místní a server. Konfliktní změny jsou buď zobrazeny vývojáři ve speciálním programovém modulu pro slučování změn (v tomto případě jsou zde zobrazeny sloučené možnosti a sloučená verze souboru, která se dynamicky mění v závislosti na příkazech uživatele), nebo jsou jednoduše označeny speciální označení přímo v textu sloučeného souboru (potom musí vývojář sám vytvořit požadovaný text na sporných místech a ponechat jej).
Konflikty v souborovém systému se vyřeší snáze: pouze smazání souboru může být v konfliktu s jednou z dalších operací a na pořadí souborů v adresáři nezáleží, takže vývojář může pouze vybrat, kterou operaci ponechat ve sloučené verzi .
Uzamykací mechanismus umožňuje jednomu z vývojářů převzít vlastnictví souboru nebo skupiny souborů, aby v nich mohl provádět změny. Když je soubor uzamčen, zůstává pouze pro čtení pro všechny ostatní vývojáře a jakýkoli pokus o provedení změn je serverem odmítnut. Technicky lze blokování organizovat různými způsoby. Následující mechanismus je typický pro moderní systémy.
Masivní používání zámků, kdy jsou všechny nebo většina souborů v projektu uzamykatelné a jakékoli změny vyžadují uzamčení odpovídající sady souborů, se také nazývá strategie „uzamčené pokladny“. [3] Systémy pro správu raných verzí podporovaly výhradně tuto strategii, čímž předcházely konfliktům v zárodku. V moderních VCS je preferováno použití neblokovacích aportů, přičemž zámky jsou považovány spíše za nutné zlo, které by mělo být co nejvíce omezeno. Nevýhody použití zámků jsou zřejmé:
Na druhou stranu je v některých případech použití zámků zcela oprávněné. Zřejmým příkladem je organizace práce s binárními soubory, pro které neexistují nástroje pro slučování změn nebo je takové slučování zásadně nemožné (jako např. u obrazových souborů). Pokud není automatické slučování možné, pak při normálním průběhu práce povede jakákoli paralelní úprava takových souborů ke konfliktu. V tomto případě je mnohem pohodlnější takový soubor uzamykat, aby bylo zajištěno, že jakékoli změny v něm budou prováděny pouze postupně.
Systém správy verzí poskytuje úložiště všech existujících variant souborů a ve výsledku i všech variant projektu jako celku, které proběhly od počátku jeho vývoje. Ale samotný pojem „verze“ v různých systémech lze interpretovat dvěma způsoby.
Některé systémy podporují verzování . To znamená, že každý soubor, který se objeví v projektu, obdrží své vlastní číslo verze (obvykle číslo 1, podmíněná "nulová" verze souboru je prázdný soubor se stejným názvem). Pokaždé, když vývojář potvrdí změny, které ovlivňují soubor, použije se příslušná část potvrzených změn na soubor a soubor získá nové, obvykle další v pořadí, číslo verze. Vzhledem k tomu, že odevzdání obvykle ovlivňuje pouze podmnožinu souborů v úložišti, čísla verzí souborů dostupných ve stejném časovém okamžiku se v průběhu času liší a projekt jako celek (tj. celá sada souborů v úložišti) se nemění. mít ve skutečnosti jakékoli "číslo verze", protože se skládá z mnoha souborů s různými čísly verzí. Podobně funguje například systém správy verzí CVS.
U jiných systémů se pojem „verze“ nevztahuje na jeden soubor, ale na celé úložiště . Nově vytvořené prázdné úložiště má verzi 1 nebo 0, jakékoli potvrzení způsobí zvýšení tohoto čísla (to znamená, že i když se jeden soubor změní o jeden bajt, celé úložiště je považováno za změněné a obdrží nové číslo verze). S čísly verzí takto nakládá například systém Subversion. Číslo verze samostatného souboru zde ve skutečnosti neexistuje, podmíněně jej lze považovat za aktuální číslo verze úložiště (tj. lze předpokládat, že s každou změnou v úložišti všechny jeho soubory změní verzi číslo, a to i ty, které se nezměnily). Někdy, když mluvíme o „verzi souboru“ v takových systémech, znamenají verzi úložiště, ve kterém byl soubor naposledy upraven (až do okamžiku, kdy nás to zajímá).
Pro praktické účely obvykle není důležitý jeden soubor, ale celý projekt jako celek. V systémech, které podporují verzování jednotlivých souborů, můžete použít datum a čas k identifikaci konkrétní verze projektu – verze projektu se pak bude skládat z těch verzí souborů v ní obsažených, které byly v úložišti v zadaném bodě čas. Pokud je podporováno verzování úložiště jako celku, může být číslem verze projektu číslo verze úložiště. Obě možnosti však nejsou příliš pohodlné, protože datum ani číslo verze úložiště obvykle nenesou informace o významných změnách v projektu, o tom, jak dlouho a intenzivně na něm pracovali. Aby bylo možné pohodlněji označit verze projektu (nebo jeho částí), systémy správy verzí podporují koncept značek .
Značka je symbolický štítek, který lze přiřadit ke konkrétní verzi souboru a/nebo adresáře v úložišti. Pomocí příslušného příkazu lze všem souborům projektu nebo jejich části, které splňují určité podmínky (například zahrnuty do hlavní verze hlavní větve projektu v určitém okamžiku), přiřadit daný štítek. Tímto způsobem můžete identifikovat verzi projektu (verze "XX.XXX.XXX" je sada verzí souborů úložiště s tagem "XX.XXX.XXX") a opravit tak jeho stav v požadovaném okamžiku. Systém označování je zpravidla poměrně flexibilní a umožňuje označit nesoučasné verze souborů a adresářů jedním tagem. To vám umožňuje sestavit "verzi projektu" libovolným způsobem. Z pohledu uživatele systému může tagování vypadat jinak. V některých systémech se zobrazuje přesně jako značka (značku lze vytvořit, aplikovat na určité verze souborů a adresářů, odstranit). V jiných systémech (například Subversion) je značka jednoduše samostatným adresářem ve stromu souborů úložiště, kde se pomocí příkazu copy vytvářejí kopie potřebných verzí souborů z kmene a větví projektu. Takže vizuálně je značka pouze kopií určitých verzí souborů úložiště umístěných v samostatném adresáři. Podle konvence strom adresářů odpovídající tagu nesmí provádět změny (to znamená, že verze projektu reprezentovaná tagem se nemění).
Postup pro použití systému správy verzí v každém konkrétním případě je určen technickými předpisy a pravidly přijatými v konkrétní společnosti nebo organizaci vyvíjející projekt. Obecných zásad pro správné používání VCS je však málo a jsou stejné pro všechny vývojové systémy a systémy pro správu verzí.
Také známý jako distribuovaný systém správy verzí , DVCS. Takové systémy používají distribuovaný model namísto tradičního modelu klient-server. Obecně nepotřebují centralizované úložiště: celá historie změn dokumentů je uložena na každém počítači v lokálním úložišti a v případě potřeby jsou jednotlivé fragmenty historie lokálního úložiště synchronizovány s podobným úložištěm na jiném počítači. V některých z těchto systémů je místní úložiště umístěno přímo v adresářích pracovních kopií.
Když uživatel takového systému provádí běžné akce, jako je odhlášení konkrétní verze dokumentu, vytvoření nové verze a tak dále, pracuje se svou lokální kopií úložiště. Jak jsou prováděny změny, repozitáře patřící různým vývojářům se začínají lišit a je nutné je synchronizovat. Takovou synchronizaci lze provést výměnou patchů nebo tzv. sad změn mezi uživateli .
Popsaný model se logicky blíží vytvoření samostatné větve pro každého vývojáře v klasickém systému správy verzí (v některých distribuovaných systémech je před prací s lokálním úložištěm potřeba vytvořit větev novou). Rozdíl je v tom, že až do okamžiku synchronizace ostatní vývojáři této větve nevidí. Dokud vývojář mění pouze svou vlastní pobočku, jeho práce neovlivňuje ostatní účastníky projektu a naopak. Po dokončení samostatné části práce se provedené změny větví sloučí s hlavní (společnou) větví. Jak při slučování větví, tak při synchronizaci různých úložišť jsou možné konflikty verzí. V tomto případě všechny systémy poskytují jednu nebo druhou metodu pro detekci a řešení konfliktů sloučení.
Z uživatelského hlediska se distribuovaný systém vyznačuje potřebou vytvořit lokální úložiště a přítomností dvou dalších příkazů v příkazovém jazyce: příkaz přijmout úložiště ze vzdáleného počítače (pull) a přenést jeho úložiště do vzdálený počítač (push). První příkaz sloučí změny ze vzdáleného a místního úložiště a pošle výsledek do místního úložiště; druhý naopak sloučí změny dvou úložišť s výsledkem umístěným ve vzdáleném úložišti. Příkazy sloučení v distribuovaných systémech zpravidla umožňují vybrat, které sady změn budou přeneseny do jiného úložiště nebo z něj vytaženy, opravit konflikty sloučení přímo během operace nebo po jejím selhání, opakovat nebo obnovit nedokončené sloučení. Obvykle je přenesení vašich změn do úložiště někoho jiného (push) úspěšné pouze v případě, že nedochází ke konfliktům. Pokud dojde ke konfliktům, uživatel musí nejprve sloučit verze ve svém úložišti (provést pull) a teprve poté je přenést do jiných.
Obecně se doporučuje organizovat práci se systémem tak, aby se uživatelé vždy nebo převážně slučovali ve vlastním úložišti. To znamená, že na rozdíl od centralizovaných systémů, kde uživatelé přenášejí své změny na centrální server, když uznají za vhodné, v distribuovaných systémech je přirozenější slučovat verze tím, kdo potřebuje získat výsledek (například vývojář spravující sestavení server) .
Hlavními výhodami distribuovaných systémů je jejich flexibilita a mnohem větší (ve srovnání s centralizovanými systémy) autonomie jednotlivého pracoviště. Každý vývojářský počítač je ve skutečnosti nezávislým a plnohodnotným serverem, z takových počítačů je možné sestavit libovolný systém ve struktuře a složitosti s nastavením (jak technickými, tak administrativními opatřeními) požadovaného pořadí synchronizace. Zároveň může každý vývojář pracovat samostatně, způsobem, který je pro něj pohodlný, měnit a ukládat meziverze dokumentů s využitím všech funkcí systému (včetně přístupu k historii změn), a to i v případě nepřítomnosti síťové připojení k serveru. Komunikace se serverem nebo jinými vývojáři je nutná pouze pro synchronizaci, přičemž výměna sad změn může být prováděna podle různých schémat.
Mezi nevýhody distribuovaných systémů patří zvýšení potřebného množství diskové paměti: každý počítač musí uchovávat kompletní historii verzí, zatímco v centralizovaném systému je na vývojářském počítači obvykle uložena pouze pracovní kopie, tedy výsek úložiště v určitém okamžiku a provedené změny. Méně zjevnou, ale nepříjemnou nevýhodou je, že je téměř nemožné implementovat některé funkce poskytované centralizovanými systémy v distribuovaném systému. To:
Můžeme rozlišit následující typické situace, ve kterých použití distribuovaného systému poskytuje znatelné výhody:
V tradičním vývoji "kancelářských" projektů, kdy je skupina vývojářů relativně malá a zcela umístěná na stejném území, v rámci jediné místní počítačové sítě, se servery neustále dostupnými, může být centralizovaný systém tou nejlepší volbou díky své pevnější struktuře. a přítomnost funkcionality, která v distribuovaných systémech chybí (například již zmíněný zámek). Schopnost provádět změny bez jejich slučování do centrální větve v takových podmínkách je snadno implementována rozdělením rozpracované výroby do samostatných vývojových větví.
Neexistuje žádná obecně přijímaná terminologie, různé systémy mohou používat různé názvy pro stejné akce. Níže jsou uvedeny některé z nejčastěji používaných možností. Jsou uvedeny anglické termíny, v literatuře v ruštině se používá ten či onen překlad nebo transliterace .
upravit Provádějte změny bez vytváření nové verze – obvykle když vývojář chybně potvrdil ( odevzdal ) verzi, ale nenahrál ( neodeslal ) na server. obviňovat Zjistěte, kdo změnu provedl. větev Větev je směr vývoje nezávislý na ostatních. Větev je kopie části (obvykle jednoho adresáře) úložiště, ve které můžete provádět vlastní změny, aniž byste ovlivnili ostatní větve. Dokumenty v různých větvích mají stejnou historii před bodem větve a jinou historii po něm. changeset, changelist, aktivita Sada změn. Představuje pojmenovanou sadu úprav provedených v místní kopii pro nějaký běžný účel. Na systémech, které podporují changesety, může vývojář organizovat místní změny do skupin a odevzdávat logicky související změny v jednom příkazu, přičemž jako parametr specifikuje požadovanou sadu změn. V tomto případě zůstanou další úpravy nepotvrzené. Typický příklad: pracuje se na přidání nové funkce a v tu chvíli je objevena kritická chyba, kterou je třeba okamžitě opravit. Vývojář vytvoří sadu změn pro již provedenou práci a novou pro opravy. Po dokončení opravy chyby je dán příkaz k potvrzení pouze druhé sady úprav. přihlásit se, odevzdat, odevzdat Vytvořte novou verzi, potvrďte změny. U některých SUV ( Subversion ) - nová verze se automaticky přenese do úložiště dokumentů. check-out, klon Načtěte dokument z úložiště a vytvořte pracovní kopii. konflikt Konflikt je situace, kdy několik uživatelů provedlo změny ve stejné části dokumentu. Konflikt je detekován, když jeden uživatel potvrdí své změny a druhý se pokusí potvrdit, a systém sám nemůže správně sloučit konfliktní změny. Vzhledem k tomu, že program nemusí být dostatečně chytrý, aby určil, která změna je „správná“, musí druhý uživatel vyřešit konflikt sám ( vyřešit ). štěp, backport, cherry-pick, transplant Použijte vestavěný slučovací algoritmus ve VMS k přenesení jednotlivých změn do jiné větve bez jejich sloučení. Opravili jsme například chybu v experimentální větvi – stejné změny provádíme i ve stabilním kmeni. hlava, kmen Hlavní verze je nejnovější verze pro větev/kmen, která je v úložišti. Kolik větví, tolik hlavních verzí. sloučení, integrace Sloučení je kombinace nezávislých změn do jedné verze dokumentu. Stalo se to, když dva lidé změnili stejný soubor nebo když přesunuli změny z jedné větve do druhé. vytáhnout, aktualizovat Získejte nové verze z úložiště. U některých SUV ( Subversion ) - dojde k vytažení i přepnutí , to znamená, že se načtou změny a pak se pracovní kopie uvede do posledního stavu. Buďte opatrní , aktualizace je nejednoznačná a znamená různé věci v Subversion a Mercurial . TLAČIT Nahrajte nové verze do úložiště. Mnoho distribuovaných VCS ( Git , Mercurial ) předpokládá, že potvrzení musí být dáno pokaždé, když programátor provedl nějakou dokončenou funkci. A vyplňte – až bude internet a ostatní budou chtít vaše změny. Commit obvykle nevyžaduje uživatelské jméno a heslo, ale push ano. rebase Pomocí vestavěného slučovacího algoritmu ve VMS přesuňte bod větvení (verze, ze které větev začíná) do novější verze kmene. Nejčastěji se v tomto scénáři používá: Boris provedl změny a zjistí, že je nemůže prosadit , protože Anna předtím změnila úplně jiné místo v kódu. Můžete je jednoduše sloučit ( merge ). Ale strom bude lineární a čitelnější, pokud opustíte svou revizi, ale provedete stejné změny v Annině revizi – toto je rebase . Pokud Anna a Boris pracují na stejném kusu kódu, vzájemně se ovlivňují a řeší konflikty ručně, rebase se nedoporučuje. úložiště, depot Úložiště dokumentů je místo, kde systém správy verzí ukládá všechny dokumenty spolu s jejich historií změn a dalšími servisními informacemi. revize Verze dokumentu. Systémy pro správu verzí rozlišují verze podle čísel, která jsou přidělována automaticky. police, skrýš Odkládání změn. Schopnost poskytovaná některými systémy vytvořit changeset (changeset) a uložit jej na server bez potvrzení (commit'a). Sada změn nevyřízeného záznamu je čitelná pro ostatní členy projektu, ale není zahrnuta v hlavní větvi, dokud nezadáte speciální příkaz. Podpora odkládání umožňuje uživatelům ukládat rozpracovanou práci na serveru, aniž by pro to vytvářeli samostatné větve. squash Režim roubování/trhání třešní pro celou větev. Jinými slovy, celá větev je potvrzena jako jedna změna. Užitečné pro změny dostatečně velké na to, aby jejich dokončení trvalo několik dní, a dostatečně malé na to, aby neuchovávaly jejich úplnou historii. etapa Vyberte, které změny chcete provést ( odevzdat ) a které ponechat soukromé nebo provést později. pás Odstraňte celou větev z úložiště. štítek, štítek Štítek, který lze přiřadit konkrétní verzi dokumentu. Štítek je symbolický název pro skupinu dokumentů a štítek popisuje nejen sadu názvů souborů, ale také verzi každého souboru. Verze dokumentů obsažené na štítku mohou patřit k různým časovým okamžikům. kmen, hlavní linie, hlavní Kmen je hlavní větví vývoje projektu. Politika kmene se může lišit projekt od projektu, ale obecně je následující: většina změn se provádí v kmeni; je-li vyžadována velká změna, která by mohla vést k nestabilitě, je vytvořena větev , která po dostatečném otestování inovace splyne s kmenem; před vydáním další verze je vytvořena větev pro následující vydání, ve které se provádějí pouze opravy. aktualizovat, synchronizovat, přepínat Synchronizace pracovní kopie do určitého stavu úložiště. Nejčastěji tato akce znamená aktualizaci pracovní kopie na nejnovější stav úložiště. V případě potřeby však můžete synchronizovat pracovní kopii do staršího stavu, než je aktuální. pracovní kopie Pracovní (místní) kopie dokumentů.| Systémy řízení verzí ( kategorie ) | |
|---|---|
| Pouze místní | |
| Klient-server | |
| Distribuováno | |