2.2 Základy práce se systémem Git - Nahrávání změn do repozitáře

Hlavním nástrojem na zjišťování stavu jednotlivých souborů je příkaz git status. Spustíte-li tento příkaz bezprostředně po klonování, objeví se zhruba následující:

To znamená, že váš pracovní adresář je čistý. Jinými slovy, nejsou v něm žádné sledované soubory, které by byly změněny. Git také neví o žádných nesledovaných souborech, jinak by byly ve výčtu uvedeny. Příkaz vám dále sděluje, na jaké větvi (branch) se nacházíte, a informuje vás, že se neodchýlila od stejné větve na serveru. Prozatím budeme uvažovat, že jde o větev master, což je výchozí název (zatím se s tím nezatěžujte). V kapitole Větve v systému Git se větvemi a referencemi budeme zabývat podrobně.

Řekněme, že nyní přidáte do projektu nový soubor, například soubor README. Pokud soubor dříve neexistoval a vy spustíte příkaz git status, bude nesledovaný soubor uveden takto:

Vidíte, že nový soubor README není sledován, protože je ve výpisu stavů uveden v části „Untracked files“. Není-li soubor sledován, znamená to, že Git vidí soubor, který nebyl v předchozím snímku (commit). Git ho nezařadí ani do dalších snímků, dokud mu k tomu nedáte výslovný příkaz. Díky tomu se nemůže stát, že budou do revizí nedopatřením zahrnuty vygenerované binární soubory nebo jiné soubory, které si nepřejete zahrnout. Vy si ale přejete soubor README do snímku zahrnout, a proto ho začněme sledovat.

K zahájení sledování nových souborů se používá příkaz git add. Sledování souboru README zahájíme takto:

Když znovu provedete příkaz git status, uvidíte, že je nyní soubor README sledován a připraven k zapsání:

Můžeme říci, že je připraven k zapsání, protože je uveden v části „Changes to be committed“, tedy „Změny k zapsání“. Pokud v tomto okamžiku zapíšete revizi (commit), bude do historického snímku uložena verze souboru z okamžiku, kdy jste spustili příkaz git add. Možná si vzpomínáte, že když jste před časem spustili příkaz git init, provedli jste potom příkaz git add (soubory). V příkazu git add je uvedena cesta buď k souboru, nebo k adresáři. Pokud se jedná o adresář, příkaz přidá rekurzivně všechny soubory v tomto adresáři.

Nyní provedeme změny v souboru, který už byl sledován. Pokud změníte už dříve sledovaný soubor s názvem CONTRIBUTING.md a poté znovu spustíte příkaz git status, zobrazí se něco takového:

Soubor CONTRIBUTING.md je uveden v části „Changes not staged for commit“ (změny, které nejsou připraveny k zapsání). Znamená to, že soubor, který je sledován, byl v pracovním adresáři změněn, avšak ještě nebyl připraven k zapsání (staged). K zapsání ho připravíme provedením příkazu git add. Příkaz git add je víceúčelový — používá se k zahájení sledování nových souborů, k přípravě souborů k zapsání a k dalším věcem, jako je například označení vyřešených případů kolize souborů při slučování. Možná vám pomůže, když o něm budete uvažovat spíše ve smyslu „přidej tento obsah do dalšího snímku“ než ve smyslu „přidej tento soubor do projektu“. Spusťme nyní příkaz git add, abychom soubor CONTRIBUTING.md připravili k zapsání, a potom znovu zadejme příkaz git status:

Oba soubory jsou nyní připraveny k zapsání a budou zahrnuty do příští revize. Nyní předpokládejme, že jste si vzpomněli na jednu malou změnu, kterou chcete v souboru CONTRIBUTING.md provést ještě před zapsáním revize. Soubor znovu otevřete, provedete změnu a chcete jej zapsat. Spusťme však ještě jednou příkaz git status:

Co to má být? Soubor CONTRIBUTING.md je uveden jak v části připraveno k zapsání (Changes to be committed), tak v části nepřipraveno k zapsání (Changes not staged for commit). Jak je tohle možné? Věc se má tak, že Git po spuštění příkazu git add připraví soubor k zapsání přesně ve tvaru, v jakém se nachází v daném okamžiku. Pokud nyní revizi zapíšete, stane se součástí snímku soubor CONTRIBUTING.md s obsahem, jaký měl, když jste naposledy spustili příkaz git add, a ne s obsahem, který měl v pracovním adresáři v okamžiku, kdy jste spustili příkaz git commit. Pokud upravíte soubor po provedení příkazu git add, je třeba spustit git add ještě jednou, aby byla k zápisu připravena aktuální verze souboru:

Výstup příkazu git status je sice poměrně srozumitelný, ale je také dost ukecaný. Git nabízí použití příznaku pro zkrácený výpis stavu, který způsobí zobrazení změn v zhuštěné podobě. Pokud spustíte git status -s nebo git status --short bude výstup příkazu mnohem jednodušší:

Před novými soubory, které nejsou sledované se zobrazuje ??, před novými soubory, které byly přidány do oblasti připravených k zapsání se zobrazuje A, před upravenými soubory se zobrazuje M (jako modified) atd. Na výstupu se zobrazují dva sloupce. Levý sloupec indikuje stav souboru v oblasti připravených změn (index, stage area), v pravém sloupci se indikuje stav v pracovním stromu. Takže například v uvedeném výstupu byl soubor README změněn v pracovním adresáři, ale nebyl zatím připraven k zápisu (staged), zatímco soubor lib/simplegit.rb byl změněn a připraven k zápisu. Soubor Rakefile byl změněn, připraven k zápisu a potom znovu změněn, takže se indikuje změna jak pro oblast připravenosti k zápisu, tak pro pracovní strom.

Ve vašem adresáři se často vyskytne skupina souborů, u nichž nebudete chtít, aby je Git automaticky přidával nebo aby je vůbec uváděl jako nesledované. Jedná se většinou o automaticky vygenerované soubory, jako soubory log nebo soubory vytvořené při překladu. V takových případech můžete vytvořit soubor .gitignore se seznamem masek pro ignorované soubory. Zde je příklad souboru .gitignore:

První řádek Gitu říká, že se mají ignorovat všechny soubory končící na .o nebo .a — objekty a archivní soubory, které mohou být výsledkem překladu. Druhý řádek Gitu říká, aby ignoroval všechny soubory, jejichž jméno končí vlnovkou (~), kterou mnoho textových editorů (např. Emacs) používá k označení dočasných souborů. Můžete rovněž přidat adresáře log, tmp nebo pid, automaticky vygenerovanou dokumentaci a další. Většinou je dobré, když soubor .gitignore vytvoříte a naplníte ještě dříve, než se pustíte do práce. Díky tomu se vám nestane, že byste nedopatřením zapsali také soubory, o které v gitovém repozitáři nestojíte.

Pravidla pro masky, které můžete použít v souboru .gitignore, jsou následující:

Masky souborů se podobají zjednodušeným regulárním výrazům, které znáte z shellu. Hvězdička (*) označuje žádný nebo více znaků; [abc] označuje jakýkoli znak uvedený v závorkách (v tomto případě a, b nebo c); otazník (?) označuje jeden znak; znaky v hranatých závorkách oddělené pomlčkou ([0-9]) označují jakýkoli znak v daném rozmezí (v našem případě 0 až 9). Použitím dvou hvězdiček můžeme popsat zanořené adresáře; a/**/z popisuje a/z, a/b/z, a/b/c/z a tak dále.

Další příklad souboru .gitignore:

Pokud je pro vás příkaz git status příliš neurčitý — chcete přesně vědět, co jste změnili, nejen jaké soubory jste změnili --, můžete použít příkaz git diff. Podrobněji se budeme příkazu git diff věnovat později, ale nejčastěji ho budete využívat k zodpovězení těchto dvou otázek: Co jste změnili, ale ještě nepřipravili k zapsání? A co jste připravili k zapsání? Ačkoliv příkaz git status vám tyto otázky velmi obecně odpoví, příkaz git diff přesně zobrazí přidané a odstraněné řádky — jakoby v podobě záplaty.

Řekněme, že znovu upravíte a připravíte soubor README a poté upravíte soubor CONTRIBUTING.md, ale nepřipravíte jej k zápisu. Pokud provedete příkas git status, uvidíte opět něco takového:

Pokud chcete vidět, co jste změnili, ale zatím nepřipravili k zapsání, napište git diff bez dalších parametrů:

Tento příkaz porovná obsah vašeho pracovního adresáře s tím, co se nachází v oblasti připravených změn. Výsledek vám řekne, jaké změny jste provedli a dosud nepřipravili k zapsání.

Chcete-li vidět, co jste připravili a co bude součástí příští revize, použijte příkaz git diff --staged. Tento příkaz porovná změny připravené k zapsání vůči poslední zapsané revizi:

Důležité je to, že git diff sám o sobě nezobrazí všechny změny provedené od poslední revize, ale jen změny, které zatím nejsou připraveny k zapsání. Může to být matoucí, protože pokud jste všechny provedené změny připravili k zapsání, bude výstup příkazu git diff prázdný.

Další příklad…​ Pokud jste soubor CONTRIBUTING.md připravili k zapsání a poté ho znovu upravili, můžete příkaz git diff použít k zobrazení změn v souboru, které byly připraveny k zapsání, a změn, které nejsou připraveny k zapsání. Dejme tomu, že situace vypadá následovně:

Příkazem git diff se teď můžete podívat, co ještě není připraveno k zapsání:

a příkaz git diff --cached ukáže změny, které už jsou připraveny k zapsání (--staged a --cached jsou synonyma):

Nyní, když jste oblast připravených změn nastavili podle svých představ, můžete začít zapisovat změny (commit). Nezapomeňte, že všechno, co dosud nebylo připraveno k zapsání — všechny soubory, které jste vytvořili nebo změnili a pro které jste potom nepoužili git add --, nebudou do revize zahrnuty. Zůstanou na vašem disku jako změněné soubory. V tomto případě jste viděli (dejme tomu, když jste naposledy spustili git status), že vše bylo připraveno k zapsání, takže jste připraveni k samotnému zápisu. Nejjednodušší způsob spočívá v provedení git commit:

Po zadání příkazu se otevře vámi zvolený editor. (Ten je nastaven proměnnou prostředí $EDITOR vašeho shellu. Obvykle je to vim nebo emacs, ale příkazem git config --global core.editor můžete nastavit libovolný jiný — jak jsme viděli v kapitole Úvod).

Editor zobrazí následující text (tento příklad je z editoru Vim):

Jak vidíte, výchozí zpráva k revizi obsahuje zakomentovaný aktuální výstup příkazu git status a nahoře jeden prázdný řádek. Tyto komentáře můžete odstranit a napsat vlastní zprávu k revizi, nebo je můžete v souboru ponechat, abyste si lépe vzpomněli, co vlastně zapisujete. (Chcete-li si ještě podrobněji připomenout, co jste měnili, můžete k příkazu git commit přidat parametr -v. V editoru se pak zobrazí také výstup rozdílů (diff), takže uvidíte přesně, jaké změny budete zapisovat.) Jakmile editor zavřete, Git vytvoří objekt revize se zprávou, kterou jste napsali (s odstraněnými komentáři, které zobrazovaly rozdíly).

Zprávu k revizi můžete rovněž napsat do řádku k příkazu commit. Jako zprávu ji označíte tak, že před ni vložíte příznak -m:

Nyní jste vytvořili svou první revizi! Vidíte, že se po zapsání revize zobrazil výpis s informacemi: do jaké větve jste revizi zapsali (master), jaký má revize kontrolní součet SHA-1 (463dc4f), kolik souborů bylo změněno a statistiku přidaných a odstraněných řádků revize.

Nezapomeňte, že příkaz commit zaznamená snímek projektu, jak byl obsažen v oblasti připravených změn. Vše, co jste nepřipravili k zapsání, zůstane ve stavu změněno na vašem disku. Můžete provést další zápis a přidat to také do vaší historie. Pokaždé, když provedete příkaz commit, nahrajete snímek svého projektu, k němuž se můžete později vrátit nebo ho můžete použít k srovnání.

