Git

Vývoj Gitu začal v dubnu 2005, když vývojáři jádra Linuxu opustili proprietární správu zdrojového kódu (SCM) BitKeeper, který používali od roku 2002.[1][2] Autor projektu a držitel copyrightu Larry McVoy tehdy ukončil možnost volného používání, které zdůvodnil tím, že Andrew Tridgell pomocí reverzního inženýrství protokolu BitKeeperu vytvořil SourcePuller.[3] Stejný incident inicioval vývoj podobného systému správy zdrojových kódů Mercurial.

Linus Torvalds chtěl mít distribuční systém, který bude moci používat stejně jako BitKeeper, ale žádný takový nebyl volně dostupný. Torvalds zmínil SCM, který za 30 vteřin aplikuje patch a aktualizuje všechna související metadata a poznamenal, že takový systém nemůže zvládnout (nemůže škálovat pro) vývoj jádra, kde správci potřebují udělat takových změn 250 najednou. Designové kritérium (návrhový vzor), které stanovil, vyžadovalo aplikaci patche za ne více než 3 sekundy[4] a přidal další tři požadavky:

• CVS je příklad jak to nedělat a pokud budeme na pochybách, uděláme to obráceně[5]
• podpora a distribuovanost podobně jako workflow BitKeeperu[5]
• zahrnout velmi silnou ochranu proti poškození ať už z důvodu nehody nebo záměru[6]

Tato tři kritéria eliminovala všechny tehdy existující systémy pro správu verzí s výjimkou Monotone, který však nesplňoval výkonnostní požadavky. Bezprostředně po vydání linuxového jádra verze 2.6.12-rc2 se Linus Torvalds rozhodl napsat svůj vlastní systém.

Git byl inspirován verzovacími systémy BitKeeper a Monotone.[7][8] Git byl původně navržen jako nízkoúrovňový nástroj, který by ostatním umožnil vytvoření uživatelského rozhraní (front end) jako je Cogito nebo StGIT.[9] Jádro projektu Git se však postupně rozrostlo na kompletní systém pro správu revizí, který je použitelný bez doplňkových nástrojů.[10]

Ze zřejmých důvodů byl Git původně psán pro operační systém Linux, ale je snadno přenositelný na ostatní UN*Xové systémy, včetně BSD, Solarisu a Darwina. Implementován je samozřejmě také pod Windows. Existuje také reimplementace JGit v Javě[11] a podpora ve formě plug-inu EGit[12] pro Eclipse.

Návrh systému Git byl syntézou zkušeností Linuse Torvaldse s údržbou rozsáhlého projektu (jádro Linuxu) vyvíjeného distribuovaným (kolektivním) způsobem, s důkladnou znalostí výkonnosti souborového systému a potřeby vytvořit v krátké době použitelný nástroj (viz níže). Uvedené vlivy vedly k následujícím implementačním rozhodnutím:

