Výukový program Git: Začínáme s řízením verzí Git

Tento článek vás seznámí s Gitem, včetně toho, jak nainstalovat potřebný software pro přístup k serverům Git, kde bude uložen váš softwarový projekt.

Koncepty řízení verzí

Abychom pochopili Git a koncept řízení verzí, je užitečné podívat se na řízení verzí z historické perspektivy. Existují tři generace softwaru pro správu verzí.

První generace

První generace byla velmi jednoduchá. Vývojáři pracovali na stejném fyzickém systému a „rezervovali“ jeden soubor najednou.

Tato generace softwaru pro správu verzí využívala techniku zvanou zamykání souborů. Když vývojář rezervoval soubor, byl uzamčen, takže žádný jiný vývojář nemohl soubor upravit.

Mezi příklady softwaru pro řízení verzí první generace patří Revision Control System (RCS) a Source Code Control System (SCCS).

Druhá generace

Problémy s první generací zahrnovaly následující:

Na souboru mohl pracovat pouze jeden vývojář. To mělo za následek úzké místo v procesu vývoje.
Vývojáři se museli přihlásit přímo do systému, který obsahoval software pro správu verzí.

Tyto problémy byly vyřešeny u druhé generace softwaru pro správu verzí. Ve druhé generaci jsou soubory uloženy na centralizovaném serveru v úložišti. Vývojáři si mohou prohlédnout samostatné kopie souboru. Když vývojář dokončí práci na souboru, soubor se ohlásí do úložiště.

Pokud dva vývojáři zkontrolují stejnou verzi souboru, pak existuje potenciální problém. To řeší proces zvaný a spojit.

Co je to sloučení? Předpokládejme, že dva vývojáři, Bob a Sue, vyzkoušejí verzi 5 souboru s názvem abc.txt. Poté, co Bob dokončí práci, zkontroluje soubor zpět. Obvykle to má za následek novou verzi souboru, verzi 6.

O něco později Sue zkontroluje svůj spis. Tento nový soubor musí zahrnovat její změny a Bobovy změny. Toho je dosaženo procesem sloučení.

V závislosti na softwaru pro správu verzí, který používáte, mohou existovat různé způsoby zpracování tohoto sloučení. V některých případech, například když Bob a Sue pracovali na úplně jiných částech souboru, je proces sloučení velmi jednoduchý. V případech, kdy Sue a Bob pracovali na stejných řádcích kódu v souboru, však může být proces sloučení složitější. V takových případech bude Sue muset rozhodovat, například zda bude Bobův kód nebo její kód v nové verzi souboru.

Po dokončení procesu slučování proběhne proces potvrzení souboru do úložiště. Potvrdit soubor v zásadě znamená vytvořit novou verzi v úložišti; v tomto případě verze 7 souboru.

Mezi příklady softwaru pro správu verzí druhé generace patří Concurrent Versions System (CVS) a Subversion.

Třetí generace

Třetí generace se označuje jako distribuované systémy řízení verzí (DVCS). Stejně jako u druhé generace obsahuje centrální úložný server všechny soubory pro projekt. Vývojáři však nekontrolují jednotlivé soubory z úložiště. Místo toho je celý projekt rezervován, což vývojáři umožňuje pracovat na kompletní sadě souborů, nikoli pouze na jednotlivých souborech.

Další (velmi velký) rozdíl mezi druhou a třetí generací softwaru pro správu verzí souvisí s tím, jak funguje proces sloučení a odevzdání. Jak již bylo zmíněno dříve, kroky ve druhé generaci jsou provedení sloučení a potvrzení nové verze do úložiště.

Se softwarem pro správu verzí třetí generace jsou soubory zaevidovány a poté sloučeny.

Řekněme například, že si dva vývojáři prohlédnou soubor založený na třetí verzi. Pokud jeden vývojář zkontroluje tento soubor, což má za následek verzi 4 souboru, musí druhý vývojář nejprve sloučit změny ze své rezervované kopie se změnami verze 4 (a případně i dalších verzí). Po dokončení sloučení lze novou verzi uložit do úložiště jako verzi 5.

Pokud se zaměříte na to, co je v úložišti (střední část každé fáze), uvidíte, že existuje velmi přímá linie vývoje (ver1, ver2, ver3, ver4, ver5 atd.). Tento jednoduchý přístup k vývoji softwaru představuje některé potenciální problémy:

Požadavek sloučení vývojáře před spácháním často vede k tomu, že vývojáři nechtějí pravidelně provádět změny. Proces sloučení může být nepříjemný a vývojáři se mohou rozhodnout, že počkají až později a provedou jedno sloučení, spíše než spoustu pravidelných sloučení. To má negativní dopad na vývoj softwaru, protože najednou jsou do souboru přidány obrovské kusy kódu. Kromě toho chcete povzbudit vývojáře, aby prováděli změny v úložišti, stejně jako chcete povzbudit někoho, kdo píše dokument, aby pravidelně ukládali.
Velmi důležité: Verze 5 v tomto příkladu není nutně prací, kterou vývojář původně dokončil. Během procesu slučování může vývojář zahodit část své práce, aby dokončil proces sloučení. To není ideální, protože to vede ke ztrátě potenciálně dobrého kódu.

Lze použít lepší, i když pravděpodobně složitější techniku. To se nazývá směrovaný acyklický graf (DAG).

Představte si stejný scénář jako výše, kde si dva vývojáři vyzkouší verzi 3 souboru. Tady, pokud jeden vývojář tento soubor zkontroluje, bude stále výsledkem verze 4 souboru. Výsledkem druhého procesu odbavení je však soubor verze 5, který není založen na verzi 4, ale je nezávislý na verzi 4. V další fázi procesu jsou verze 4 a 5 souboru sloučeny a vytvoří verzi 6.

I když je tento proces složitější (a potenciálně mnohem složitější, pokud máte velký počet vývojářů), poskytuje některé výhody oproti jedné linii vývoje:

Vývojáři mohou provádět své změny pravidelně a nemusí se starat o sloučení až později.
Proces sloučení lze delegovat na konkrétního vývojáře, který má lepší představu o celém projektu nebo kódu, než mají ostatní vývojáři.
Projektový manažer se může kdykoli vrátit a zjistit, jaké dílo vytvořil každý vývojář.

Určitě existuje argument pro obě metody. Mějte však na paměti, že tento článek se zaměřuje na Git, který používá metodu řízeného acyklického grafu systémů pro správu verzí třetí generace.

Instalace Git

Možná už máte Git ve svém systému, protože je někdy nainstalován ve výchozím nastavení (nebo jej mohl nainstalovat jiný správce). Pokud máte přístup do systému jako běžný uživatel, můžete provést následující příkaz a zjistit, zda máte nainstalovaný Git:

ocs @ ubuntu: ~ $ který git / usr / bin / git

Pokud je nainstalován Git, pak cesta k sakra je poskytnut příkaz, jak je znázorněno v předchozím příkazu. Pokud není nainstalován, pak buď nedostanete žádný výstup, nebo chybu, jako je následující:

[ocs @ centos ~] # which git / usr / bin / which: no git in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/ bin: / usr / sbin: / bin: / sbin: / root / bin)

Jako správce v systému založeném na Debianu můžete použít dpkg příkaz k určení, zda byl nainstalován balíček Git:

root @ ubuntu: ~ # dpkg -l git Požadováno = Neznámý / Instalovat / Odstranit / Vyčistit / Zadržet | Status = Not / Inst / Conf-files / Unpacked / halF-conf / Half-inst / trig-aWait / ➥Trig-pend | / Err? = (None) / Reinst-required (Status, Err: uppercase = bad) | | / Název Verze Architektura Popis +++ - ======== - ============= - ============= - === ===================================== ii git 1: 1.9.1-1ubun amd64 rychlý, škálovatelný , distribuováno ➥revision con

Jako správce v systému založeném na Red Hat můžete použít ot / min příkaz k určení, zda byl nainstalován balíček git:

[root @ centos ~] # rpm -q git git-1.8.3.1-6.el7_2.1.x86_64

Pokud ve vašem systému není nainstalován Git, musíte se buď přihlásit jako uživatel root, nebo použít sudo nebo su k instalaci softwaru. Pokud jste přihlášeni jako uživatel root v systému založeném na Debianu, můžete k instalaci Gitu použít následující příkaz:

apt-get install git

Pokud jste přihlášeni jako uživatel root v systému založeném na Red Hat, můžete k instalaci Gitu použít následující příkaz:

yum nainstalovat git

Získejte více než Git

Zvažte instalaci softwarového balíčku git-all. Tento balíček obsahuje několik dalších balíčků závislostí, které dodávají Git více výkonu. Ačkoli tyto funkce na začátku nemusíte používat, bude dobré mít je k dispozici, až budete připraveni provádět pokročilejší funkce Git.

Git koncepty a funkce

Jednou z výzev při používání Gitu je pochopení konceptů, které jsou za ním. Pokud nerozumíte konceptům, pak všechny příkazy vypadají jako nějaká černá magie. Tato část se zaměřuje na kritické koncepty Git a seznamuje vás s některými základními příkazy.

Gitové fáze

Je velmi důležité si uvědomit, že jste zkontrolovali celý projekt a že většina vaší práce bude místní v systému, na kterém pracujete. Soubory, které rezervujete, budou umístěny do adresáře ve vašem domovském adresáři.

Chcete-li získat kopii projektu z úložiště Git, použijte proces s názvem klonování. Klonování nevytváří pouze kopii všech souborů z úložiště; ve skutečnosti plní tři primární funkce:

Vytvoří místní úložiště projektu pod název projektuadresář /.git ve vašem domovském adresáři. Soubory projektu v tomto umístění se považují za rezervované z centrálního úložiště.
Vytvoří adresář, kde můžete přímo vidět soubory. Tomu se říká pracovní oblast. Změny provedené v pracovní oblasti nejsou okamžitě kontrolovány verzí.
Vytvoří pracovní plochu. Pracovní oblast je navržena tak, aby ukládala změny souborů, než je potvrdíte v místním úložišti.

To znamená, že pokud byste klonovali projekt s názvem Jacumba, celý projekt by byl uložen do souboru Jacumba / .git adresář ve vašem domovském adresáři. Neměli byste se pokoušet tyto úpravy přímo. Místo toho se podívejte přímo do ~ / Jacumba adresář tol zobrazit soubory z projektu. Toto jsou soubory, které byste měli změnit.

Předpokládejme, že jste provedli změnu souboru, ale než budete připraveni provést změny v místním úložišti, musíte na některých dalších souborech pracovat. V takovém případě ano etapa soubor, na kterém jste dokončili práci. To by připravilo jeho závazek k místnímu úložišti.

Po provedení všech změn a ustavení všech souborů je odevzdáte do místního úložiště.

Uvědomte si, že potvrzení postupných souborů je odešle pouze do místního úložiště. To znamená, že k provedeným změnám máte přístup pouze vy. Proces kontroly nových verzí do centrálního úložiště se nazývá a tam.

Výběr hostitele úložiště Git

Za prvé, dobrá zpráva: Mnoho organizací poskytuje Git hosting - v době psaní tohoto článku existuje více než dvě desítky možností. To znamená, že máte na výběr z mnoha možností. To jsou dobré zprávy ... a špatné zprávy.

Je to jen špatná zpráva, protože to znamená, že opravdu musíte věnovat nějaký čas zkoumání výhod a nevýhod hostitelských organizací. Například většina neúčtuje poplatky za základní hosting, ale účtuje si poplatky za rozsáhlé projekty. Některé poskytují pouze veřejné úložiště (vaše úložiště může zobrazit kdokoli), zatímco jiné vám umožňují vytvářet soukromá úložiště. Je třeba vzít v úvahu mnoho dalších funkcí.

Jednou z funkcí, která může být na vašem seznamu vysoko, je webové rozhraní. Ačkoli můžete provádět téměř všechny operace úložiště lokálně ve vašem systému, může být velmi užitečné provádět některé operace prostřednictvím webového rozhraní. Než se rozhodnete, prozkoumejte poskytované rozhraní.

Přinejmenším doporučuji zvážit následující:

//bitbucket.org
//www.cloudforge.com
//www.codebasehq.com
//github.com
//gitlab.com

Všimněte si, že jsem si pro níže uvedené příklady vybral Gitlab.com. Kterýkoli z hostitelů v předchozím seznamu by fungoval stejně dobře; Vybral jsem si Gitlab.com jednoduše proto, že to byl ten, který jsem použil na svém posledním projektu Git.

Konfigurace Git

Nyní, když jste prošli celou teorií, je čas s Gitem něco udělat. Tato další část předpokládá následující:

Nainstalovali jste sakra nebo git-all softwarový balíček ve vašem systému.
Vytvořili jste účet v hostitelské službě Git.

První věcí, kterou chcete udělat, je provést základní nastavení. Kdykoli provedete operaci potvrzení, vaše jméno a e-mailová adresa budou zahrnuta do metadat. Chcete-li nastavit tyto informace, proveďte následující příkazy:

ocs @ ubuntu: ~ $ git config --global user.name "Bo Rothwell" ocs @ ubuntu: ~ $ git config --global user.email "[email protected]"

Je zřejmé, že nahradíte „Bo Rothwell“ se svým jménem a „[email protected]“ s vaší e-mailovou adresou. Dalším krokem je klonování projektu z hostitelské služby Git. Před klonováním je v domovském adresáři uživatele pouze jeden soubor: