Git

Z Wikipedie, otevřené encyklopedie
Skočit na: Navigace, Hledání
Git
Logo
Vývojář Junio Hamano, Linus Torvalds
Aktuální verze 2.0.1 (25. června 2014)
Operační systém POSIX
Typ softwaru Verzovací systém
Licence GPL v2
Web git-scm.com

Git je distribuovaný systém správy verzí vytvořený Linusem Torvaldsem, původně pro vývoj jádra Linuxu.

Návrh Gitu byl ovlivněn projekty BitKeeper (ten byl používán pro vývoj jádra Linuxu dříve) a Monotone. Původně se jednalo o nízkoúrovňový základ pro vývoj různých systémů správy verzí (mezi známé vzniklé nastavby patří například Cogito), ale časem se Git vyvinul do samostatně použitelného systému správy verzí. Dnes je používán mnoha známými projekty, kromě zmíněného jádra Linuxu mimo jiné X.Org a Ruby on Rails.

Vývoj Gitu je v současnosti spravován Junio Hamanem, je šířen pod GPL verze 2, jedná se o svobodný software.

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. Existuje také reimplementace JGit v Javě[1] a podpora ve formě plug-inu EGit[2] pro Eclipse.

Charakteristika[editovat | editovat zdroj]

Návrh systému Git byl inspirován systémy BitKeeper a Monotone.[3][4] 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.[5] 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ů.[6]

Návrh systému Git je syntézou Torvaldsových zkušeností s údržbou rozsáhlého projektu vyvíjeného distribuovaný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 detaily v sekci věnovaná historii.) 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 zveřejněno prostřednictvím protokolů HTTP, FTP, rsync nebo protokolu Git realizovaného buď přes obyčejné sockety 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 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ý.[7] Výkonnostní testy uskutečněné sdružením Mozilla ukázaly, že Git je o jeden řád rychlejší (cca 10x) než jiné systémy pro správu revizí. Některé operace jsou dokonce o dva řády rychlejší (cca 100x).[8][9]
  • 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í.[10] Jako výsledek úsilí o přenos Git pod systém Microsoft Windows byla většina těchto skriptů přepsána do jazyka 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ů[11].
  • Zaměnitelné slučovací strategie (Pluggable merge strategies). Součástí návrhu do podoby sady nástrojů (toolkit design) je dobře definovaný model neúplného sloučení (incomplete merge) a několika 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.
  • Smetí 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 neužitečné 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é.[12]

Jednou z vlastností Git je to, že zachycuje stav adresářových stromů se soubory. Dřívější systémy pro sledování verzí zdrojového kódu, SCCS a RCS, pracovaly na úrovni jednotlivých souborů a dosahovaly úspory prostoru na základě ukládání rozdílů mezi verzemi. Pozdější systémy pro správu revizí pokračovaly v tomto pojetí existence identifikovatelného souboru, který prochází více revizemi projektu.

Torvalds uvedenou koncepci odmítnul[13]. Git tedy explicitně neuchovává vztahy mezi soubory revize na jakékoliv nižší úrovni uvnitř stromu zdrojových souborů. Plynou z toho významné důsledky:

  • Zjištění historie změn jednoho souboru je o něco náročnější, než zjištění téhož pro celý projekt.[14] Aby Git zjistil historii změn daného souboru, musí projít globální historii a zjistit, zda každá ze změn mohla vést ke změně onoho souboru. Tento způsob zjišťování historie ale systému Git umožňuje se stejnou efektivitou zjistit historii jak pro jeden soubor, tak pro libovolnou sadu souborů. 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. To znamená, že přejmenování souboru není možné, aniž bychom buď přerušili jeho historii, anebo historii přejmenovali a učinili ji tak 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 i-uzlu), které přežívá i po přejmenování. Git podobné identifikátory nepoužívá a považuje to za výhodu.[15][16] 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[17]. 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).[18] (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 CPU a používání více voleb pro nastavení potřebných heuristik.

Některé lidi navíc znervózňuje 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í:[19]

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í".[20]
octopus
Standardní (default) strategie při slučování více než dvou hlavních větví (when merging more than two heads).

Datové struktury[editovat | editovat zdroj]

Git není ve své podstatě jen system pro management zdrojového kódu (SCM):

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

– Linus Torvalds

Z tohoto počátečního návrhu se v Gitu vyvinula celá řadu funkcí, které jsou očekávány od tradičních SCM s funkcemi, které byly vytvořeny, když to bylo potřeba.

Git má dvě datové struktury: proměnlivý index (také nazýván stage nebo cache), který ukládá informace o pracovním adresáři a další commitnuté revizi; a neměnný, append-only objekt databáze. Objektová databáze obsahuje čtyři typy objektů:

  • Blob objekt je obsah souboru. Blob objekty nemají název souboru, časová razítka nebo další metadata.
  • Strom objekt je ekvivalentem adresáře. Obsahuje seznam názvů souborů, z nichž každý má nějaký druh bitů a název blob nebo strom objekt, kterým je daný soubor, symbolický odkaz, nebo obsah adresáře. Tento objekt popisuje snapshot zdrojového stromu.
  • Commit objekt odkazuje stromy objektů do historie. Obsahuje název stromu objektu (na nejvyšší úrovni zdrojového adresáře), časové razítko, log zprávy a jména žádného nebo více mateřských commit objektů.
  • Tag objekt je kontejner, který obsahuje odkaz na jiný objekt a může mít další meta-dat 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í konkrétnímu poslaní údajů do repositáře (=začaly být sledovány Gitem).

Index slouží jako spojovací bod mezi objektovou databází a pracovním stromem.

Každý objekt má přidělen SHA-1 hash jeho obsahu. Git počítá hash a používá tuto hodnotu pro název daného objektu. Objekt je umístit do adresáře, kterému odpovídají první dva znaky jeho hashe. Zbytek hashe se používá jako název souboru pro daný objekt.

Git ukládá každou revizi souboru jakožto jedinečné blob objektu. Vztahy mezi bloby lze nalézt prostřednictvím zkoumání stromu a commit objektů. Nově přidané objekty jsou uloženy v celém svém rozsahu pomocí zlib kompresi. To může rychle spotřebovat velké množství místa na disku, takže objekty mohou být kombinovány do balíčků, které využívají delta komprese pro úsporu místa. To jest, ukládání blobů jako jejich změn ve srovnání s jinými bloby.

Git servery typicky naslouchají na TCP portu 9418.

Realizace Gitu[editovat | editovat zdroj]

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, Mac OS X a Windows NT.

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

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

Libgit2 realizace Gitu je ANSI C softwarová knihovna, která může být vystavěna na různých platformách včetně Microsoft Windows, Linux, Mac OS X a BSD. Používá se jako základ pro Git knihovny pro programovací jazyky Ruby, Python a Haskell a jako základní Git implementace v týmu Microsoft Foundation servis a Visual Studio.

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

Osvojení[editovat | editovat zdroj]

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. [48] 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:

Historie[editovat | editovat zdroj]

Vývoj Gitu začal, když se množství vývojářů Linuxového kernelu rozhodlo přestat pracovat s BitKeeperem (SCM systém, který byl již dříve použit k udržení projektu). Držitel autorských práv k BitKeeperu, Larry McVoy, stáhl bezplatné používání výrobku poté, co uvedl, že Andrew Tridgell prováděl reverzní inženýrství na protokolu BitKeeperu.

Linus Torvalds chtěl distribuovaný systém, který by mohl použít jako BitKeeper, ale žádný z dostupných volných systémů nesplňoval jeho potřeby, zejména co se týče výkonu. Torvalds stanovil jako požadavek SCM vyžadující třicet sekund na aplikování patche a aktualizaci všech souvisejících metadat. Při vývoji linuxového jádra, synchronizace s ostatními správci může vyžadovat klidně i 250 takových akcí najednou. Torvalds stanovil několik dalších návrhových kritérií:

  • Vezměme CVS za odstrašující příklad. Pokud si nejste jisti, udělejte to opačně.
  • Musí být distribuovaný + inspirovat se způsobem práce s BitKeeperem.
  • Velmi silná opatření pro zajištění integrity dat.

Tato tři kritéria eliminovala všechny tehdy existující systémy pro správu verzí s výjimkou Monotone. Ovšem vzhledem k požadavku na výkon byl Monotone vyloučen také. Bezprostředně po vydání verze 2.6.12-rc2 linuxového jádra se Linus Torvalds rozhodl napsat svůj vlastní systém.

Reference[editovat | editovat zdroj]

  1. JGit [online]. [cit. 2012-08-18]. Dostupné online.  
  2. EGit [online]. [cit. 2012-08-18]. Dostupné online.  
  3. . Dostupné online. (anglicky)  "Historické souvislosti" kolem předchůdců systému git
  4. . Dostupné online. (anglicky) 
  5. . Dostupné online. (anglicky) 
  6. . Dostupné online. (anglicky) 
  7. . Dostupné online. (anglicky) 
  8. 1=http://weblogs.mozillazine.org/jst/archives/2006/11/vcs_performance.html , http://weblogs.mozillazine.org/jst/archives/2006/11/vcs_performance.html , benchmarking "git diff" against "bzr diff", and finding the former 100× faster in some cases.
  9. Roland Dreier. Oh what a relief it is [online]. 2006-11-13. Dostupné online.  , observing that "git log" is 100× faster than "svn log" because the latter has to contact a remote server.
  10. . Dostupné online. (anglicky) , describing Git's script-oriented design
  11. iabervon. Git rocks! [online]. 2005-12-22. Dostupné online.  , praising Git's scriptability
  12. Git User's Manual [online]. 2007-08-05. Dostupné online.  
  13. . Dostupné online. (anglicky) 
  14. . Dostupné online. (anglicky) 
  15. . Dostupné online. (anglicky) 
  16. . Dostupné online. (anglicky) 
  17. . Dostupné online. (anglicky) 
  18. . Dostupné online. (anglicky) , on using git-blame to show code moved between source files
  19. Linus Torvalds. git-merge(1) [online]. 2007-07-18. Dostupné online.  
  20. Linus Torvalds. CrissCrossMerge [online]. 2007-07-18. Dostupné online.  
  21. Bright, Peter."Microsoft brings git support to its CodePlex hosting service", 22 March 2012. Ověřeno k 23 March 2012. 

Související články[editovat | editovat zdroj]

Externí odkazy[editovat | editovat zdroj]

Kategorie Git ve Wikimedia Commons