Oblast připravených změn může být úžasně užitečným nástrojem pro vytváření chtěné posloupnosti revizí, ale při určitém způsobu práce někdy představuje zbytečnou komplikaci. Chcete-li oblast připravených změn úplně přeskočit, nabízí Git jednoduchou zkratku. Přidáte-li k příkazu git commit parametr -a, Git do revize automaticky zahrne každý soubor, který je sledován. Odpadá potřeba zadávat příkaz git add:

Povšimněte si, že kvůli souboru CONTRIBUTING.md v tomto případě nemusíte před zapsáním revize provádět příkaz git add. To proto, že příznak -a přidá všechny změněné soubory. Je to praktické, ale buďte opatrní. Někdy se stane, že si tímto příznakem přidáte nechtěné změny.

Chcete-li soubor z Gitu odstranit, musíte ho odstranit ze sledovaných souborů (přesněji řečeno, musíte ho odstranit z oblasti připravených změn) a poté zapsat revizi. Je k tomu určen příkaz git rm, který soubor odstraní také z vašeho pracovního adresáře, takže ho už příště neuvidíte mezi nesledovanými soubory.

Pokud soubor jednoduše odstraníte z pracovního adresáře, zobrazí se ve výpisu git status v části „Changes not staged for commit“ (tedy „Změny nejsou připraveny k zapsání“):

Pokud ale provedete git rm, odstranění souboru bude připraveno k zapsání:

Při příštím zápisu (commit) už tam soubor neuvidíte a nebude se sledovat. Pokud už jste soubor upravili a už jste ho přidali do indexu, musíte odstranění vynutit přidáním volby -f ^[6]. Jde o funkci zvyšující bezpečnost tím, že brání nechtěnému odstranění dat, která ještě nebyla zaznamenána do snímku, a proto by nemohla být Gitem obnovena.

Další užitečnou věcí, kterou byste mohli chtít, je možnost zachování souboru v pracovním stromu při současném odstranění z oblasti připravených změn. Jinými slovy, soubor chcete ponechat na disku, ale už nechcete, aby ho Git sledoval. Může to být zvlášť užitečné, pokud jste něco zapomněli přidat do souboru .gitignore a omylem jste to zahrnuli do oblasti připravených změn — například velký log soubor nebo spoustu zkompilovaných souborů s příponou .a. Provedete to pomocí volby --cached:

Příkazu git rm můžete zadat soubory, adresáře a jejich masky. To znamená, že můžete zadat příkaz jako:

Všimněte si zpětného lomítka (\) před znakem *. Je to nezbytné, protože Git provádí své vlastní nahrazování masek souborů (kromě toho, které provádí shell). Uvedeným příkazem odstraníte všechny soubory s příponou .log z adresáře log/. Provést můžete také tento příkaz:

Tento příkaz odstraní všechny soubory, jejichž jména končí vlnovkou (~).

Na rozdíl od ostatních systémů pro správu verzí, Git nesleduje přesouvání souborů přímo. Pokud soubor v systému Git přejmenujete, neuloží se žádná metadata s informací, že jste soubor přejmenovali. Nicméně, Git je dost chytrý na to, aby to zjistil. Detekcí přesunu souboru se budeme zabývat později.

Takže se může zdát zvláštní, že Git přesto nabízí příkaz mv. Chcete-li v systému Git přejmenovat soubor, můžete provést něco takového:

a vše bezvadně funguje. A skutečně, pokud takový příkaz provedete a podíváte se na hlášení o stavu, uvidíte, že Git považuje soubor za přejmenovaný (renamed):

Výsledek je však stejný, jako byste provedli následující:

Git umí zjistit, že jde o přejmenování, a proto nehraje roli, zda přejmenujete soubor tímto způsobem, nebo pomocí příkazu mv. Jediným skutečným rozdílem je, že git mv je jediný příkaz místo tří — jde o funkci pro zjednodušení práce. Důležitější je, že pro přejmenování souboru můžete použít jakýkoli oblíbený nástroj a později, před zapsáním revize, provést příkaz add/rm.