• Mocná podpora pro nelineární vývoj. Git podporuje rychlé vytváření větví a rychlé slučování (merge). Obsahuje specifické nástroje pro vizualizaci a navigaci v nelineární historii vývoje projektu. Jedním z klíčových předpokladů (na kterých je Git založen) je to, že změna je začleňována (merge) do jiných větví častěji, než je vytvářena -- tak jak prochází rukama různých recenzentů.
• Distribuovaný vývoj. Podobně jako je tomu u systémů Darcs, BitKeeper, Mercurial, SVK, Bazaar a Monotone poskytuje Git každému vývojáři lokální kopii celé historie vývoje. Změny se kopírují z jednoho takového úložiště do jiného. Tyto změny se importují v podobě dalších vývojových větví, které mohou být začleněny do jiné větve stejným způsobem, jako lokálně vyvíjené větve.
• Úložiště může být zpřístupněno prostřednictvím protokolů HTTP, FTP, rsync nebo protokolu Git realizovaného buď přes obyčejné sokety nebo přes SSH. Git obsahuje rovněž emulaci CVS serveru, což umožňuje zpřístupnit úložiště Git i stávajícím CVS klientům a zásuvným modulům (plugin) pro vývojová prostředí (IDE).
• Úložiště systémů Subversion a svk mohou být používána přímo, nástrojem git-svn.
• Efektivní práce s velkými projekty. Torvalds popisuje Git jako velmi rychlý a škálovatelný.[13] Výkonnostní testy uskutečněné sdružením Mozilla ukázaly, že Git je o jeden řád rychlejší (cca 10×) než jiné systémy pro správu revizí. Některé operace jsou dokonce o dva řády rychlejší (cca 100×).[14][15]
• Kryptografická autentizace historie. Historie je v systému Git uložena takovým způsobem, že jméno konkrétní revize (v pojmech Git je nazýváno „commit“) závisí na celkové historii vývoje, která vede až k tomuto commitu. Jakmile je jednou zveřejněno, nelze staré verze změnit, aniž by to prošlo bez povšimnutí (tuto vlastnost mají i systémy Mercurial a Monotone).
• Navržen jako sada nástrojů (Toolkit design). Systém Git byl navržen jako sada programů napsaných v jazyce C a dalších shellovských skriptů, které volání těchto programů obalují.[16] Při přenosu Gitu do systému Microsoft Windows byla většina skriptů nahrazena programy v jazyce C, ale původní návrh je zachován. Díky tomu lze snadno řetězit funkčnost jednotlivých komponent s cílem dosáhnout jiných zajímavých efektů.[17]
• Zaměnitelné slučovací strategie (Pluggable merge strategies). Součástí návrhu ve formě sady nástrojů (toolkit design) je dobře definovaný model neúplného sloučení (incomplete merge) a několik algoritmů pro jeho dokončení. Na vrcholu procesu stojí uživatelské hlášení, že Git není schopen dokončit sloučení (merge) automaticky a že musí být provedena ruční editace.
• Nepotřebné soubory se hromadí až do úklidu. Přerušení operace nebo návrat ke stavu před změnami vede k tomu, že v databázi zůstávají viset nepotřebné objekty. V rámci průběžně narůstající historie chtěných objektů jde o malé zlomky, ale jejich odstraňování (garbage collection) pomocí git-gc --prune může být pomalé.[18]

Pro dosažení maximální rychlosti zachycuje Git vývoj projektu jako sérii stavů adresářových stromů se soubory. Tím se liší od dřívějších verzovacích systémů jako SCCS a RCS, které se soustředily na úsporu místa ukládáním rozdílů mezi verzemi jednotlivých souborů, a koncept, kdy se sledují změny identifikovatelného souboru procházejícího jednotlivými revizemi projektu, převzaly i pozdější systémy. Torvalds však tuto koncepci odmítl,[19] takže Git vztahy mezi jednotlivými revizemi jednoho souboru nijak neuchovává. Z toho plynou významné důsledky:

• Zjištění stavu celého projektu v libovolném historickém okamžiku je velmi rychlé.
• Zjištění historie změn jednoho souboru je o něco náročnější než zjištění historie změn celého projektu.[20] Git zjišťuje historii změn jednoho souboru tak, že projde globální historii, a zjišťuje, zda jednotlivé změny mohly vést ke změně daného souboru. Zjišťování historie libovolné sady souborů je pak stejně efektivní jako v případě jednoho souboru. Velmi běžné je například zjišťování historie pro podadresář zdrojových textů a přidruženého globálního hlavičkového souboru.
• Přejmenování je prováděno implicitně a ne explicitně. Mezi časté stížnosti na CVS patří to, že součástí historie revizí souborů je jeho jméno. Kvůli tomu nelze přejmenovat soubor, aniž by došlo k přerušení jeho historie, nebo přejmenování historie, které ji učiní nepřesnou. Většina systémů pro správu revizí novějších než CVS tento problém řeší tím, že souboru přidělí unikátní trvanlivé jméno (něco jako číslo inodu), které přežívá i po přejmenování. Git podobné identifikátory nepoužívá a považuje to za výhodu.[21][22] Jako argument lze použít skutečnost, že zdrojové soubory jsou kromě prostého přejmenování občas také rozdělovány nebo slučovány.[23] Zachycením této skutečnosti jako prosté přejmenování by jen zafixovalo nepřesné vyjádření toho, co se ve skutečnosti stalo, v rámci (později neměnitelné) historie. Git tento problém řeší detekcí přejmenování během zjišťování historie stavů projektu (snapshots) a nikoliv jeho zaznamenáváním při zachycování stavu (snapshot).[24] (Stručně: Pokud se v revizi N nachází nějaký soubor, pak soubor se stejným jménem v revizi N-1 je jeho předpokládaným předkem. Pokud ale v revizi N-1 není soubor podobného jména, pak Git hledá soubor, který existoval v revizi N-1 a je velmi podobný novému souboru.) Tento přístup ovšem při každém prohlížení historie vyžaduje více času procesoru a používání více voleb pro nastavení potřebných heuristik.

