Git

Z Wikipedie, otevřené encyklopedie
Skočit na: Navigace, Hledání
Git
Logo
Vývojář Junio Hamano, Linus Torvalds
Aktuální verze 2.7.2 (22. února 2016)
Operační systém Linux, POSIX, Windows, OS X
Vyvíjeno v C (programovací jazyk), Bourne shell, Tcl, Perl
Typ softwaru Verzovací systém
Licence GPL v2
Web http://git-scm.com

Git je v informatice distribuovaný systém správy verzí vytvořený Linusem Torvaldsem pro vývoj jádra Linuxu. Návrh Gitu byl ovlivněn projekty BitKeeper (dříve používán pro vývoj jádra Linuxu) a Monotone. V současnosti (2016) je projekt Git používán mnoha známými projekty, například: jádro Linuxu, X.Org nebo Ruby on Rails. Projekt spravuje Junio Haman, je šířen pod GPL verze 2 a jedná se o svobodný software.

Charakteristika[editovat | editovat zdroj]

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

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ě[5] a podpora ve formě plug-inu EGit[6] 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 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 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ý.[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] 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ů[11].
  • 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é.[12]

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[13], 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.[14] 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.[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 procesoru 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 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 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).

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

Každou revizi souboru Git ukládá 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.[21]

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 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, 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í 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.

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ři sekundy na aplikování záplaty (patch) 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í linuxového jádra verze 2.6.12-rc2 se Linus Torvalds rozhodl napsat svůj vlastní systém.

Odkazy[editovat | editovat zdroj]

Reference[editovat | editovat zdroj]

  1. . [1]. (anglicky)  "Historické souvislosti" kolem předchůdců systému git
  2. . [2]. (anglicky) 
  3. . [3]. (anglicky) 
  4. . [4]. (anglicky) 
  5. JGit [online]. [cit. 2012-08-18]. Dostupné online.  
  6. EGit [online]. [cit. 2012-08-18]. Dostupné online.  
  7. . [5]. (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. . [6]. (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. . [7]. (anglicky) 
  14. . [8]. (anglicky) 
  15. . [9]. (anglicky) 
  16. . [10]. (anglicky) 
  17. . [11]. (anglicky) 
  18. . [12]. (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. Service Name and Transport Protocol Port Number Registry [online]. IANA (Internet Assigned Numbers Authority). Dostupné online.  
  22. 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]