Elosztott verzióvezérlés - Distributed version control

A szoftverfejlesztés , elosztott verziókezelő (más néven elosztott változáskezelõ ) egyik formája a verzió ellenőrzés , amely a teljes codebase , beleértve annak teljes történetét, tükrözve van minden fejlesztő számítógépén. A központosított verzióvezérléshez képest ez lehetővé teszi az automatikus felügyeleti elágazást és összevonást , felgyorsítja a legtöbb műveletet (kivéve a tolást és a húzást), javítja az offline munkavégzés képességét, és nem támaszkodik egyetlen helyre a biztonsági mentésekhez. A Git , a világ legnépszerűbb verziókezelő rendszere, egy elosztott verziókezelő rendszer.

2010 -ben Joel Spolsky szoftverfejlesztési szerző úgy jellemezte az elosztott verziókezelő rendszereket, mint "a szoftverfejlesztési technológia talán legnagyobb fejlődését az [elmúlt] tíz évben".

Elosztott vs központosított

Az elosztott verzióvezérlő rendszerek (DVCS) peer-to-peer megközelítést alkalmaznak a verzióvezérléshez , szemben a központosított rendszerek ügyfél-szerver megközelítésével. Az elosztott felülvizsgálatvezérlés szinkronizálja a tárolókat azáltal, hogy áthelyezi a javításokat a peer -ről a peer -re. Nincs egyetlen központi verziója a kódbázisnak; ehelyett minden felhasználónak van egy munkapéldánya és a teljes változástörténet.

A DVCS előnyei (a központi rendszerekhez képest) a következők:

  • Lehetővé teszi a felhasználók számára, hogy produktívan dolgozzanak, ha nincsenek hálózathoz csatlakoztatva.
  • A közös műveletek (például a véglegesítés, a megtekintési előzmények és a változtatások visszaállítása) gyorsabbak a DVCS esetében, mivel nincs szükség kommunikációra egy központi szerverrel. A DVCS esetén a kommunikáció csak akkor szükséges, ha a változásokat megosztják más társaik között.
  • Lehetővé teszi a privát munkát, így a felhasználók még a korai vázlatokhoz is használhatják a módosításokat, amelyeket nem szeretnének közzétenni.
  • A munkapéldányok hatékonyan működnek távoli biztonsági mentésként, így elkerülhető, hogy egyetlen fizikai gépre támaszkodjon egyetlen hibaként.
  • Lehetővé teszi különböző fejlesztési modellek használatát, például fejlesztési ágak vagy parancsnok/hadnagy modell használatát.
  • Lehetővé teszi a projekt "kiadási verziójának" központi vezérlését
  • A FOSS szoftverprojekteken sokkal könnyebb egy projektvillát létrehozni egy olyan projektből, amely vezetői konfliktusok vagy tervezési nézeteltérések miatt elakad.

A DVCS hátrányai (a központi rendszerekhez képest) a következők:

  • A lerakat kezdeti ellenőrzése lassabb, mint a központosított verziókezelő rendszerben, mivel alapértelmezés szerint az összes ág és a felülvizsgálati előzmények a helyi gépre vannak másolva.
  • A zárolási mechanizmusok hiánya, amely a legtöbb központosított VCS része, és továbbra is fontos szerepet játszik a nem összevonható bináris fájlokban, például grafikus eszközökben vagy túl bonyolult egyfájlú bináris vagy XML csomagokban (pl. Irodai dokumentumok, PowerBI fájlok, SQL Server) Data Tools BI csomagok stb.).
  • További tárhelyre van szükség ahhoz, hogy minden felhasználó rendelkezzen a teljes kódbázistörténet teljes másolatával.
  • A kódbázis fokozott expozíciója, mivel minden résztvevőnek van egy helyileg sérülékeny példánya.

Néhány eredetileg központosított rendszer mostantól kínál néhány elosztott funkciót. Például a Subversion számos műveletet képes elvégezni hálózat nélkül. A Team Foundation Server és a Visual Studio Team Services mostantól központosított és elosztott verziókezelő tárolókat üzemeltet a Git tárhelyén keresztül.