Někteří lidé kritizují model ukládání dat:

• Opakované explicitní balení objektů. Git uchovává každý nově vytvořený objekt jako samostatný soubor. Ačkoliv je každý z nich komprimován, vede to k prostorové neefektivnosti. Tento problém je řešen používáním balíčků (pack), které ukládají více objektů v jednom souboru (nebo v jednom síťovém proudu dat) při zhušťování na základě uchovávání vzájemných rozdílů. Při kompresi balíčků se využívá heuristika, která vychází z toho, že soubory se stejným jménem jsou asi podobné. Ale na této heuristice není závislá korektnost. Nově vytvořené objekty (nově přidaná historie) jsou ukládány odděleně. Pro dosažení prostorové efektivnosti je nutné provést znovuzabalení (repacking). Git provádí periodické znovuzabalení automaticky, ale lze je provést i ručně provedením příkazu git gc.

Git implementuje několik slučovacích strategií (merging strategies). Nestandardní strategie může být zvolena v okamžiku zahájení slučování:[25]

resolve

Tradiční třícestný slučovací algoritmus (3-way merge).

recursive

Toto je standardní (default) strategie užívaná v případě, kdy dochází k přetažení (pulling) nebo sloučení (merging) jedné větve. Jde o variantu třícestného slučovacího algoritmu. „Pokud existuje více než jeden společný předek, který by mohl být použit pro třícestné slučování, vytvoří se sloučený strom společných předků a ten se použije jako referenční strom pro třícestné slučování. Tento přístup vede k méně slučovacím konfliktům aniž by docházelo k chybným slučováním. Bylo to potvrzeno testy na skutečných případech slučování (merge commits) převzatých z historie vývoje jádra Linux 2.6. Tento přístup navíc může detekovat a vyřešit slučování, jehož součástí je i přejmenování“.[26]

octopus

Standardní (default) strategie při slučování více než dvou hlavních větví (when merging more than two heads).

Git není v podstatě jen systém pro správu zdrojových kódů (SCM):

Je mnoho způsobů, jak můžete vidět Git jen jako souborový systém – je obsahově adresovatelný, a umí verzovat, ale hlavně problémy řeší z pohledu souborového systému (jo, jádra jsou to, co já dělám), a já ve skutečnosti nemám naprosto žádný zájem na vytvoření tradičního SCM systému.

—Linus Torvalds

K tomuto základu byla postupně, jak se ukázala jejich potřeba, doplněna řada funkcí, které jsou očekávány od tradičních SCM.

Git používá dvě základní datové struktury umístěné v adresáři .git: proměnlivý index (také nazývaný stage nebo cache), který ukládá informace o pracovním stromě a připravovaném commitu (revizi); a databázi, do které se pouze připisuje. Index slouží jako spojovací bod mezi objektovou databází a pracovním stromem. Databáze obsahuje čtyři typy objektů:

• Blob slouží k uložení obsahu jednoho souboru. Blob objekt neobsahuje název souboru, časová razítka ani jiná metadata.
• Strom je ekvivalentem adresáře. Obsahuje seznam názvů souborů, z nichž ke každému je přiřazena řada bitových příznaků a název objektu typu blob nebo strom, které odpovídají jednotlivým souborům, symbolickým odkazům, nebo podadresářům. Tento objekt popisuje snapshot zdrojového adresáře, jejich hierarchie pak snapshot zdrojového stromu.
• Commit slouží k seřazení objektů strom do historie. Obsahuje název objektu strom (který odpovídá nejvyšší úrovni zdrojového adresáře), časové razítko, žurnálovací zprávy a jména commit objektů, které jsou bezprostředními předchůdci tohoto commitu; mnoho commitů má jednoho bezprostředního předchůdce, commity vzniklé slučováním mají dva nebo více předchůdců, nejstarší commit nemá žádného předchůdce.
• Tag je kontejner, který obsahuje odkaz na jiný objekt a může obsahovat další metadata ve spojení s jiným objektem. Nejčastěji se používá k ukládání digitálního podpisu commit objektu odpovídajícímu konkrétnímu poslaní údajů do repositáře (tj. začaly být sledovány Gitem).

Každý objekt je v Gitu identifikován hodnotou hašovací funkce SHA-1 svého obsahu.

Git ukládá každou revizi souboru jako samostatný blob. Vztahy mezi bloby lze nalézt pouze prohlížením stromu a commit objektů. U nově přidávaných objektů se nevyužívá jejich podobnosti s předešlou revizí, pouze se zkomprimují algoritmem zlib. Git spočítá hodnotu haše (u souborů se hodnota počítá včetně předřazené identifikace typu a čísla objektu) a blob umístí do adresáře podle prvních dvou znaků haše. Zbytek hashe se používá jako název souboru pro daný objekt. To může vést k velké spotřebě diskového prostoru, proto se starší objekty ukládají do jednoho souboru v adresáři .git/objects/pack, který pro úsporu místa využívá delta kompresi, což znamená, že se ukládají pouze změny oproti jiné revizi.

Git servery typicky naslouchají na TCP portu 9418.[27]

Git je primárně vyvíjen na Linuxu, ale také podporuje většinu hlavních operačních systémů včetně BSD, Solarisu, macOS a Windows NT.

JGit realizace Gitu je čistě Java softwarová knihovna, jež má být začleněna do všech aplikací Java. JGit používá Gerrit (code review tool) a EGit (Git klient pro Eclipse IDE).

Realizace Dulwich je čistě Python softwarová komponenta pro Python 2.

Libgit2 je realizace Gitu v podobě ANSI C knihovny, kterou lze přeložit pro různé platformy včetně Microsoft Windows, Linux, macOS a BSD. Používá se jako základ pro Git knihovny pro programovací jazyky Ruby, Python a Haskell a jako základní implementace gitu v týmu Microsoft Foundation servis a Visual Studio.

Verzovací systémy Perforce a Plastic SCM obsahuje vlastní implementaci protokolu Git, aby jejich klienti mohli spolupracovat se vzdálenými Git repozitáři.

Eclipse Foundation uvedl v ročních statistických zjišťování Společenství, že v květnu 2012 více než 27 % (z 732) z profesionálních softwarových vývojářů používalo Git jako jejich primární systém, což byl nárůst z 12,8 % v roce 2011.[28] Open source directory Ohloh vykazuje podobný nárůst mezi open source projekty.

Ve Spojeném království IT webové stránky itjobswatch.co.uk hlásí, že od prosince 2012 má přibližně 10 % společností zabývajících se vývojem softwaru na seznam požadavků Git ve srovnání s 17,3 % v Subversion, 8,7 % pro Microsoft Team Foundation Server, a 1,9 % pro Visual SourceSafe.

Následující webové stránky poskytují zdarma hostování zdrojových kódu v repozitářích postavených na Gitu: