Git

A Git (ejtsd: "git" [7] ) egy elosztott verziókezelő rendszer . A projektet Linus Torvalds hozta létre a Linux kernel fejlesztésének menedzselésére , az első verzió 2005. április 7- én jelent meg . A mai napig Junio ​​​​Hamano támogatja .

A Git-et használó projektek közé tartozik a Linux kernel , a Swift , az Android , a Drupal , a Cairo , a GNU Core Utilities , a Mesa , a Wine , a Chromium , a Compiz Fusion , a FlightGear , a jQuery , a PHP , a NASM , a MediaWiki , a DokuWiki , a Qt számos Linux - disztribúció .

A program ingyenes és a GNU GPL 2-es verziója alatt jelent meg. Az alapértelmezett a 9418 -as TCP-port .

Történelem

A Linux kernel fejlesztése a saját fejlesztésű BitKeeper [8] rendszeren történt , amelyet a szerző - Larry McVoy , aki maga is Linux fejlesztő - biztosította a projektet ingyenes licenc alatt. Fejlesztők, magas osztályú programozók számos segédprogramot írtak, és az egyikhez Andrew Tridll fordította meg a BitKeeper adatátviteli formátumot. McVoy válaszul a megállapodás megszegésével vádolta meg a fejlesztőket, és visszavonta a licencet, Torvalds pedig új rendszert vett fel: egyik nyílt rendszer sem tette lehetővé, hogy programozók ezrei működjenek együtt erőfeszítéseikben (ugyanez a konfliktus vezetett a Mercurial megírásához ). Az ideológia egyszerű volt: vegyük a CVS -megközelítést , és fordítsuk a fejére [9] , és ezzel egyidejűleg növeljük a megbízhatóságot.

A kezdeti fejlesztés kevesebb mint egy hetet vett igénybe: 2005. április 3-án megkezdődött a fejlesztés, április 7-én pedig a Git kódot egy befejezetlen rendszer kezelte. Június 16-án a Linuxot áttelepítették a Gitre, július 25-én pedig Torvalds lemondott a vezető fejlesztői posztról.

Torvalds annyira szarkasztikus volt a git (ami angolul "gazember") nevet választotta:

	Egoista barom vagyok, ezért minden projektemet magamról nevezem el. Először Linux, most git.		Önző barom vagyok, ezért minden projektemet magamról nevezem el. Először Linux , most git.
[10] [11]

Jellemzők

A rendszert kifejezetten forgatókönyvekben való használatra tervezték . Ez megkönnyíti az egyéni Git-alapú verziókezelő rendszerek vagy felhasználói felületek létrehozását. Például a Cogito egy ilyen példa a Git-tárolók körüli burkolásra, az StGit pedig a Git-et használja a javítások ( javítások ) gyűjteményének kezelésére .

A Git támogatja a gyors verziófelosztást és -egyesítést, valamint eszközöket tartalmaz a nemlineáris fejlesztési előzmények megjelenítéséhez és navigálásához. A Darcshoz , a BitKeeperhez , a Mercurialhoz , a Bazaarhoz és a Monotone -hoz hasonlóan a Git minden fejlesztőnek egy helyi másolatot biztosít a teljes fejlesztési előzményről, a változtatások átmásolásra kerülnek egyik tárolóból a másikba.

A Git-tárolókhoz való távoli hozzáférést a git démon , SSH vagy HTTP szerver biztosítja. A git-daemon TCP szolgáltatás a Git disztribúció része, és az SSH-val együtt a leggyakoribb és legmegbízhatóbb hozzáférési módszer. A HTTP hozzáférési módszer számos korlátozás ellenére nagyon népszerű a vezérelt hálózatokban, mivel lehetővé teszi a meglévő hálózati szűrőkonfigurációk használatát.

Megvalósítási jellemzők

A Git core parancssori segédprogramok készlete opciókkal. Minden beállítás szöveges konfigurációs fájlokban tárolódik. Ez a megvalósítás lehetővé teszi, hogy a Git könnyen hordozható legyen bármilyen platformra, és könnyen integrálható más rendszerekbe (különösen grafikus git kliensek létrehozása tetszőleges felülettel).

A Git-lerakat egy olyan könyvtár a fájlrendszeren, amely a lerakatkonfigurációs fájlokat, a lerakaton végrehajtott műveleteket tároló naplófájlokat, a fájlok helyét leíró indexet és a tényleges fájlokat tartalmazó tárat tartalmazza. A fájltároló szerkezete nem tükrözi a repozitóriumban tárolt fájlfa valós szerkezetét, hanem a tárhellyel végzett műveletek gyorsítására koncentrál. Amikor a kernel egy változtatási parancsot dolgoz fel (akár helyi változtatások esetén, akár egy másik csomóponttól kapott javításkor), új fájlokat hoz létre a lerakatban a megváltozott fájlok új állapotának megfelelően. Fontos, hogy semmilyen művelet ne változtassa meg a tárolóban már meglévő fájlok tartalmát.

Alapértelmezés szerint a lerakat a lerakatban tárolt fájlfa munkapéldányának gyökérkönyvtárában egy " .git " nevű alkönyvtárban van tárolva. A rendszerben lévő bármely fájlfa átalakítható git tárolóvá, ha kiadja a tár létrehozására szolgáló parancsot a fa gyökérkönyvtárából (vagy a gyökérkönyvtár megadásával a program beállításai között). Az adattár importálható a hálózaton keresztül elérhető másik csomópontból. Egy új lerakat importálása automatikusan létrehoz egy munkapéldányt, amely megfelel az importált lerakat legfrissebb véglegesített állapotának (vagyis nem másolja át a forráscsomópont munkapéldányába azokat a módosításokat, amelyekhez nem adtak ki véglegesítési parancsot az adott csomóponton ).

Építészet

A git alsó szintje az úgynevezett tartalom-címzett fájlrendszer . A git parancssori eszköz számos olyan parancsot tartalmaz, amelyekkel közvetlenül kezelheti ezt a tárat alacsony szinten. Ezek a parancsok nem szükségesek a git-tel mint verziókezelő rendszerrel való normál munkához, hanem összetett műveletek végrehajtásához (sérült lerakat javítása stb.), valamint lehetővé teszik saját alkalmazás létrehozását a git tároló alapján.

A tárolóban lévő minden egyes objektumhoz egy SHA-1 hash kerül kiszámításra, és ez lesz az objektumot tartalmazó fájl neve a .git/objects könyvtárban . A könyvtárfákat nem használó fájlrendszerek optimalizálásához a hash első bájtja az alkönyvtár neve, a többi pedig a benne lévő fájl neve lesz, ami csökkenti az egy könyvtárban lévő fájlok számát (a teljesítményt korlátozó tényező ilyen régebbi fájlrendszereken).

Minden hivatkozás a lerakatobjektumokra, beleértve az egyik objektumon belüli hivatkozást is, SHA-1 hash.

Ezenkívül van egy refs könyvtár a tárolóban , amely lehetővé teszi, hogy ember által olvasható neveket állítson be néhány Git objektumhoz. A Git-parancsokban mind az ember által olvasható referenciák, mind a mögöttes SHA -1 teljesen felcserélhetők.

A klasszikus normál forgatókönyv szerint háromféle objektum található egy git-tárházban – egy fájl, egy fa és  egy véglegesítés .  A fájl néhány felhasználói fájl verziója, a fa különböző alkönyvtárakból származó fájlok gyűjteménye, a „commit” egy fa és néhány további információ (például szülő véglegesítések, valamint megjegyzés).

A repository időnként szemétgyűjtést végez, melynek során az elavult fájlokat deltákkal helyettesíti a köztük lévő és a tényleges fájlok között (azaz a fájl aktuális verziója nem növekményesen kerül tárolásra, a növekményekkel csak a korábbi verziókhoz való visszatérés történik), majd a delta adatok hozzáadódnak egy nagy fájlhoz, amelybe az index épül. Ez csökkenti a tárolási kapacitásigényt.

A Git adattár lehet helyi vagy távoli. A helyi repository a .git alkönyvtára, amelyet a git init hoz létre (üres), és (nem üres, azonnal átmásolja a szülő távoli tároló tartalmát, és a szülőhöz kapcsolódik) a git clone .

Szinte minden normál verziókezelési művelet, mint például a véglegesítés és az összevonás, csak a helyi lerakaton történik. Egy távoli tároló csak felfelé ( push ) és lefelé ( pull ) szinkronizálható egy helyi tárolóval.

Ha a teljes projekttárat minden fejlesztőnél helyileg birtokoljuk , a Git számos előnnyel rendelkezik az SVN - hez képest . Így például a push és pull műveletek kivételével minden művelet végrehajtható internetkapcsolat nélkül.

A git nagyon erős tulajdonsága az ágak, amelyek sokkal teljesebben vannak implementálva, mint az SVN-ben: valójában a git ág nem más, mint egy névre szóló hivatkozás, amely egy commit-ra mutat a repository-ban (egy refs alkönyvtár segítségével ). Egy új ág létrehozása nélküli véglegesítés csak áthelyezi ezt a hivatkozást magához, és egy ág létrehozásával végrehajtott véglegesítés a régi hivatkozást a helyén hagyja, de az új commit alkalmával újat hoz létre, és aktuálisnak nyilvánítja. Ugyanilyen triviális a helyi fejlesztési fájlok lecserélése egy másik ágból származó fájlkészletre, és ezáltal a velük való munkavégzésre való átállás.

Az alrepozitóriumok az aktuális ágak szinkronizálásával is támogatottak.

A push parancs minden új adatot (azokat, amelyek még nincsenek a távoli tárolóban) átviszi a helyi lerakatból a távoli tárolóba. A parancs végrehajtásához az szükséges, hogy a távoli tároló ne végezzen új véglegesítéseket más kliensektől, különben a push meghiúsul, és le kell húzni és össze kell egyesíteni.

A pull parancs  a push parancs ellentéte . Abban az esetben, ha ugyanannak az ágnak önálló előzményei vannak a helyi és a távoli másolatban, akkor a húzás azonnal megkezdődik az egyesítéshez.

A különböző fájlok egyesítése automatikusan megtörténik (ez a viselkedés konfigurálható), és egyetlen fájlon belül - szabványos három ablaktáblás fájl-összehasonlítással. Az összevonás után az ütközéseket megoldottnak kell nyilvánítania.

Mindennek az eredménye egy új állapot az egyesítést végző fejlesztő helyi fájljaiban. Azonnal végre kell hajtania egy commit-ot, miközben ebben a commit objektumban a repositoryban olyan információ lesz, hogy a commit két ág egyesítésének eredménye, és két szülő committel rendelkezik.

Az összevonás mellett a Git támogatja az újrabázis műveletet is .  Ez a művelet az A ágban végrehajtott összes változás halmazát kapja, majd ezek „előregurulnak” a B ágba. Ennek eredményeként a B ág AB állapotba kerül. Az összevonástól eltérően az AB ág történetében nem lesz A ág köztes commitálása (csak a B ág története és magának az újrabázisnak a nyilvántartása, ez leegyszerűsíti a nagy és nagyon nagy projektek integrálását).

A Gitnek van egy ideiglenes helyi fájlindexe is. Ez egy közbenső tároló az aktuális fájlok és a következő véglegesítés között (a véglegesítés csak ebből az indexből történik). Ennek az indexnek a segítségével új fájlok kerülnek hozzáadásra (a git add hozzáadja őket az indexhez, a következő véglegesítésbe kerülnek), valamint nem minden megváltozott fájl véglegesítésre kerül (csak a git add által készített fájlok kerülnek véglegesítésre ). A git add után tovább szerkesztheti a fájlt, ugyanabból a fájlból három példányt kap – az utolsót, az indexben (amely a git add idején volt ), és az utolsó véglegesítéskor.

Alapértelmezett ágnév: master . Az alapértelmezett távoli tár neve, amelyet a git clone hozott létre egy tipikus "egy meglévő projekt húzása a szerverről a gépre" művelet során: origin .

Így a helyi adattárnak mindig van egy fő ága , amely a legfrissebb helyi véglegesítés, és egy eredet/fő ág , amely a távoli lerakat legfrissebb állapota az utolsó pull vagy push befejezésekor .

A fetch parancs (részleges lehívás ) - lekéri a távoli szerverről az origin/master változásait , és átírja azokat a helyi tárolóba, elősegítve az origin/master címkét .

Ha azután, hogy a mester és az origó/fő elvált, akkor egyesíteni kell úgy, hogy az egyesítés eredményére mestert állít be (a pull parancs a fetch+merge ). Továbbá lehetséges a push az összevonás eredményének elküldésével a szervernek, és annak eredet/mester beállításával .

Megvalósítás részletei Windows rendszeren

A Windows verzió (a hivatalos Windows verzió neve mSysGit) az mSys csomagot használja, amely a MinGW projekt POSIX -kompatibilis Windows parancssorának  portja . A Githez szükséges összes könyvtár és eszköz, valamint maga a Git átkerült az mSys alá. Amikor SSL -en keresztül távoli tárolókkal dolgozik , az mSys tanúsítványtárolóját használja, nem a Windows-ból.

Számos grafikus felhasználói felület létezik a Git for Windows számára, például a TortoiseGit . Mindegyiket az mSysGit hívásaival valósítják meg, és telepíteni kell a gépre. Ez alól a SourceTree, az Atlassian megoldása sem kivétel, de tartalmazza az mSysGit-et, aminek megvannak az előnyei és hátrányai (mivel a mély alkönyvtárba történő telepítés megnehezíti a szükséges SSL-tanúsítványok mSys-hez való hozzáadását).

Mivel a Windows más sorvégi karaktert használ, mint a legtöbb Unix-szerű rendszer , vannak lehetőségek (kliens- és adattárszinten is) a csoportok számára az operációs rendszerek között, hogy egységes sorvégi megjelenítést biztosítsanak.

