Git

Z Multimediaexpo.cz

Broom icon.png Tento článek potřebuje úpravy. Můžete Multimediaexpo.cz pomoci tím, že ho vylepšíte.
Jak by měly články vypadat, popisují stránky Vzhled a styl a Encyklopedický styl. 		Broom icon.png



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 mělo jednat 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 egit v Javě ve formě plug-inu pro Eclipse.


Obsah

Charakteristika

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]

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ý.[5] 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).[6][7]
  • 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í.[8] 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ů[9].
  • 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é.[10]

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[11]. 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.[12] 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.[13][14] 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[15]. 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).[16] (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í:[17]

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

Související články

Reference

  1. ↑ "Historické souvislosti" kolem předchůdců systému git
  2. ↑ {{cite mailing list |mailinglist=linux-kernel | url=http://lkml.org/lkml/2005/4/8/9 | autor=Linus Torvalds | titul=Re: Kernel SCM saga | datum=2005-04-07}}
  3. ↑
  4. ↑
  5. ↑
  6. ↑ , benchmarking "git diff" against "bzr diff", and finding the former 100x faster in some cases.
  7. ↑ Roland Dreier. Oh what a relief it is [online]. 2006-11-13. Dostupné online.  , observing that "git log" is 100x faster than "svn log" because the latter has to contact a remote server.
  8. ↑ , describing Git's script-oriented design
  9. ↑ iabervon. Git rocks! [online]. 2005-12-22. Dostupné online.  , praising Git's scriptability
  10. ↑ Git User's Manual [online]. 2007-08-05. Dostupné online.  
  11. ↑
  12. ↑
  13. ↑
  14. ↑
  15. ↑
  16. ↑ , on using git-blame to show code moved between source files
  17. ↑ Linus Torvalds. git-merge(1) [online]. 2007-07-18. Dostupné online.  
  18. ↑ Linus Torvalds. CrissCrossMerge [online]. 2007-07-18. Dostupné online.  

Externí odkazy


Citováno z „http://www.multimediaexpo.cz/mmecz/index.php/Git“