Git verziószabályozó rendszer. A Git verzióvezérlő rendszer alapjai kezdőknek, akik a SmartGit-et használják példaként

A projektek kidolgozása során a résztvevők gyakran szembesülnek a szinkronizálással és a fájl előzményekkel kapcsolatos problémákkal, amelyeket a verzióvezérlő rendszerek (SUMS) segítenek megoldani. Ennek a cikksornak az a célja, hogy megismertesse az olvasót a SUV működésének elveivel, és részletesen megvizsgálja ezek egyikét, nevezetesen Git-et. Miért? az az utóbbi időben,  ez a rendszer egyre népszerűbb, és fontosságát a szabad szoftverek (és különösen a GNU / Linux projekt esetében) szempontjából nehéz túlbecsülni.

Általánosságban következetesen elemezzük a vezérlőrendszerek jellemzőit, és beszélünk azok architektúrájáról és a kérdéses alkalmazás főbb jellemzőiről. Ezen felül megvizsgáljuk a Gittel való együttműködés meglévő interfészeit.

A szerző szándékosan kihagyja a funkciók, a kulcsok és az egyéb finomságok terminológiáját annak érdekében, hogy világosan, érthetően és általános formában ábrázolja a képet. Ez a cikk feltételezi, hogy az olvasó ismeri az Unix-szerű operációs rendszereket (OS), és alapvető ismeretei vannak az algoritmusokról és általában a számítógépes ismeretekről.

A következő anyagokban áttekintjük Git felépítését és filozófiáját, ennek a rendszernek a sajátosságait és a vele gyakorlati munka finomságait. A Git és más SUV-ok (például Subversion, CVS, Mercurial stb.) Kölcsönhatásáról szóló cikk véget vet a ciklusnak.

2. Git ...

A Git egy elosztott fájlverzió-vezérlő rendszer. A programkód elsősorban C-ben van írva. A projektet Linus Torvalds készítette 2005-ben a Linux kernel fejlesztésének irányítására, és hasonlóan a GNU / Linuxhoz, ez egy ingyenes szoftver (szoftver), és a harmadik fél általi felhasználásra a GNU GPL 2. verziója vonatkozik. Röviden Ez a megállapodás szabadkódú szoftverként írható le, amelyet nyíltan kell fejleszteni, azaz bármely programozónak joga van a projekt továbbfejlesztését bármely szakaszában. Rövid ideje alatt ezt a rendszert  sok vezető fejlesztő vezette be. A Git-et olyan projektekben használják, amelyek a Linux közösség számára ismertek: Gnome, GNU Core Utilities, VLC, Kairó, Perl, Chromium, Wine.

3. Verziókezelő rendszerek

A Version Control Systems (Version Control Systems) egy olyan fájl, amelynek célja egy fájl (vagy fájlcsoport) történetének automatizálása, a változások figyelése, az adatok szinkronizálása és a projekt biztonságos tárolójának megszervezése. Röviden: a verzióvezérlő rendszerek fő célja az, hogy megkönnyítsék az információ megváltoztatását. Elemezzük a fejlesztés általános nézetét egy példa segítségével.

Tegyük fel, hogy van egy bizonyos projekt, amelyet fejleszt, több programozói részleg és te vagy a koordinátor (vagy vezető). A vezérlőrendszerrel kapcsolatban, függetlenül attól, hogy szerver (ha ez egy központi rendszer) vagy helyi gép - a projektfejlesztőket csak a fájlverziók módosítására és / vagy olvasására vonatkozó hozzáférési jogok korlátozzák ezt a lerakatot. Az adatokat bármikor visszaállíthatja a szükséges verzióra. Ön, mint koordinátor, korlátozhatja bizonyos felhasználók hozzáférését a fájl verziójának frissítéséhez. A SUV felülettel rendelkezik a fájl verziók megfigyelésére és keresésére is. Például létrehozhat egy lekérdezést: “Hol és mikor változott ez a kóddarab?”.

A rendszer feltételezi a biztonságos adattárolást, azaz minden benne tárolt blokk sok klónt tartalmaz. Tehát például, ha egy fájl sérült, akkor időben cserélheti le egy példányára. A projekt adatainak csökkentése érdekében gyakran használnak delta tömörítést - egy olyan típusú tárolást, amelyben nem maguk a fájlverziók vannak tárolva, hanem csak az egymást követő javítások között változnak.

4. Különbségek az elosztott verziószabályozó rendszerek között

Az elosztott verzióvezérlő rendszerek SUV-k, amelyek fő paradigmája az egyes projektfejlesztők adatainak lokalizálása. Más szavakkal: ha egy centralizált SUV-ban minden művelet, úgy vagy úgy, egy központi objektumtól (kiszolgálótól) függ, akkor egy elosztott SUV-ban minden fejlesztő a teljes projekt saját verzióját tárolja. Egy ilyen rendszer kényelme az, hogy minden fejlesztőnek lehetősége van önállóan dolgozni, alkalmanként cserélve a közbenső fájl opciókat más projekt résztvevőivel. Vegye figyelembe ezt a funkciót, folytatva az előző példát.

A gépen minden fejlesztőnek megvan a saját helyi repozitóriuma - egy hely a fájlverziók tárolására. A projekt adatokkal történő munka a helyi tárházban valósul meg, és ehhez nem szükséges a többi (még a fő) fejlesztési ággal tartani a kapcsolatot. Más adattárakkal való kapcsolat csak akkor válik szükségessé, ha más ágak fájlverzióját módosítja / olvassa. Ugyanakkor minden projekt résztvevője megszabja a saját tárolási jogát az olvasáshoz és az íráshoz. Így az elosztott SUA-ban az összes ág egyenlő egymással, és a koordinátor kiválasztja közülük a főet. A fő ág csak abban különbözik, hogy a fejlesztők szellemileg egyenlővé teszik.

5. A Git főbb jellemzői

Érdemes azt mondani, hogy a rendszer, ha nem csillogott, akkor kissé felrázta a SUV területén a közösséget újdonságával, és új fejlesztési utat javasolt. A Git rugalmas és könnyen használható eszközöket biztosít a projekt történetéhez.

A Git jellemzője, hogy a projekt verziókkal való munka nem időrendi sorrendben zajlik. A fejlesztés több párhuzamos ágban is elvégezhető, amelyek a tervezés során bármikor összeolvadhatnak és megoszthatók.

A Git meglehetősen rugalmas rendszer, és hatóköre nem korlátozódik a fejlesztés körére. Például az újságírók, a szakirodalom szerzői, az adminisztrátorok és az egyetemi oktatók felhasználhatják ezt saját tevékenységükben. Ezek a feladatok magukban foglalják az összes dokumentáció, jelentés, házi feladat verziókezelését.

Kiemeljük a Git és a többi elosztott és központosított SUV közötti főbb különbségeket.

Git építészet

Az SHA1 (Secure Hash Algorithm 1) egy kriptográfiai kivonási algoritmus. A projekt minden egyes fájlja egy nevet és tartalmat tartalmaz. A név az első 20 bájt adat, vizuálisan negyven karakterből áll, a hexadecimális számrendszerben. Adott kulcs  amelyet a fájl tartalmának kivonásával kapunk. Tehát például a két név összehasonlításakor szinte száz százalékos valószínűséggel mondhatjuk, hogy azonos tartalommal rendelkeznek. Ugyanakkor a különféle ágakban (adattárakban) lévő azonos objektumok neve ugyanaz, ami lehetővé teszi az adatok közvetlen működtetését. Jó kiegészítő  A fentiekben említettek szerint a hash lehetővé teszi a fájlok sérülésének pontos meghatározását. Például, összehasonlítva a tartalom kivonatát a névvel, pontosan meg tudjuk mondani, hogy az adatok sérültek-e vagy sem. Ezenkívül a név alatt a fájl nevét értjük, és a karakterláncot SHA1 hash-nak nevezzük.

Érdemes megemlíteni az úgynevezett ütközéseket. A „helyesen határozza meg a sérülést” azt jelenti, hogy vannak olyan, eltérő tartalmú fájlok, amelyek SHA1-kivonása azonos. Az ilyen ütközések valószínűsége nagyon alacsony, és az előzetes becslések szerint a -80-as foknál 2 (a -25 fokon ~ 10). Nincs pontos becslés, mivel a világközösség jelenleg nem volt képes hatékonyan visszafejteni ezt a kriptográfiai sémát.

Git tárgyakat

A Git fájlverzióival való munka összehasonlítható a szokásos fájlrendszer-műveletekkel. A struktúra négy típusú objektumból áll: Blob, Fa, Commit és References; néhányuk viszont alobjektumokba oszlik.

Blob (bináris nagy objektum) - egy adattípus, amely csak a fájl tartalmát és a saját SHA1 kivonatát tartalmazza. A Blob a fő és egyetlen adathordozó a Git-keretrendszerben. Párhuzamot húzhat az objektum és a fájlrendszerek inódjai között, mivel azok felépítése és célja nagyon hasonló.

Fa (fa)

• saját SHA1 hash;
• SHA1 hasábfoltok és / vagy fák;
• unix rendszerek hozzáférési jogai;
• az objektum szimbolikus neve (név a rendszer belső használatához).

Magában az objektum egy könyvtár analógja. Meghatározza a projekt fájlok hierarchiáját.

Commit  - adattípus, amely tartalmazza:

• saját SHA1 hash;
• pontosan egy fához mutató link;
• link az előző kötelezettségvállaláshoz (lehet több)
• a szerző neve és az elkötelezettség létrehozásának ideje;
• az elkövető neve (elkövető - az a személy, aki elkötelezett az adattárban, eltérhet a szerzőtől) és a kötelezettségvállalás alkalmazásának ideje;
• tetszőleges adat (a blokk felhasználható elektronikus aláírásra vagy például az elkötelezettség változásainak magyarázatára).

Ezt az objektumot egy fájlcsoport pillanatképének (verziójának) tárolására tervezték egy adott időpontban, összehasonlíthatják egy vezérlőponttal. A kötelezettségvállalások összevonhatók, elágazhatnak, vagy létrehozhatnak például egy lineáris struktúrát, tükrözve ezáltal a projekt verzióinak hierarchiáját.

Referencia - adattípus, amely linket tartalmaz a négy objektum bármelyikéhez (Blob, Fa, Commit és References). Fő célja, hogy közvetlenül vagy közvetve mutatjon egy objektumra, és szinonimája legyen annak a fájlnak, amelyre hivatkozik. Ez növeli a projekt struktúrájának megértését. Nagyon kényelmetlen a név értelmetlen karakterkészlettel történő üzemeltetés, ám egy link, az SHA1 kivonattal ellentétben, megnevezhető, mivel a fejlesztő számára kényelmesebb.

A linkektől viszont számos alobjektumot különböztethetünk meg, amelyeknek van némi eltérése: Branch, Tag. Fontolja meg őket.

Ág (vezető, ág) - szimbolikus link (szimbolikus link), amely az utolsó ágra mutat egy adott ág kötelező kronológiájában, és tárolja az objektum SHA1 kivonatát. A naplózó fájlrendszerek adattípusa. Az ilyen típusú objektumot nem a Git határozza meg, hanem az operációs és fájlrendszerből örökölte. Az ágot szinonimának használják annak a fájlnak, amelyre hivatkozik, azaz A Git lehetővé teszi a közvetlen működtetését. Megengedheti magának, hogy ne gondoljon arra, hogy a legújabb verzióval dolgozik-e vagy sem.

Tag (tag)  - egy adattípus, amely az ágakkal ellentétben mindig ugyanazon objektumra utal, mint például blob, fa, átadás vagy címke. Ezt viszont fel lehet osztani könnyű és könnyű vagy megjegyzéses címkére. A fényjelző a kapcsolat megváltoztathatatlansága mellett nem különbözik a közönséges ágaktól, azaz csak a hivatkozott objektum SHA1 kivonatát tartalmazza önmagában. A feliratozott címke két részből áll:

• az első rész a saját SHA1-kivonatát tartalmazza;
• a második rész a következőkből áll:
  • Az objektum SHA1, amelyre a megjegyzéshez csatolt címke mutat;
  • a megjelölt objektum típusa (blob, fa, elkötelezettség vagy címke);
  • a címke szimbolikus neve;
  • a címke létrehozásának dátuma és időpontja
  • a címkekészítő neve és e-mail címe;
  • tetszőleges adat (ez a blokk felhasználható elektronikus aláíráshoz vagy egy címke magyarázatához).

Más szavakkal, egy projekt Gitben olyan blobok gyűjteménye, amelyeket fák hálózata kapcsol össze. Az eredményül kapott hierarchikus struktúra az időtől függően visszafordulhat az elkövetési verziók formájában, és hogy megértsék azok szerkezetét a Gitben, vannak olyan objektumok, mint a hivatkozások. A linkekkel végzett műveletek kivételével a rendszerobjektumokkal való szinte minden munka belülről van a lehető leg automatizáltabb. A linkmechanizmus alapján a következő ötlethez jutunk: dolgozzunk fájlcsoportokkal. A szerző szerint az ötlet kulcsfontosságú Git filozófiájában. Például egy művelet megadásával egy adott megbízáshoz rekurzívan kidolgozza a részét a fában, amelyre hivatkozik. Az általánosan elfogadott „művelet az egyes fájlokon” nézet kiterjesztéseként az innováció leegyszerűsíti a programozó megvalósítását és megközelítését a SUV mindennapi feladataira, például az ágak egyesítésére / felosztására, a folyamat ismét rekurzív automatizálására. Ez a megközelítés könnyen érthető, gyors működésű és rugalmas a célok megvalósításában. Ezeknek a szolgáltatásoknak a sokát az Unix-orientált rendszernek köszönhetően érik el, azaz szabványos eszközökkel működve, a Git a jelenleg létező eszközökre támaszkodik operációs rendszer  megoldásokat.

Pontosítsuk az adattárolás pillanatát. A kronológiában szereplő különféle verziók fájljainak tartalma sok memóriát igényel. Tehát például egy húsz fájlból álló, húsz verziójú projektben az archívum 20-szor nagyobb (talán körülbelül száz megabájt), és mi fog történni, ha ezeknek és másoknak a száma tízszeres (úgy tűnik, hogy nem sok)? Az elfoglalt hely mérete 100-szor növekszik (azaz körülbelül 1 GB). Valódi problémák esetén az elfoglalt memória növekedési üteme messze nem lineárisan függ az időtől. A probléma megoldására számos optimalizálás lehetséges:

• minden Git objektumot rendes archívumként tárol (tar.gz);
• a szekvenciális delta tömörítést a teljes fájlhierarchiához kell használni.

Vegyünk egy példát.

Három éves története van a projektjének, benne mintegy ezer fájl és száz változat található. Ha valamikor el kell lépnie a legkorábbi verzióra, akkor Gitnek ki kell csomagolnia a teljes fájl előzményeinek delta tömörítését. Csalódás, de ez a folyamat délig tarthat. Git javasolja az úgynevezett csinálást ellenőrző pontok, azaz tároljon egy heti archivált fájlt számos verzión keresztül, amelyeket a tömörítési mélységnek hívunk. Ezután a példánkban az egész történet egy meghatározott előre meghatározott számú delta-tömörítésre szűkíthető, és kibontva őket, megnézheti a kronológia bármely verzióját. Vegye figyelembe, hogy a delta tömörítést a legmegfelelőbb a hierarchiához legközelebb eső bizonyos objektumtípusok felett alkalmazni, ehhez az adattárat típus és méret szerint kell osztályozni. Az ebben a szakaszban ismertetett műveletsorozatokat a git-repack függvény (és az azt tartalmazó git-gc) hajtja végre.

Ágak egyesítése és felosztása

Ez a kérdés nagyon fárasztó és telített, ezzel összefüggésben csak általános módon vezetjük be az egyesülés és szétválás fogalmát. Nézzük meg ismét egy példát.

Képzelje el a projektfejlesztés pillanatát, amikor a fő cél a program sebessége. Az egyik lehetséges taktikai megoldás a fejlesztők két csoportra osztása, amelyek mindegyike ugyanazt a problémát oldja meg. Ebben az esetben a projekt történetének ágát meg kell osztani. Ez az eljárás  úgynevezett ág. A fióktelep elágazása egyszerűen létrehozza annak egy példányát, amelynek később megvan a maga története.

Tegyük fel ugyanazon feladat két, már elkészült eredményét, amelyen két programozói csoport dolgozott. Hogy lehetünk? Lásd, kinek a kódja gyorsabb és megbízhatóbb? Ez túl könnyű, de nem mindig a legjobb megoldás. Jó megoldás az, ha a kódot és a fájlokat kissé megértjük, részfeladatokra vagy kódblokkokra osztjuk őket. És csak akkor azonosíthatjuk ezeknek a daraboknak az erősségeit és gyengeségeit. Természetesen ez a lehetőség csak akkor megfelelő, ha előre előre látta, hogy ezeket a részecskéket később össze lehet gyűjteni. Az a helyzet, amikor saját maga fejleszti ki a kódot, bizonyos hibák javítása és kijavítása megegyezik a megadott példával. Ez a folyamat  két egész szám összevonását egyesítésnek nevezzük. A projekt legfontosabb pontja a két verzió kombinációja. Bárhogy is legyen, kerülje a művelet automatikus végrehajtását. A Git megkülönböztető tulajdonsága a legmegbízhatóbb és legmegfelelőbb gyors út  az elágazási probléma megoldása.

A rendszer előnyei a következők:

1. Unix orientáció
2. Ideológiai következetesség (a rendszer használatának szabályait követve nagyon nehéz bejutni reménytelen helyzet  vagy szerezze meg azt, amire nem számított.
3. Nagy teljesítmény (ez a rendszer egyik legszembetűnőbb előnye, amelynek kifizetése az "ideológiai fenntarthatóság" és az "Unix-orientált").
4. Git-integráció harmadik féltől származó ellenőrző rendszerekkel, például a Subversion, a Mercurial, ...
5. Egy fájlcsoport kezelése (a rendszernek nem kell külön megfontolnia az egyes fájlokban bekövetkező változásokat, és a teljes projektben megjegyzi a változásokat, és ha hirtelen meg kell nyomon követnie az egyes módosításokat, akkor pontosan azt a részt adja ki, amely ehhez a fájlhoz társult).
6. Összevonási művelet (egy összetett feladat leg automatizáltabb végrehajtása).

A hátrányok között szerepel:

1. Unix-orientáció (érdemes megjegyezni, hogy a Git ésszerűen nem valósult meg a nem Unix rendszereken).
2. A git-gc parancs időszakos végrehajtásának szükségessége (csomagolja a fájlcsoportokat, és törli azokat, amelyeket nem hivatkoznak egymással).
3. Hasító ütközések (a különböző tartalomú fájlok SHA1 kivonatának megfelelő).

6. Git interfészek

"Hány ember, oly sok vélemény." Próbáljuk megvilágítani a rendszerrel való interfész számos típusát. Bizonyos célokra az alábbi alkalmazástípusok mindegyike jobb a maga módján.

Azok számára, akik nem vesznek részt szorosan a fejlesztésben, a „konzervatívok” számára - akik szeretik a „gombokat és a jelölőnégyzeteket”, és akik tudatosan meg akarják védeni magukat a funkciók, a kulcsok és a sok apróság finomata erőfeszítésektől, a TortoiseGit vagy a Git kiterjesztés stílusában a lehetőség megfelelőbb - egyszerű interfészek. Ezek lehetővé teszik, hogy főként az egérrel cselekedjen, és sokak számára a szokásos Windows operációs rendszerben dolgozzon.

Pontosan az ellenkező típusú interfész. Azoknak a programozóknak, akiknek állandóan kapcsolatba kell lépniük az alkalmazottakkal, meg kell oldaniuk a kódvezérlés tipikus feladatait, és azok számára, akik megszokták a terminált használó Unix-szerű rendszerekben dolgozni, az alkalmazások konzolnézete a legmegfelelőbb. Könnyen kezelhetők, kicsit gyorsabbak és funkcionálisabbak, de időre van szükségük ahhoz, hogy kitalálják, hogyan kell használni.

Megkülönböztethetjük a harmadik típusú interfészt - az első kettő keverékét. Ie van egy konzol alkalmazás, például egy “natív” git shell. Számos további segédprogramot, például Gitk vagy QGit, használhat a fák megjelenítéséhez, a verzióhierarchia áttekintésének, a verziók közötti különbségek egyszerűsítésének és a szükséges objektumok keresésének egyszerűsítéséhez.

7. Következtetés

Tehát az olvasók már rájönnek, hogy a modern verzióvezérlő rendszerek hogyan működnek. Ezen felül áttekintettük az egyik legnépszerűbb rendszer - a Git - architektúráját. A következő cikkben megpróbáljuk megismerni annak néhány jellemzőjét a gyakorlatban - megvizsgáljuk a funkciókat és azok kulcsát. A cikk számos szemléltető példát ad a fájltörténet fenntartásáról, valamint az elosztott rendszerek filozófiájáról. A szerző megpróbálja megmutatni az olvasóknak, hogyan kell helyesen használni a Git-t, és megvizsgál néhány tipikus hibát a GMS használatában.

A fejlesztéssel kapcsolatosak közül sokan szoftverhallottam a gitről. Mi ez a három betű? Nagyon fontos megérteni a leírást és a működés alapelveit annak érdekében, hogy hatékonyan használhassuk ezt a verziószabályozó rendszert, amelyben - más hasonló rendszerekkel ellentétben - teljesen eltérő információkoncepciók működnek vele, a hasonló felhasználói felület. Szóval mi a git?

leírás

A Git a fejlett fájlok elosztott verziókezelő rendszere. 2005-ben a Linux operációs rendszer szerzője hozta létre. Ez a rendszer szinkronizálja a munkát a webhellyel, és a fájlok módosításait is menti és frissíti. Ez nagyon kényelmes megközelítés, ha több fejlesztő dolgozik egy projekten. Manapság sok közismert projekt pontosan a Git-et használja. Mit ad a használat? Például egy operációs rendszer fejlesztése android rendszerek  számos programozóval foglalkozik. Rendkívül kényelmetlen lenne, ha egyikük változtatna, míg a többi nem tud róla. A Git lehetővé teszi mindenkinek, hogy lépést tartson az összes változással, és hibák esetén térjen vissza korábbi verziók  fájlokat.

Helyezések helyett öntések használata

A Git és a többiek közötti fő különbség az, hogy hogyan néz ki az adat. A legtöbb program az információkat a fájlok javításának nevezett változtatások listájaként tárolja. Az ilyen rendszerek a tárolt adatokra mint fájlkészletre vonatkoznak, valamint az egyes fájlokhoz az idő függvényében végrehajtott változtatásokra. Hogyan tárolja a Git adatait? Mi különbözteti meg ezt a rendszert másoktól? A javítások helyett az itt tárolt adatok egy kis fájlrendszer rögök sorozatának tekinthetők. Amikor egy felhasználó elkészíti a projekt új verzióját, a rendszer egyszerűen pillanatfelvételt készít a fájlok aktuális állapotáról. A hatékonyság növelése érdekében abban az esetben, ha a fájlt nem változtatták meg, a rendszer nem menti el, hanem egy linket hoz létre egy korábban elmentett példányhoz, amelyben a legutóbbi módosításokat végrehajtották.

Ez nagyon fontos különbség a többi vezérlőrendszerhez képest, ami a Git-ben rejlik. Mi a különbség? Git olyan lesz, mint egy kicsit fájlrendszernagyon erős eszközökkel, amelyek működnek rajta.

Leginkább helyi műveletek

A legtöbb művelet Gitben történő végrehajtásához csak helyi erőforrásokra és fájlokra van szüksége. Ez azt jelenti, hogy a hálózat többi számítógépén általában nincs szükség információra. Mivel az összes projektmódosítás lemezen van, a műveleteket villámsebességgel hajtják végre. Például egy projekt előzményeinek megtekintéséhez nem kell letölteni a szerverről. A számítógép helyi lerakatából olvasható le. Ha látnia kell a változásokat a fájl egy hónappal ezelőtt készült verziója és a jelenlegi változat között, akkor ezt nagyon gyorsan megteheti anélkül, hogy a kiszolgálóra kellene mennie.

A helyi munka azt is jelenti, hogy sok mindent megtehet anélkül, hogy csatlakozna a hálózathoz. Például egy fejlesztő változtatásokat hajthat végre szállítás közben. Sok vezérlőrendszerben ez nem lehetséges.

Az adatok integritásának figyelése

Bármely fájl mentése előtt hozzárendel egy indexet egy ellenőrző összeg formájában, amelyet közvetlenül a Git kiszámít. Mi az Ez az érték, amelyet speciális algoritmusok segítségével számítanak ki, és az adatok integritásának ellenőrzésére szolgálnak tárolásuk és továbbításuk során. Git ismerete nélkül itt semmit sem lehet megváltoztatni, és ez a rendszer filozófiájának fontos alkotóeleme.

Az adatokat általában hozzáadják.

Szinte az összes, a Gitben végrehajtott művelet hozzáadódik az adatbázishoz. Távolítani őket nagyon nehéz. Csak azokat az információkat veszítheti el, amelyeket még nem ment meg, de amikor elkötelezték őket, az elvesztés kizárt. Ez az oka annak, hogy sokan a Git-et választják, mert itt kísérletezhet anélkül, hogy kockázat nélkül csinálhat helyrehozhatatlan dolgot.

Fájl állapota

A kezdő kezdőknek szóló Git-vel történő munka során emlékezni kell arra, hogy a fájl három állapot egyikében lehet:

• Elkötelezett, vagyis a fájlt a helyi tárolóba menti.
• Szerkesztéskor módosult, de a mentés még nem fejeződött be.
• Kész - módosított fájlok, amelyek meg vannak jelölve a mentésre.

Tehát a Git-t használó projektekben három szakasz található a különféle fájlállapotokra:

• A Git könyvtár, ahol a metaadatok tárolódnak, valamint az objektumok adatbázisa. A rendszer ezen része a legfontosabb.
• A működő könyvtár, amely a projektnek az adatbázisból kibontott verziójának másolata.
• A későbbi mentéssel kapcsolatos információkat tartalmazó fájl.

Telepítse a Git szoftvert

A verziószabályozó rendszer használatához az első lépés, amelyet telepíteni kell. Ennek többféle módja van. A legfontosabb két lehetőség:

• Telepítse a Git-t a forrásból.
• A csomag telepítése a platformhoz.

Telepítse a Git-t a forrásból

Ha ez lehetséges, akkor jobb használni ezt a lehetőséget, mivel a legtöbb friss verzió. Minden frissítés általában számos hasznos fejlesztést tartalmaz, ezért ha a forrásból történő telepítés nem túl nehéz a számodra, akkor jobb, ha azt részesíted előnyben. Igen, és a legtöbb Linux disztribúció tartalmaz korábbi csomagokat.

A telepítéshez szüksége lesz a szükséges könyvtárakra: expat, curl, libiconv, openssl, zlib. A telepítés után letöltheti legújabb verzió  verzióvezérlő rendszer, fordítsa le és telepítse.

Windows telepítése

Ha a felhasználónak nincs Linuxja, de a Git használatát akarja, a Windows szintén támogatja ezt a rendszert. És a telepítése nagyon egyszerű. Van egy msysGit projekt, amelynek telepítési eljárása az egyik legegyszerűbb. Csak le kell töltenie a telepítő fájlt, amely megtalálható a GitHub projekt oldalán, majd futtatnia kell. A telepítés végén két változat lesz a számítógépen - grafikus és konzol.

Indítsa el a kezdeti beállításokat

Miután a vezérlőrendszert telepítette a számítógépre, végre kell hajtania néhány műveletet a felhasználó környezetének konfigurálásához. Ez egyszer megtörténik. Frissítéskor az összes beállítás elmentésre kerül. Bármikor megváltoztathatók.

A Git tartalmazza a git config segédprogramot, amely lehetővé teszi a beállításokat és a rendszer működésének vezérlését is megjelenés. Ezek a paraméterek három helyen tárolhatók:

• Egy fájlban, amely minden felhasználó és adattár közös értékeit tartalmazza.
• Egy adott felhasználó beállításait tartalmazó fájlban.
• Az aktuális lerakatban található konfigurációs fájlban. Ezek a paraméterek csak rá vonatkoznak.

egyéni nevet

Mindenekelőtt a telepítés után meg kell adnia a felhasználónevet és a felhasználót e-mail. Ez nagyon fontos, mivel minden kötelezettségvállalás (állapotmegőrzés) tartalmazza ezeket az adatokat. Az összes elkötelezett kötelezettségvállalásba beletartoznak, és később nem módosíthatók.

Ha megadja a -global beállítást, akkor ezeket a beállításokat egyszer kell elvégezni.

Szövegszerkesztő kiválasztása

A név megadása után ki kell választania azt a szerkesztőt, amelyre szükség lesz az üzenetek Gitbe történő gépelésére. Alapértelmezés szerint a szokásos operációs rendszer-szerkesztőt fogjuk használni. Ha a felhasználó egy másik felhasználót akar használni, regisztrálnia kell a core.editor sor konfigurációs fájljában.

A paraméterek ellenőrzése

A Git alapjainak megismeréséhez képesnek kell lennie a használt beállítások ellenőrzésére. Ehhez használja a config -list parancsot. Megjeleníti az összes elérhető paramétert, amelyet megtalál. Egyes beállításnevek többször is megjelenhetnek a listán. Ennek oka az, hogy Git beolvassa a kulcsot a különféle fájlokból. Ebben a helyzetben az egyes kulcsokhoz az utolsó értéket kell használni. Bizonyos kulcsok értékeit ellenőrizheti a „--list” - „(key)” helyett a parancs beírásával.

Hogyan lehet létrehozni egy lerakatot?

Kétféle módon érhetjük el ezt a célt. Az első egy meglévő katalógus vagy projekt importálása a rendszerbe. A második a meglévő tároló klónozása a kiszolgálón.

Létrehozás ebben a könyvtárban

Ha a felhasználó úgy dönt, hogy elkezdi használni a Git-t egy meglévő projekthez, el kell mennie a könyvtárba, és inicializálnia kell a rendszert. Ehhez a git init parancsra van szükség. Ő létrehoz egy alkönyvtárat a könyvtárban, ahol mindenki ott lesz szükséges fájlok. Ebben a szakaszban a projekt verziószabályozása még nem jött létre. Az ellenőrzés alatt álló fájlok hozzáadásához indexelnie kell azokat és végre kell hajtania az első változtatásokat.

Tároló klónozása

Meglévő lerakat másolatának megszerzéséhez szükség van a git clone parancsra. Ezzel a Git szinte az összes adatot megkapja a szerverről. Ez vonatkozik az egyes fájlok minden verziójára. Nagyon kényelmes szolgáltatás, mivel szerver meghibásodása esetén a programozó bármely kliensen felhasználhatja a klónt, hogy visszatérje a szervert az állapotába, amelyben a klónozás volt. Úgy néz ki, mint egy helyreállítási pont.

Töröljön egy fájlt a Git-ben

Bármely fájlt törölhet a rendszerből, ha kizárja az indexből, azaz a megfigyelt fájlokból. Ehhez szüksége van a git rm parancsra. Emellett eltávolítja a fájlt a felhasználó munkakönyvtárából. Akkor el kell vállalnod. Ezután a fájl egyszerűen eltűnik, és nem lesz követhető. Ha megváltoztatják és már indexelték, akkor a -f opcióval kényszerített törlést használunk. Ez a módszer megakadályozza az olyan adatok törlését, amelyeket még nem készített a pillanatképbe, és amelyeket nem lehet visszaállítani a rendszerből.

Visszaváltás

Előfordulhat, hogy bármikor törölnie kell egy műveletet. Ha a felhasználó korábban végrehajtotta a kötelezettségvállalást, elfelejtett néhány fájlt hozzáadni, akkor a --amend opcióval túlteljesen kitöltheti. Ez a parancs az index végrehajtására szolgál. Ha az utolsó mentés után nem történt változás, akkor a projekt ugyanabban az állapotban lesz, és megjelenik egy megjegyzés szerkesztője, ahol a felhasználó mindent szerkeszthet, amire szüksége van. Ne feledje, hogy nem minden törlési műveletet lehet visszavonni. Időnként véglegesen törölheti a szükséges adatokat. Legyen óvatos.

találatok

Most a felhasználónak elképzelést kell kapnia arról, hogy mi a Git, miért van szükség erre a verziószabályozó rendszerre, hogyan különbözik más hasonló termékektől. Nyilvánvaló, hogy a teljes bevezetéshez telepíteni kell a Git működő verzióját személyes beállításokkal. A Git-ről szóló, a "próbabábuk" számára készített bármely tankönyv vagy videó tanfolyam nem bántja a felhasználót, amely lépésről lépésre bemutatja a felhasználót a rendszerrel végzett munka minden szakaszában.

Ez a fejezet a Gittel való kezdésről szól. Először tanuljuk meg a verziókezelő rendszerek alapjait, majd folytassuk a Git futtatásának az operációs rendszeren, és végül konfiguráljuk úgy, hogy működjön. A fejezet végén már tudni fogja, mi a Git és miért kell azt használni, és megkap egy olyan rendszert is, amelyet végül konfiguráltak működésre.

A verziókezelésről

Mi az a "verziókezelő rendszer" és miért fontos? A verziókezelő rendszer egy olyan rendszer, amely idővel módosít egy fájlt vagy fájlkészletet, és lehetővé teszi, hogy később visszatérjen egy adott verzióhoz. A szoftver forráskódját példaként fogjuk használni a könyv fájlverzióinak ellenőrzésére, bár valójában szinte bármilyen fájltípushoz használhatjuk a verziószabályozást.

Ha Ön grafikus vagy webdesigner, és el akarja menteni a kép vagy az elrendezés minden verzióját (valószínűleg ezt akarja), a verzióvezérlő rendszerre (a továbbiakban: SLE) éppen szüksége van. Ez lehetővé teszi a fájlok visszaállítását abban az állapotban, amelyben a módosítások előtt voltak, a projekt visszatérését kezdeti állapot, megnézheti a változásokat, megnézheti, ki változtatott valami utoljára és okozta a problémát, ki állította be a feladatot, mikor és még sok más. Az SLE használata általában azt is jelenti, hogy ha valamit megszakít vagy fájlokat veszít, akkor könnyen megjavíthatja. Mindent megtesz, mindezt extra erőfeszítés nélkül.

Helyi verziószabályozó rendszerek

Sokan a fájlok másolását külön könyvtárba használják verziószabályozási módszerként (esetleg akár időbélyegzővel ellátott könyvtárat is, ha elég okosak). Ez a megközelítés nagyon egyszerű az egyszerűség miatt, de hihetetlenül hajlamos a hibákra. Könnyedén elfelejtheti, hogy melyik könyvtárban van, és véletlenül megváltoztathatja a rossz fájlt, vagy másolhatja a kívánt fájlokat.

A probléma megoldása érdekében a programozók régen kifejlesztettek egy helyi kemény valutát egy egyszerű adatbázissal, amely tárolja a fájlokban bekövetkezett összes változás nyilvántartását, ezáltal ellenőrizve a javításokat.

1. ábra. Helyi verzióvezérlés.

Az egyik népszerű kemény valuta az RCS rendszer volt, amelyet ma sok számítógéppel forgalmaznak. Még a népszerű Mac OS X is biztosítja az rcs parancsot a Fejlesztői eszközök telepítése után. Az RCS a lemezen javításkészleteket (fájlok közötti különbségeket) tárol egy speciális formátumban, amelynek segítségével újra létrehozhatja az egyes fájlok állapotát egy adott időpontban.

Centralizált verziókezelő rendszerek

A következő komoly probléma, amellyel az emberek szembesülnek, az, hogy kapcsolatba kell lépni más fejlesztőkkel. Ennek kezelése érdekében központi verziókezelő rendszereket (CSCV) fejlesztettek ki. Az olyan rendszereknek, mint a CVS, a Subversion és az Perforce, egyetlen kiszolgáló van, amely a fájlok összes verzióját tartalmazza, és számos olyan ügyfél, amely fájlokat fogad ebből a központosított lerakatból. A CCSC használata évek óta szabvány.

2. ábra: Centralizált verzióvezérlés.

Ennek a megközelítésnek számos előnye van, különösen a helyi kemény valutához képest. Például, minden projektfejlesztő bizonyos mértékben tudja, mit csinál. A rendszergazdák teljes mértékben ellenőrzik, hogy ki mit csinálhat, és a CCSV-k adminisztrálása sokkal könnyebb, mint a helyi adatbázisok működtetése az egyes klienseken.

Ennek ellenére ennek a megközelítésnek komoly hátrányai vannak. A legnyilvánvalóbb mínusz a központi szerver által képviselt egyetlen hibapont. Ha ez a szerver egy órán keresztül meghibásodik, ezen idő alatt senki sem fogja tudni használni a verzióvezérlést a dolgozó változtatások mentésére, és senki sem fogja megosztani ezeket a változásokat más fejlesztőkkel. ha merevlemez, ahol a központi adatbázis tárolása megsérült, és nincs időben történő biztonsági mentés, mindent el fog veszíteni - a projekt teljes története, nem számítva a tároló egyetlen pillanatképeit, amelyeket a fejlesztők helyi gépeire mentettek. A helyi kemény valuta ugyanazt a problémát érinti - ha a projekt teljes története egy helyen tárolódik, akkor mindent elveszíthet.

Decentralizált verziókezelő rendszerek

Itt kerülnek a decentralizált verzióvezérlő rendszerek (DSCW) használatára. A DSCW-ben (például Git, Mercurial, Bazaar vagy Darcs) az ügyfelek nem csak letöltik az összes fájl pillanatképét (a fájlok állapota egy adott időpontban): teljes mértékben lemásolják a lerakatot. Ebben az esetben, ha az egyik kiszolgáló, amelyen keresztül a fejlesztők adatcserét folytattak, meghal, az ügyfél-lerakat másolható egy másik kiszolgálóra a munka folytatása érdekében. A tároló minden példánya az összes adat teljes biztonsági másolatát képezi.

3. ábra. Decentralizált verzióvezérlés.

Sőt, sok DSCW egyidejűleg kölcsönhatásba léphet több távoli adattárral, így különféle embercsoportokkal dolgozhat, különböző megközelítéseket alkalmazva ugyanabban a projektben. Ez lehetővé teszi számos megközelítés alkalmazását a fejlesztésben, például a hierarchikus modelleket, ami teljesen lehetetlen a központosított rendszerekben.

Nemrég tartott, hogy megtanítsam Git alapjait több alkalmazottomnak, akik éppen programozást tanulnak és dolgozni próbálnak. Miután az interneten kezdő cikkeket kerestem, rájöttem, hogy legtöbbjük arról szól, hogyan kell használni a Git konzolt, vagy annak szükségességéről és előnyeiről más hasonló rendszerekkel szemben. A kezdõ általában nem nagyon erõs ezekben a kérdésekben. Úgy gondolom, hogy a kezdőknek nem kell mindent tudnia. Végül is használhatja a Git projektekhez, és megtanulhatja az összes varázsát a programozás tanulmányozásával párhuzamosan. azonbannagyon javaslom, hogy ezt a cikket tényfeltáró cikkként vegye figyelembe, és többet megtudjon a Gitről a jövőben..

Általában egy macskacikk alatt, mint használóSmartGit és BitBucket   Javíthatja életét kezdő fejlesztőként.

M scarlet terv, hogy mit fogunk csinálni:

1. Lerakat létrehozása a Bitbucket-en.
2. Repository klónozása (hozzáadása a SmartGithez).
3. Kötelezettségvállalások létrehozása.
4. Dobja el a változásokat.
5. Hozzon létre ágakat.
6. Ágak áthelyezése egy távoli lerakatba (ágai feltöltése egy távoli kiszolgálóra).
7. Egyesíti az ágakat.

Menjünk. A lerakat létrehozása nagyon egyszerű feladat. Ehhez a BitBucket-et fogjuk használni, tehát itt kell rendelkeznie fiókkal. A regisztráció után kattintson a "Létrehozás" gombra, és töltse ki a szükséges mezőket. Klónozzon a tárolót a SmartGit használatával. Vedd el a lerakat linkjét.

Most futtassa a SmartGit szoftvert, válassza a „Projekt” - „Klón” (vagy a Ctrl + Alt + O) elemet, és töltse ki a szükséges mezőket:

A rendszer a Bitbucket-től kéri a felhasználónevét és jelszavát:

A következő ablakban két klónozási lehetőség áll rendelkezésre: „Almodulok beillesztése” és „Az összes fej és címke letöltése”. A Git lehetővé teszi különálló alkalmazási modulok tárolását különböző tárolókban. Ha bejelöli az „Almodulok beillesztése” beállítást, a SmartGit automatikusan betölti az összes modult. Ha a „Minden fej és címke letöltése” opció be van jelölve, akkor a SmartGit a projekt mappa létrehozása után letölti az összes ágot és címkét ehhez a lerakathoz:

A következő ablak a projekt neve a SmartGitben:

Ha egy üres tárolót klónozott (ahogy ez a cikkben), akkor a következő ablakot fogja látni:

Menj tovább. Hozzunk létre egy kötelezettségvállalást. Mi az elkötelezettség? Ez változások elkövetése. Mindegyik elkötelezett „emlékszik”, hogy pontosan mit változtatott meg, és bármikor visszaállíthatja a fájlok korábbi állapotát. Azt javaslom, hogy tegyen kötelezettséget minden jelentős változtatás után, például javítson egy hibát egy funkcióban. Elkötelezettség létrehozásához meg kell változtatnia valamit a projektben. Adjon hozzá néhány fájlt a projekt mappájához:

Most láthatja projektünk változásait a SmartGitben:

Válassza ki mindkét fájlt, majd kattintson a „Stage”, majd a „Commit” gombra. Miért nyomja meg a Stage? A Stage gomb hozzáadja a kiválasztott fájlokat az aktuális indexhez. Ha két fájlhoz szeretne létrehozni egy elkötelezettséget, de megváltoztatta, tegyük fel, hogy akár öt is van, csak válassza ki ezt a két fájlt, kattintson a "Stage" gombra, amely hozzáadja azokat az indexhez, és a "Commit" után. Így csak a kiválasztott két fájl lesz a kötelező érvényű.

Ezután megjelenik egy ablak, ahol megjegyzést kell fűznie a kötelezettségvállaláshoz. Általában azt írják, amit megváltoztattak, hozzáadtak, töröltek és így tovább:

Ezután kattintson a „Kötelezettség” gombra. A Visszatérés és nyomógomb ugyanezt teszi, de a változtatásokat a távoli lerakatba (a mi esetünkben a Bitbucketbe) is továbbítja (feltölti). Még ne tedd ezt. Mi tovább haladunk. Az alábbiakban megjelenik az ágak listája helyi fióktelep  «Mester». Ez az alkalmazás kódjának fő ága. Mik az ágak, egy kicsit később elmondom. Most tegyünk valamit a projektünkkel, és tegyük vissza a változásokat. Törli a readme.txt fájlt, szerkeszti az index.php fájlt és új confic.cfg fájlt ad hozzá:

Most tegye vissza a változást a kötelezettségvállalás után. Menjünk a Naplóba:

Kiválasztjuk azt a kötelezettségvállalást, amelybe vissza akarunk térni, és kattintsunk az „Alaphelyzet” gombra:

A következő ablakban felkínáljuk, hogy válasszon, melyik „Reset” -t szeretnénk végrehajtani:

Magyarázom. Emlékezzünk arra, hogy kötelezettségvállalás létrehozásakor először fájlokat adunk az indexhez (szakasz). Ez lehetővé teszi, hogy csak indexelt fájlokat készítsen. A lágy alaphelyzetbe állítás csak a visszaállítást követi. A fájlok index és fizikai változásai megmaradnak. A vegyes alaphelyzetbe állítás ugyanúgy működik, mint a szoftver, de törli a fájlindexet. A hard reset törli a fájlok végrehajtási, indexelési és fizikai változásait. Használjon óvatosan kemény visszaállításez véletlenül nem távolítja el a felesleget.

Könnyen visszaállítottam az egyértelműség érdekében:

Mint láthatja, a fájlokban minden változás eltűnt, vagy inkább minden visszatért az első kötelező állapotba.

Most egy kicsit az ágak létrehozásáról. Miért van szükségük egyáltalán? Az ág lehetővé teszi a kód aktuális állapotának mentését és a kísérletet. Például egy új modult ír. Logikus ezt külön ágban elvégezni. A főnök felhívja és azt mondja, hogy van egy hiba a projektben, és azt sürgősen ki kell javítani, de a modul nem került hozzáadásra. Hogyan kell kitölteni törött fájlok? Csak váltson egy működő ágra modul nélkül, javítson ki egy hibát, és töltsön fel fájlokat a szerverre. És amikor a "veszély" elmúlt - folytassa a munkát a modulon. És ez az ágak előnyeinek számos példája.

Próbáljuk meg létrehozni a saját águnkat. Van már egy, ez a mester. Ez automatikusan létrejön (ha nincs), amikor elvégzi az első kötelezettségvállalást. Hozzon létre egy másik ágot, és nevezze el „new_future1” -nek. Nyomja meg az F7 billentyűt, vagy kattintson a jobb egérgombbal a „Helyi ágak” felirat „Ágak” fülén az alábbi gombra, és válassza a legördülő listában az „Ág hozzáadása” lehetőséget:

Kattintson az „Ág hozzáadása és váltás” elemre, hogy azonnal átválthasson a létrehozott ágra. Most új kötelezettségeket hozhat létre, módosíthat fájlokat, és nem kell aggódnia. Mivel mindig van egy mesterág, amelyre visszatérhet. Ha átvált egy ágra, a Git a helyi fájlokat megváltoztatja az abban található fájlok között. Vagyis ha létrehoz új ág  módosítson valamit az index.php fájlban, majd váltson a mesterágra, majd az összes módosítást törli. Ha visszalép a létrehozott ágra, akkor a módosítások visszatérnek.

Eddig helyben dolgoztunk. Próbáljuk feltölteni munkánk munkáit a szerverre. Hozzunk létre néhány kötelezettséget az new_future1 ágban. Ha a lerakat üres és üres, mivel egy ideje létrehoztuk, és még nem töltöttünk fel semmit a szerverre, a Bitbucket a főként az elsőként letöltött ágot rendeli hozzá. Ezért váltson a "mester" ágra és nyomja meg a "Nyomja meg" gombot:

Ezután a SmartGit megkérdezi, hogy konfigurálható-e az ágkövetés (cofigure-követés). A követés lehetővé teszi, hogy automatikusan frissítse a vonatkozó ágakat, amikor letölt vagy letölt a kódfrissítéseket. Tehát nyugodtan kattintson a "Konfigurálás" gombra:

Most váltson egy másik ágra, és tegye ugyanezt. Menjünk a Bitbucket-hez és nézzük meg, mi változott a „Kötelezettség” szakaszban:

Mint láthatja, minden eljutott a távoli szerverre.

Most sózzuk az ágakat. Miért van erre szükség? Vegyük ugyanazt a példát a modullal. Előbb vagy utóbb hozzáadja, és a modul kódját hozzá kell adnia a fő alkalmazás kódjához. Csak egyesítse az ágakat. Ehhez váltson arra az ágra, amelybe össze kívánja vonni a kódot. A mi esetünkben ez a mester. Ezután kattintson a jobb gombbal arra az ágra, amelyből a kódot egyesíteni szeretné, és válassza az "Egyesítés" lehetőséget:

És most csak a fő ág változásait kell kiszolgálóra tenni. Töltse ki a kiszolgáló módosítását ugyanúgy, mint korábban, és kapja meg:

Ennyi egyszerre. A képek miatt a cikk nagyszerű lett. Kérdezze meg a válaszokat. Írjon kérdéseket.

A VCS alapjai

bevezetés

Mielőtt bármilyen verziószabályozó rendszerről beszélne, meg kell értenie, mi az, mi azok és miért jelentek meg egyáltalán. Ez az előadás a verziókontroll és a menedzsment rendszerek kezdeti megismerésére szolgál, és először elmondom neked a verziókezelő eszközök eredetét, elmondom, mely verziószabályozó rendszerek népszerűek manapság, és melyek a legfontosabb különbségek közöttük.

A verziószabályozásról

Mi a verzióvezérlés, és miért van rá szüksége?

Valószínűleg érdemes egy verziókontroll rendszer (SLE) meghatározásával kezdeni - ez egy olyan rendszer, amely egy vagy több fájlban rögzíti a változásokat, így a jövőben visszatérhet ezeknek a fájloknak a régi verzióira.

A közelmúltban a fájlok sok szakma végső eredményei (például írás, kutatás és természetesen szoftverfejlesztés). Nagyon sok időt és erőfeszítést igényel ezeknek a fájloknak a fejlesztése és karbantartása, és senkinek sem kell több időt és erőfeszítést költenie a változások eredményeként elveszített adatok helyreállítására.

Képzelje el, hogy egy programozó egy kis fájlból álló projektet dolgoz ki (egyébként a példa valódi, nem szintetikus, a valós életben találkozik). A projekt első verziójának kiadása után nehéz választással kell szembenéznie: javítani kell az első verzió felhasználói által bejelentett problémákat, és egyidejűleg valami újat kell kidolgozni a másodikhoz. Még akkor is, ha csak meg kell javítania a felmerülő problémákat, valószínű, hogy bármilyen változás után a projekt nem működik, és meg kell határoznia, hogy mi történt megváltoztatva, hogy a probléma könnyebben lokalizálható legyen. Ezenkívül tanácsos valamilyen naplót vezetni a végrehajtott változtatásokról és javításokról, hogy ne végezzük ugyanazt a munkát többször.

A legegyszerűbb esetben a fenti probléma több fájl másolat tárolásával oldható meg, például az egyik a projekt első verziójában a hibák javításához, a második az új változtatásokhoz. Mivel a változások általában nem túl nagyok a fájlmérethez képest, csak a diff segédprogrammal tárolhatja a megváltozott sorokat, és később egyesítheti azokat a patch segédprogrammal. De mi van, ha egy projekt több ezer fájlból áll és száz ember dolgozik rajta? Ha ebben az esetben a fájlok különálló másolatainak tárolására (vagy akár csak a változtatásokra) használja ezt a módszert, akkor a projekt nagyon gyorsan elakad. A következő előadásokban például a programok forráskódjait fogom használni, de valójában szinte bármilyen fájlt verzióvezérlés alá lehet helyezni.

Ha Ön grafikus vagy webdesigner, és a kép vagy az elrendezés minden változatát szeretné tárolni - és valószínűleg ezt akarja -, akkor a verziószabályozó rendszer használata nagyon bölcs döntés. Az SLE lehetővé teszi az egyes fájlok visszatérését az előző állapotukba, a teljes projekt visszaállítását az előző állapotukba, az idővel bekövetkező változások megtekintését, annak meghatározását, hogy ki módosította a modult, amely hirtelen leállt, ki okozta a hibát, és még sok más. Általánosságban elmondható, hogy ha az SLE használatával mindent elront vagy fájlokat veszít, akkor minden könnyen visszaállítható. Ezen túlmenően a mindent megkapó rezsi nagyon kicsi lesz.

Helyi verziószabályozó rendszerek

Mint korábban említettük, a helyi SUV egyik példája rendkívül egyszerű: sokan inkább a verziók vezérlésére törekednek, ha fájlokat másolnak egy másik könyvtárba (általában az aktuális dátumot adják hozzá a könyvtár nevéhez). Ez a megközelítés nagyon általános, mert egyszerű, de gyakran kudarcot vall. Nagyon könnyű elfelejteni, hogy rossz könyvtárban van, és véletlenül megváltoztatja a rossz fájlt, vagy másolja át a fájlokat rossz helyre, és törölje a szükséges fájlokat. A probléma megoldására a programozók már régóta kifejlesztettek egy helyi kemény valutát egy egyszerű adatbázissal, amely a szükséges fájlok összes módosítását tárolja.

Az egyik legnépszerűbb kemény pénznem az RCS (Revision Control System), amelyet még mindig sok számítógépre telepítenek. Még a modern Mac OS X esetén is, az rcs telepítve van a Fejlesztői eszközökkel. Az RCS-t az 1980-as évek elején fejlesztette ki Walter F. Tichy. A rendszer lehetővé teszi, hogy csak egy fájl verzióit tárolja, tehát több fájlt manuálisan kell kezelnie. A rendszer ellenőrzése alatt álló egyes fájlok esetében a verzióinformációkat egy speciális fájlban tárolják, az eredeti fájl nevével, amelyhez a végén a ", v" karakterek kerülnek. Például a file.txt esetében a verziók a file.txt fájlban kerülnek tárolásra, v. Ez a segédprogram a javítókészletekkel való pár verziók közötti munkán alapszik (a javítás egy fájl, amely leírja a fájlok közötti különbséget). Ez lehetővé teszi, hogy bármilyen fájlt bármikor újra létrehozhasson, javításokat alkalmazva. A rendszer a diff segédprogramot használja a verziók tárolására. Noha az RCS megfelel a verziókezelő rendszerre vonatkozó minimumkövetelményeknek, ennek a következő fő hátrányai vannak, amelyek ösztönzőként szolgáltak a következő vizsgált rendszer létrehozására is:

• Csak egy fájl kezelése, minden fájlt külön kell kezelni;
• Kényelmetlen mechanizmus több felhasználónak a rendszerrel való egyidejű működésére, a tároló egyszerűen blokkolva van, amíg a blokkoló felhasználó fel nem oldja;
• Senki sem szabadít fel a biztonsági másolatoktól, kockáztathat mindent.

Centralizált verziókezelő rendszerek

A következő fő probléma a más számítógépek fejlesztőivel való együttműködés szükségessége volt. Ennek megoldására központi verzióvezérlő rendszereket (CSCV) hoztunk létre. Az ilyen rendszerekben, például a CVS, a Subversion és az Perforce, van egy központi kiszolgáló, amelyen az összes fájlt verzióvezérlés alatt tárolják, és számos olyan ügyfél, amely fájlok másolatát kapja tőle. Ez évek óta a verziószabályozó rendszerek standardja.

Ennek a megközelítésnek számos előnye van, különösen a helyi kemény valutához képest. Például mindenki tudja, ki és mi vesz részt a projektben. Az adminisztrátorok egyértelműen ellenőrzik, ki és mit tehet, és természetesen a CCSC-k adminisztrálása sokkal könnyebb, mint az egyes ügyfelek helyi adatbázisai. Ennek a megközelítésnek azonban számos súlyos hátránya van. A legnyilvánvalóbb, hogy a központosított kiszolgáló sebezhetőséget okoz az egész rendszerben. Ha a szerver egy órára kikapcsol, akkor a fejlesztők egy órán keresztül nem léphetnek kapcsolatba, és senki sem tud megmenteni új verzió  munkájuk. Ha a központi adatbázist tartalmazó lemez sérült, és nem mentés, abszolút mindent elveszít - a projekt teljes története, kivéve talán, kivéve néhány működő verziót, amelyeket a felhasználók munkagépein mentettek el.

CVS

A CVS (párhuzamos verziók rendszere) továbbra is a legszélesebb körben használt rendszer, de gyorsan elveszíti népszerűségét olyan hibák miatt, amelyeket alább tárgyalok. Dick Grune az 1980-as évek közepén fejlesztette ki a CVS-t. Az egyes fájlok tárolására a CVS (valamint az RCS) RCS formátumú fájlokat használ, de lehetővé teszi a könyvtárakban található fájlcsoportok kezelését. A CVS olyan kliens-szerver architektúrát is használ, amelyben az összes verzióinformációt a kiszolgálón tárolják. Az ügyfél-szerver architektúra használata lehetővé teszi a CVS használatát még a földrajzilag elosztott felhasználói csapatok számára is, ahol minden felhasználónak saját munkakönyvtára van a projekt másolatával. Ahogy a neve is sugallja, a felhasználók megoszthatják a rendszert.

Ugyanazon fájl módosításakor felmerülő esetleges konfliktusokat az a tény oldja meg, hogy a rendszer lehetővé teszi, hogy csak a fájl legújabb verziójára módosítson. Ezért mindig javasolt frissíteni a fájlok másolatát esetleges ellentmondásos változások esetén, mielőtt feltölti a módosításokat. Frissítéskor a rendszer automatikusan megváltoztatja a munkapéldányt, és csak az egyik fájlhely konfliktust okozó változtatása esetén kéri a konfliktus helyének manuális javítását.

A CVS lehetővé teszi több projektfejlesztési vonal vezetését a fejlesztési ágak felhasználásával. Így, a fent említettek szerint, kijavíthatja a projekt első verziójában levő hibákat, és ezzel párhuzamosan új funkciókat fejleszthet ki.

A CVS-t használtuk sok  projektek, de természetesen nem hiányosságok nélkül később jött létre a következő vizsgált rendszer. Vegye figyelembe a fő hátrányokat:

• Mivel a verziók RCS fájlokban vannak tárolva, a könyvtári verziók nem menthetők. Szabványos módon  ezen akadály megkerülése érdekében egy fájlt (például README.txt) el kell menteni egy könyvtárba;
• A fájlok áthelyezése vagy átnevezése nem tartozik verziószabályozás alá. Ennek szokásos módja az, hogy először másolja a fájlt, törölje a régi fájlt a cvs remove paranccsal, majd adja hozzá az új nevét a cvs add paranccsal;

felforgatás

A Subversion (SVN) programot 2000-ben fejlesztették ki a CollabNet kezdeményezésére. Az SVN-t eredetileg "legjobb CVS-ként" fejlesztették ki, és a fejlesztők fő feladata a CVS-ben szereplő hibák kijavítása volt, fenntartva egy hasonló felületet. Az SVN, akárcsak a CVS, kliens-szerver architektúrát használ. A legjelentősebb változások a CVS-hez képest:

• Atomi változások (kötelezettségvállalás). Ha a kötelezettségvállalás feldolgozása megszakadt, akkor nem történik változtatás.
• A fájlok átnevezése, másolása és áthelyezése elmenti a változások teljes előzményeit.
• A könyvtárak, a szimbolikus hivatkozások és a meta adatok verziókezelés alatt állnak.
• Hatékony változtatástároló bináris fájlokhoz.

Elosztott verziószabályozó rendszerek

És ebben a helyzetben az elosztott verzióvezérlő rendszerek (RSKV) kerülnek játékba. Az olyan rendszereken, mint a Git, a Mercurial, a Bazaar vagy a Darcs, az ügyfelek nem csak a fájlok legfrissebb verzióját töltik le, hanem teljes egészében lemásolják a teljes lerakatot. Ezért abban az esetben, ha az a kiszolgáló, amelyen keresztül a munka meghal, bármilyen ügyfél-tárházat vissza lehet másolni a kiszolgálóra az adatbázis visszaállítása érdekében. Minden alkalommal, amikor az ügyfél felveszi a fájlok legújabb verzióját, elkészíti magának az összes adat teljes példányát.

Ezen felül a legtöbb ilyen rendszerben több távoli tárolóval is dolgozhat, így ugyanabban a projektben egyszerre másképp dolgozhat különböző embercsoportokkal. Tehát egy projektben többféle munkafolyamat is elvégezhető egyszerre, ami a központosított rendszerekben lehetetlen.

Miért van szükség elosztott rendszerekre?

Amint a neve is sugallja, az elosztott rendszerek egyik legfontosabb elképzelése egyértelműen meghatározott központi verzióraktár - egy adattár - hiánya. Elosztott rendszerek esetén a verziók teljes vagy részlegesen eloszthatók a különféle tárolók között, ideértve a távoli adattárakat is. Ez a modell tökéletesen illeszkedik az elosztott csapatok munkájához, például egy világszerte elosztott fejlesztői csapat dolgozik egy nyílt projekten forráskód. Egy ilyen csapat fejlesztője letöltheti az összes verzióinformációt, majd csak a helyi gépen dolgozhat. Amint elértük a munka egyik szakaszának eredményét, a módosításokat feltölthetjük az egyik központi adattárba, vagy közzétehetjük a fejlesztő weboldalán vagy a levelezőlistán. Más projekt résztvevői viszont frissíthetik a verzióraktár másolatát új változtatásokkal, vagy kipróbálhatják a közzétett változtatásokat egy külön, tesztfejlesztési ágon. Sajnos, jó projektszervezés nélkül, egy központi lerakat hiánya lehet az elosztott rendszerek mínusza. Ha centralizált rendszerek esetében mindig van egy közös lerakat, ahonnan beszerezheti a projekt legújabb verzióját, akkor elosztott rendszerek esetén szervezetileg meg kell határoznia, melyik projektágak lesznek a főek. Miért érdekli az elosztott verzióvezérlő rendszer valaki, aki már használ központosított rendszert - például Subversion? Bármelyik munka magában foglalja a döntések meghozatalát, és a legtöbb esetben különféle lehetőségeket kell kipróbálni: verzió-vezérlő rendszerekkel való együttműködés során a fejlesztési ágak használják a különféle lehetőségek mérlegelését és a nagy változások elvégzését. Bár ez egy meglehetősen természetes koncepció, a Subversionban nem könnyű azt használni. Sőt, minden bonyolultabbá válik az ágakból a több egymást követő csatlakozás esetén - ebben az esetben a konfliktusok és hibák elkerülése érdekében pontosan meg kell jelölni az egyes változtatások kezdeti és végleges változatát. Az elosztott verziószabályozó rendszereknél a fejlesztési ágak az egyik alapvető fogalom - a legtöbb esetben a verziótároló minden példánya fejlesztési ága. Így az elosztott rendszerek esetében az egyik ágaról a másikra történő változások kombinálásának mechanizmusa az egyik fő, amely lehetővé teszi a felhasználók számára, hogy kevesebb erőfeszítést tegyenek a rendszer használatakor.

A népszerű disztribútor rövid ismertetése

• A Git egy elosztott verziószabályozó rendszer, amelyet Linus Torvalds fejlesztett ki. A Git-t eredetileg a Linux kernel fejlesztési folyamatában szánták, de később sok más projektben is felhasználták - mint például az X.org és a Ruby on Rails, Drupal. A Git jelenleg a leggyorsabban elosztott rendszer, amely a legkisebb változatú áruházat használja. Ugyanakkor a Git interfész bonyolultnak tűnhet például azoknak a felhasználóknak, akik a Subversionról váltanak át.
• A Mercurial egy elosztott rendszer, Python-ban írva, több kiterjesztéssel C-ben. A Mercurial-t használó projektek közül a Mozilla és a MoinMoin nevet adhatja meg.
• A Bazaar egy fejlesztési rendszer, amelyet a Canonical támogat, az Ubuntu terjesztéséről és a https://launchpad.net/ webhelyről ismert. A rendszer elsősorban Pythonban van írva, és olyan projektekben használják, mint például a MySQL.
• Codeville - Python-alapú elosztott rendszer innovatív egyesítési változás algoritmust használva. A rendszert például az eredeti BitTorrent kliens fejlesztésére használják.
• A Darcs egy elosztott verziókezelő rendszer, Haskell nyelven írva, amelyet például a Buildbot projekt használ.
• Monotone - C ++ nyelvű rendszer, amely az SQLite-t használja a revíziók tárolójaként.