Hasonlóképpen, egyes elosztott rendszerek mostantól olyan funkciókat kínálnak, amelyek enyhítik a fizetési időket és a tárolási költségeket, például a Microsoft által kifejlesztett Virtual File System for Git nagyon nagy kódbázisokkal való együttműködésre, amely egy virtuális fájlrendszert tesz lehetővé, amely csak helyi tárolóra tölti le a fájlokat ahogy szükség van rájuk.

Munka modell

Az elosztott modell általában jobban alkalmas nagy projektekre, amelyek részben független fejlesztőkkel rendelkeznek, mint például a Linux kernel projekt, mivel a fejlesztők önállóan dolgozhatnak, és beküldhetik a módosításokat egyesítésre (vagy elutasításra). Az elosztott modell rugalmasan lehetővé teszi az egyéni forráskód -hozzájárulási munkafolyamatok elfogadását. Az integrátor munkafolyamata a leggyakrabban használt. A központosított modellben a fejlesztőknek sorba kell állítaniuk munkájukat, hogy elkerüljék a különböző verziókkal kapcsolatos problémákat.

Központi és fióktelepek

Minden projekt rendelkezik egy központi adattárral, amelyet hivatalos tárolónak tekintünk, és amelyet a projekt fenntartói kezelnek. A fejlesztők klónozzák ezt az adattárat, hogy azonos helyi példányokat hozzanak létre a kódbázisból. A központi lerakat forráskód -változásait rendszeresen szinkronizálják a helyi adattárral.

A fejlesztő új ágat hoz létre a helyi tárházban, és módosítja a forráskódot ezen az ágon. A fejlesztés befejezése után a változtatást integrálni kell a központi adattárba.

Húzza a kéréseket

Az elosztott verziókezelő rendszert használó forráskód -lerakathoz való hozzájárulás általában lekérési kérelem , más néven egyesítési kérelem útján történik . A közreműködő kéri, hogy a projektfenntartó húzza le a forráskód módosítását, innen a "pull request" elnevezést. A fenntartónak egyesítenie kell a lehívási kérelmet, ha a hozzájárulás a forrásbázis részévé válik.

A fejlesztő lehívási kérelmet hoz létre, hogy értesítse a fenntartókat az új változásról; megjegyzés szál van társítva minden lekérési kérelemhez. Ez lehetővé teszi a kódváltozások összpontosított megvitatását . A beküldött lekérési kérelmek mindenki számára láthatók, akik hozzáférnek a tárházhoz. A lekérési kérelmet a fenntartók elfogadhatják vagy elutasíthatják.

Miután a lekérési kérelmet felülvizsgálták és jóváhagyták, az egyesül a lerakatba. A kialakított munkafolyamattól függően előfordulhat, hogy a kódot tesztelni kell, mielőtt a hivatalos kiadásba kerülne. Ezért egyes projektek speciális ágat tartalmaznak a nem tesztelt lekérési kérelmek egyesítésére. Más projektek automatikus tesztcsomagot futtatnak minden lekérési kérésnél, egy folyamatos integrációs eszközt, például Travis CI -t használva , és a felülvizsgáló ellenőrzi, hogy minden új kód megfelelő tesztlefedettséggel rendelkezik -e.

Történelem

Az első nyílt forráskódú DVCS-rendszerek közé tartozott az Arch , a Monotone és a Darcs . A nyílt forráskódú DVCS -ek azonban soha nem voltak nagyon népszerűek a Git és a Mercurial megjelenéséig .

A BitKeeper -t 2002 -től 2005 -ig használták a Linux kernel fejlesztésében. A Git , a világ legnépszerűbb verziókezelő rendszere kifejlesztését az a döntés indította el, amely a BitKeeper -t arra kényszerítette, hogy vonja vissza Linus Torvalds és néhány más Linux kernelfejlesztők korábban kihasználták.

Lásd még

Hivatkozások

Külső linkek