Bevezetés a verziókezelő rendszer - alapján a git
Mielőtt meg kell értened, hogy mi ez, mik ezek, és miért jönnek beszélni, amit adott verziókezelő rendszer. Az előadás célja egy kezdeti bevezetését verzió ellenőrzési és irányítási rendszerek, és először fogok beszélni eredetét eszközök verziókövetés, mondják el, mit verziókövető rendszerek most népszerű, és mit kell jelentős különbségeket.
Mintegy verzió ellenőrzése
Mi verziókövetés, és miért van szükség egy?
Talán meg kellene kezdeni a meghatározás a verziókezelő rendszerek (SLE) - egy olyan rendszer, amely regisztrálja változások egy vagy több fájlt, úgy, hogy a jövőben, akkor menj vissza az egyes régebbi verziói ezeket a fájlokat.
A közelmúltban, a fájlok a végeredmény sok szakmák (például irodalmi tevékenység, tudományos munka, és természetesen, szoftverfejlesztés). Töltöttem sok időt és erőfeszítést, hogy a fejlesztési és az ezeket támogató fájlokat, és senki sem akarja, hogy meg kell tölteni, még több időt és erőfeszítést visszaállítani elveszett adatok miatt bekövetkezett változásokat.
Képzeljük el, hogy egy programozó fejleszt a projekt, amely egy kis fájlt (by the way, egy példa egy nagyon is valóságos, nem szintetikus, találkozott az életben). Megjelenése után az első változat a projekt egy nehéz választás: a problémák megoldásában a felhasználók által jelentett az első változatát, és ugyanabban az időben, hogy dolgozzon ki valami újat a második. Akkor is, ha csak azt kell megoldani a problémát, hogy a felmerülő, akkor valószínű, hogy bármilyen változtatását követően a projekt nem működik, és meg kell határozni, milyen változások történtek, hogy könnyebb elkülöníteni a problémát. Az is kívánatos, hogy végezzen egy magazin változtatásokat és javításokat tenni többször ugyanazt a munkát.
A legegyszerűbb esetben a fenti problémát úgy lehet megoldani, tárolása több példányban fájlok, például, az egyik kijavítani a hibákat az első változata a projekt, a második az új változásokat. Mivel a változások általában nem túl nagy méretéhez képest a fájlt, akkor csak tárolja a megváltozott vonalat diff majd összekapcsolják őket a javítás segédprogramot. De mi van, ha a projekt keretében több ezer fájlt, és több száz ember dolgozik rajta? Ha ebben az esetben az alkalmazott módszer, hogy tárolja az egyes fájlok másolatait (vagy akár csak megváltozik), akkor a projekt leállt nagyon gyorsan. A későbbi fejezetekben például fogom használni a forráskód programok, de valójában alatt verziókövetés, akkor tegye a fájlokat gyakorlatilag bármilyen típusú.
Ha egy grafikus vagy webdesigner és meg kívánja tartani minden változata egy kép vagy elrendezés - és akkor érdemes - használata a verziókövető rendszer egy nagyon bölcs döntés. SCR lehetővé teszi a visszatérés az egyes fájlokat a korábbi formájában, térjen vissza az előző állapot a teljes projekt, kilátás, hely, változtatni az idő, hogy eldöntsék, ki utolsó módosítást a hirtelen leáll egység, és amikor be a kódot néhány hibát, és még sok más. Általában, ha a kemény valuta, még mindig összezavar, vagy elveszíti a fájlokat, mindent könnyen visszaállítható. Ezen felül, a felső, amit kapsz lesz nagyon kicsi.
Helyi Version Control Systems
Mint korábban említettük - az egyik példája a helyi SUV egyszerű: sokan inkább verziókezelő egyszerűen másolja a fájlokat egy másik könyvtárba (általában hozzáadásával az aktuális dátumot a könyvtár neve). Ez a megközelítés nagyon gyakori, mert egyszerű, de gyakran ad hibák. Ez könnyű elfelejteni, hogy te nem abban a könyvtárban, és véletlenszerűen változik a hibás fájlt, vagy másolja a fájlokat ha nem akart, és felülírja a fájlokat. A probléma megoldásához, programozók régen alakult ki helyi SLE egy egyszerű adatbázis, amely tárolja az összes változtatást szükséges fájlokat
Az egyik legnépszerűbb deviza ilyen típusú a RCS (Revision Control System, Revision Control System), amely még mindig telepítve van sok számítógép. Még egy modern operációs rendszere, a Mac OS X rcs segédprogram telepítése a fejlesztői eszközök. RCS-ben fejlesztették ki az 1980-Valterom Tichi (Walter F. Tichy). A rendszer lehetővé teszi, hogy tárolja csak egy változata a fájlt, így kezelni több fájlt kell kézzel. Minden fájl ellenőrzése alatt a rendszer információit változatok egy fájlban tárolják a neve az eredeti fájl amihez hozzáadódik a végén a szereplők, v '. Például file.txt Fájlverziók fogja tartani a fájl file.txt, v. Ez a segédprogram alapja a munka készlet foltok párok közötti változatok (tapasz - file leíró különbségek fájlok). Ez lehetővé teszi, hogy újra minden fájlt bármely időpontban, következetes alkalmazásával javításokat. A tárolásához változat a rendszer által használt közművek diff. Bár RCS megfelel a minimális követelményeknek a verziókezelő rendszert, akkor a következő fő hátránya, amely szintén az ösztönzést a rendszer a következő:
- Bízza csak egy fájlt, minden fájl kell külön szabályozható;
- Kellemetlen mechanizmus egyidejű többfelhasználós rendszerben, a tároló van zárva, amíg csak blokkolja a felhasználó kinyitja azt;
- A mentést akkor nem szabad, azt kockáztatja, elveszti mindent.
Központosított verziókövető rendszerek
A másik nagy kihívás volt, hogy szükség van, hogy működjön együtt a fejlesztők más számítógépek. Hogy oldja meg, a központi verziókezelő rendszer (TSSKV) jött létre. Az ilyen rendszerek, mint például CVS, Subversion, és a Perforce, van egy központi szerver, amely tárolja az összes fájl alatt verziókövetés, és a fogyasztók száma, akik megkapni az fájljait. Sok éven át ez volt a szabvány változat rendszerek.
Ez a megközelítés számos előnye van, különösen a helyi és regionális SLE. Például, mindenki tudja, hogy ki mit csinál a projektben. A rendszergazdák világos felett ki mit tehet, és természetesen, hogy kezelje TSSKV sokkal könnyebb, mint a helyi adatbázisok minden ügyfélnek. Azonban ebben a megközelítésben, számos komoly hátránya. A legnyilvánvalóbb - a központi szerver egy gyenge pontja az egész rendszert. Ha a szerver leáll, egy órát, majd egy óra, a fejlesztők nem tudnak kommunikálni, és senki sem tudja menteni egy új változata a munkájukat. Ha a sérült lemezt egy központi adatbázisba, és nincs tartalék, akkor veszít, mindent - az egész történelem a projekt, talán kivéve a több dolgozó változat, túlélő a felhasználó számítógépére.
CVS (Concurrent Versions System, a közös rendszer verzió) még mindig a legelterjedtebb rendszer, de gyorsan veszít népszerűsége hiányosságai miatt, amit a későbbiekben majd. Dick Grune (Dick Grune) CVS kifejlesztett 1980-as évek. CVS tárolni az egyes fájlokat (valamint RCS) használ fájlok RCS formátumú, de lehetővé teszi, hogy kezelje a csoport kép található a könyvtárakban. CVS is használ egy kliens-szerver architektúra, amelyben az összes információt a változat a szerveren tárolt. Egy kliens-szerver architektúra lehetővé teszi a használatát CVS, még földrajzilag szétszórt csapatok felhasználó, ahol minden felhasználónak van egy üzemi könyvtárban egy példányát a projekt. Ahogy a neve is mutatja, a felhasználók használhatják a rendszer együtt.
Lehetséges konfliktusok a változás az azonos sorban megoldódnak, hogy a rendszer lehetővé teszi, hogy a változások csak a legújabb verzióját a fájlt. Ezért mindig ajánlott öntés előtt a módosításokat, hogy frissítse a munkapéldányod az iratokból az esetleges ütköző módosításokat. Ha frissíti a rendszer módosítja a működő példány automatikusan, és csak abban az esetben egymásnak ellentmondó módosítások egyike a kívánt fájlt kézzel kell kijavítani a helyét a konfliktus.
A CVS segítségével többsoros fejlesztési projekt segítségével ágak (ágak) fejlesztése. Így, mint már említettük, lehetőség van arra, hogy kijavítsa a hibákat az első változata a projekt, és ezzel párhuzamosan új funkciót.
CVS már használt egy csomó projekt, de biztosan nem volt mentes a hibákat, amelyek később vezetett a következő a rendszer. Tekintsük a fő hátránya:
- Mivel a változat tárolt RCS fájl nem lehet tartani a változat könyvtárakat. A szokásos módja, hogy kb ez - ez a fájl mentéséhez (például README.txt) a könyvtárban;
- Áthelyezése vagy átnevezése nem tartozik verzió ellenőrzése. A szabványos módon Ehhez először másolja a fájlt, törölje a régi parancsok segítségével, például CVS eltávolítani, majd adjunk hozzá egy új nevet a cvs add paranccsal;
felforgatás
Elosztott Rendszerek Version Control
És ebben a helyzetben jön szóba, hogy elosztott verziókezelő rendszer (RSKV). A rendszerek, mint a Git, Mercurial, Bazaar vagy Darcs ügyfelek nem csak kirak az utolsó változat a fájl, és teljesen másolja a teljes adattár. Ezért, amikor a „haldokló” szerver, amelyen keresztül a munka folyik, minden ügyfél adattár másolható vissza a szerver vissza az adatbázisba. Minden alkalommal, amikor egy ügyfél felveszi a legújabb verzióját a fájlokat, létrehoz magának egy teljes másolatát az összes adatot.
Ezen kívül, a legtöbb ilyen rendszer képes kezelni több távoli adattárak, így egyszerre dolgozunk különböző módon, különböző embercsoportok egy projekt. Például egy projekt egyszerre fenntartani többféle munkafolyamatok, amelyeket nem lehet a központi rendszerek.
Miért Elosztott Rendszerek?
Rövid leírása népszerű megosztott SUV