GIT

Ať už používáte GIT ve skupince kolegů nebo pro samotářský vývoj, několika repositářům se nevyhnete. Já mám pro každý projekt jeden repositář na netbooku, na server a nakonec ten hlavní mám na desktopu, kde probíhá většinou nejrušivější vývoj. Je tedy nezbytně nutné, abychom uměli s těmito repositáři komunikovat, přelívat kód z jednoho do druhého a navíc, abychom uměli řešit situaci, kdy pracujeme na nějaké funkci a ve vzdáleném repositáři došlo k nějakým změnám, protože bylo třeba potřeba něco opravit. Hlavně ze začátku, než pochopíte, jak GIT s vaším kódem pracuje, je důležité se držet postupů, které nezničí změny na jednom či druhém místě.

Klíčem ke všem vzdáleným operacím jsou příkazy:

• remote
• push
• pull
• fetch

Začneme tím, že si pojmenujeme všechny vzdálené stroje v repositáři. To se dělá pomocí příkazu remote. GIT umí pracovat téměř se vším, co umí nějak přenášet adresářovou strukturu, ale tento seriál bude zaměřen primárně na SSH a to jak z důvodu jednoduchosti, tak bezpečnosti.

Velmi zjednodušený výtažek z manuálu vám pomůže pochopit, jak se s remote pracuje. Jde vlastně o takové aliasy, kterými pojmenujete vzdálené repositáře a pod nimi je pak bude GIT znát. Pokud používáte SSH, je nutné pro přístup k repositáři vyplnit adresu server (v horším případě IP) a pak cestu repositáři. Výsledek může vypadat třeba takhle:

Všimněte si, že je potřeba vyplnit vcelku nezapamatovatelná IP adresa, jméno uživatele a pak cestu k repositáři, která je v tomto případě ještě docela krátká. Také si všimněte, že jsem použil zatím neznámý příkaz clone. S ním lze naklonovat nějaký vzdálený repositář a pak budete mít na lokálním stroji jeho přesnou kopii. To se samozřejmě dělá jen u vytváření repositářů, takže na existující lokální repositář to nepoužívejte.

Nebudeme dál otálet a vytvoříme si alias pomocí příkazu remote.

Pokračovat dál na příkladu klonování není zrovna dobrý nápad, takže na novém aliasu vyzkoušíme příkaz pull:

Tímto jsme zajistili, že se změny udělané v repositáři repo1 natáhnou k nám. Pokud dojde ke konfliktům, je potřeba je vyřešit, ale o tom bude jeden z dalších dílů. Když takto chudě osázený příkaz pull spustíte, vyběhne vám dlouhý text, který vám mimo jiné oznámí, že se GIT pokusil stáhnout obsah všech větví ve vzdáleném repositáři, jejichž název se shoduje s názvy lokálních větví. O větvích budeme pro změnu mluvit v příštím díle a tuto informaci vám sděluji hlavně proto, abyste nepanikařili.

Když stáhnete změny, musíte si uvědomit, že se nezměnil pracovní adresář jak jste zvyklí třeba z SVN, ale jenom obsah repositáře. Proto je potřeba dávat pozor, abyste měli před použitím pull vše commitlé a pracovní adresář zůstal shodný s obsahem repositáře. To si překontrolujte pomocí příkazu status, o kterém jsme již mluvili. Pokud by se vám náhodou povedlo nejdříve stáhnout změny pomocí pull a až potom jste commitly pracovní adresář, změny, které jste stáhli se smažou, resp. se uloží commit, který udělá jejich přesný opak, takže repositář bude nakonec ve stavu před staženými změnami a bude v něm uložen rozdíl jak pro vytvoření stažených změn, tak pro jejich zrušení.

Víme na co si dát pozor a teď nastal čas uvést pracovní adresář do stavu v jakém se nachází repositář. To uděláme pomocí příkazu reset:

Parametr –hard říká, že se nemá brát na nic ohled a změny, které jsou v pracovním adresáři provedený se tím pádem ztratí. Příkaz reset má ještě jeden velmi užitečný parametr a názvem –merge, který by mohl v příkladu nahradit –hard. Ten se pokusí sjednotit stáhnuté změny a zároveň udržet změny v pracovním adresáři. V této fázi ho nedoporučuji používat, protože byste se mohli dostat do situace, kdy by byl potřeba vyřešit nějaký konflikt a těm je lepší se momentálně vyhýbat. Až si probereme řešení konfliktů, bude ten správný čas hrát si s –merge, zatím platí varování výše.

Když uděláme všechny změny co jsme chtěli, je čas odeslat je do vzdáleného repositáře. Tento postup také moc nedoporučuji a pokud je to možné, spíše se přiklánějte ke stahování změn od vás z druhé strany. Pokud totiž na druhé straně opět došlo k nějakým změnám, commity se neodešlou a budete to muset udělat tak jako tak z druhé strany.

K odeslání změn slouží příkaz push.

Nakonec ještě jednu poznámku a tou také skončíme. Jak jsem řekl, GIT používám hlavně přes SSH, ale určitě se setkáte ještě s minimálně jednou formou vzdáleného repositáře a to je jiný lokální repositář. K němu přistupujeme pouhým zadáním cesty, třeba:

Můžeme samozřejmě vytvořit i alias:

A používat pull/push podle libosti:

Příště se podíváme na práci s větvemi, které se nám budou velmi hodit k příkazům push, pull a nakonec i zatím neznámým příkazům merge a rebase.

Při své práci mimo Root.cz používám hlavně čtyři technologie/nástroje, bez kterých bych se dnes už asi neobešel. Převážně programuji různé většinou webové aplikace a starám se o servery. Někdy se obě činnosti propojují a když už se do něčeho opravdu pustím, vzniká u toho hromada kódů všech kvalit a je potřeba všechen kód dát nějak dohromady, aby byla možnost ho používat ještě jinde. To krom roků zkušeností a nezdarů vyžaduje i pořádnou správu verzí, abyste věděli, co jste kdy dělali.

Proto chci na svém blogu každé pondělí vydávat krátký post o některé funkci GITu a postupně tak dostat čtenáře do stavu, kdy bude schopen GIT používat taky.

Pokud jste nedočkaví, určitě vám pomůže těchto několik odkazů:

• Domácí stránka GITu
• Pro Git – knížka přeložená do čeština díky CZ.NIC
• Seriál na Root.cz

Pravou sílou GITu je, že všichni vývojáři mají rovná práva. Tím mám namysli, že každý vývojář má jeden či více svých repositářů s několika větvemi vývoje, kde dává dohromady na ostatních nezávislý kód. Ten postupně nahrává do svého repositáře a jednotlivým změnám se říká commit. Každý commit má identifikátor, podle kterého s ním můžete dále pracovat, ale osobně to moc často nedělám, leda ve chvíli, kdy je potřeba najít nějaká chyba, ale o tom až někdy za hodně dlouho, protože tak rozsáhlý kód, abych fičury na hledání chyb potřeboval jsem ještě nedělal.

Levou sílou GITu jsou větve. Znáte takové ty situace, kdy je potřeba udělat nějaká změna na produkční verzi, často oprava nevyhnutelného bugu, ale u sebe máte rozkopanou verzi, která rozhodně nemůže ven a tam ta chyba je taky? S GITem prostě pracujete v nějaké vývojové větvi a na serveru je třeba větev master. Klidně si uděláte několik změn ve větvi master a na vývojovou větev nehledíte. Když máte všechny nové vlastnosti hotovy a odzkoušeny, jednoduše nejdříve změníte základ vaší vývojové větve na větev master a po vyřešení konfliktů (které přijít nemusí) je změna uložena i tam a můžete obě větve hezky spojit.

Ještě než začneme, musíme si GIT nakonfigurovat, přesněji nadefinovat jméno a e-mail, se kterými GIT pracuje:

Ve vašem domácím adresáři se vytvoří soubor ~/.gitconfig s obsahem:

[user]
	name = Adam
	email = cx@initd.cz

Abych vás nenechal na konci jen tak koukat do země, vytvoříme si náš první repositář:

Tím jsme vytvořily repositář a poznáme ho tak, že po napsání:

dostaneme něco jako:

V adresáři .git se budou ukládat všechny vaše změny, které uděláte v adresáři s repositářem, kterému se říká pracovní adresář.

Provedené změny vypíšete pomocí:

A to je pro dnešek vše, příště se podíváme na vytváření commitů a pamatujte, GIT byl vytvořen pro vývoj jádra a i když se může zdát ze začátku složitý, po prvním pár commitech si ho zamilujete.