Hálózati és szervermegoldások

A Git csak a távoli tárolókkal való megosztására használja a hálózatot.

A következő protokollok használhatók:

• a git protokoll (URI séma - git: ) egy nyílt protokoll [12] , amelyhez egy futó git démon [13] szükséges a szerveren (a Githez mellékelve), a protokoll nem rendelkezik felhasználói hitelesítési eszközökkel;
• SSH ( ssh: ) - kulcspárokat használó felhasználói hitelesítést, valamint a Unix rendszerbe épített "fő" SSH szervert (sshd) használja, szerver oldalról git-t shellként tartalmazó fiókok létrehozása szükséges;
• HTTP és HTTPS ( http: , https: ) - használja a curl eszközt (Windowshoz - a git-hez tartozik) és annak HTTP hitelesítési képességeit, valamint támogatja az SSL-t és a tanúsítványokat.

Ez utóbbi esetben egy webalkalmazás szerveroldalán kell dolgoznia, amely rétegként működik a szerveren lévő Git-parancsok és a HTTP-kiszolgáló között (köztük az ASP.NET MVC 4-en fejlesztett WebGitNet). A szerveroldali push és pull parancsok támogatása mellett az ilyen webalkalmazások csak olvasási hozzáférést is biztosíthatnak a tárolóhoz egy webböngészőn keresztül.

Grafikus interfészek

Számos grafikus felületet fejlesztettek ki a rendszerhez, többek között - GitKraken (egy platformközi megosztási szoftver Git kliens), SmartGit (platformok közötti interfész Javaban), gitk (egy egyszerű és gyors program Tcl / Tk nyelven írva, Gittel terjesztve). maga), Giggle (a Gtk+ egyik változata ), TortoiseGit ( Windows Explorer kiterjesztésként megvalósított felület ), SourceTree (ingyenes Git kliens Windows és Mac rendszerhez), Github kliens és még számos más.

Ezen kívül számos webes frontendet fejlesztettek ki, köztük GitWebAdmin, GitLab , Gitblit, Gerrit , Gitweb, Kallithea, Gitea .

Git hosting

Számos szolgáltatás nyújt tárhelyet a git adattárak számára, a leghíresebbek a GitHub , Codebase , SourceForge , SourceHut , Gitea , Bitbucket , GitLab .

Interakció más verziókezelő rendszerekkel

A Git szabványos disztribúciója támogatja az interakciót a CVS -szel (importálás és exportálás, CVS-kiszolgáló emuláció) és a Subversion -nal ( az import és export részleges támogatása). Az ökoszisztémán belüli szabványos importálási és exportálási eszköz a .tar.gz és .tar.bz2 formátumú fájlok verziószámának archívuma.

Jegyzetek

1. ↑ https://github.com/git/git/graphs/contributors
2. ↑ Re: Apróságok: Mikor lett a git saját házigazdája?
3. ↑ [ HIRDETÉS a Git v2.38.1-ről és egyebekről] – 2022.
4. ↑ A git nyílt forráskódú projekt az Open Hubon: Nyelvek oldala - 2006.
5. ↑ 1 2 3 4 5 6 Git csomag formátum
6. ↑ Másolás  _
7. ↑ git . Letöltve: 2009. június 19. Az eredetiből archiválva : 2010. április 14.. (határozatlan)
8. ↑ BitKeeper és Linux: Az út vége? (nem elérhető link) . Letöltve: 2017. november 7. Az eredetiből archiválva : 2017. június 8. (határozatlan) 
9. ↑ Torvalds beszéde . Letöltve: 2017. szeptember 28. archiválva az eredetiből: 2007. május 28. (határozatlan)
10. ↑ GitFaq: Miért a „Git” név ? Letöltve: 2017. november 7. Az eredetiből archiválva : 2012. július 23. (határozatlan)
11. ↑ Egy vita után Torvalds elkezdi dolgozni a 'git'-en . PC világ. Letöltve: 2017. november 7. Az eredetiből archiválva : 2011. február 1.. (határozatlan) Eredeti szöveg  (angol)[ showelrejt] Arra a kérdésre, hogy miért nevezte „git”-nek az új szoftvert, a brit szleng jelentése „rohadt ember” – mondta. "Egoista barom vagyok, ezért minden projektemet magamról nevezem el. Először Linux, most git."
12. ↑ Git - Transfer Protocols . Hozzáférés időpontja: 2013. október 28. Az eredetiből archiválva : 2013. október 29. (határozatlan)
13. ↑ Git a szerveren - Git démon . Letöltve: 2022. május 9. Az eredetiből archiválva : 2017. április 20. (határozatlan)

Linkek