git
remote add
. git clone
to udělá automaticky.Semestrální práce budete v tomto předmětu odevzdávat prostřednictvím gitu. Protože předpokládáme, že ne všichni z vás git znají, přinášíme vám k němu malý úvod.
Pokud používáte nějakou distribuci Linuxu, git nainstalujete klasicky přes
balíčkovací systém. Pro ostatní systémy je možné ho stáhnout přímo z
oficiálních stránek. Základní grafické nástroje
git gui
a gitk
jsou zahrnuty, v některých distribucích jsou v samostatných
balíčcích (v Debianu git-gui
a gitk
).
git gui
a gitk
jsou součástí oficiálních balíčků.
git help
je váš přítel.
Git patří mezi verzovací systémy. To znamená, že vám umožňuje udržovat si verze něčeho – my budeme mluvit o programu, ale může jít o cokoliv, třeba několik zdrojových kódů, jeden soubor s poznámkami z analýzy, nebo klidně celou bakalářku tvořenou programy, daty, textem práce, obrázky, poznámkami, …
Mezi zásadní výhody gitu patří jeho flexibilita, takže s gitem dokážete v podstatě cokoliv – samozřejmě ale komplikované problémy mívají komplikované řešení. My zůstaneme u těch jednoduchých, takže by komplexita měla zůstat v únosné míře. Tento úvod je zjednodušený, a místy v zájmu srozumitelnosti trochu nepřesný, ovšem na základní použití by měl posloužit velmi dobře.
Pojmem, kterému se v povídání o gitu nemůžeme vyhnout, je repozitář. V
prvním přiblížení si ho představíme jako složku obsahující náš program. Tato
složka může obsahovat libovolné množství souborů a složek (které mohou obsahovat
další soubory a složky, a tak dále). Repozitář se nějak jmenuje, třeba
semestralka.git
. Jak to se jmény bývá, je vhodné, aby jméno repozitáře
přímočaře souviselo s jeho obsahem, ale technicky to nutné není.
Verzí programu budeme označovat přesný stav složky (repozitáře). To zejména znamená, které soubory v ní jsou a jaký přesně mají obsah (ale také třeba jaká mají práva). Dvě verze se od sebe mohou lišit třeba opravou středníku v jednom souboru .cpp, přidáním několika testů do souborů s testy, odstraněním zastaralé (deprecated) funkce, … Opět, technicky může verze vypadat jakkoliv. Prakticky je vhodné, aby každá verze programu byla zkompilovatelná a přidávala či ubírala nějakou dobře definovanou část funkcionality programu. O verzích budeme později mluvit jako o commitech.
Repozitář můžeme založit přímo na gitlabu intuitivně tlačítkem “New project”. Potom už si jen musíme nový repozitář naklonovat na svůj počítač (viz dále). Gitlab nám dokonce dá po založení návod, jak to udělat.
Protože git je distribuovaný verzovací systém (to znamená, že každý klon je
plnohodnotným repozitářem), můžeme si repozitář vytvořit klidně i jenom lokálně
pomocí příkazu git init
. Pak ale samozřejmě nemáme jak změny
publikovat1).
K vlastní práci v repozitáři si musíme pořídit jeho klon. Existující
repozitář si na svůj stroj naklonujeme pomocí příkazu git clone
, tedy např.
git clone git@gitlab.fel.cvut.cz:uzivatel/semestralka.git
. Ale počkat … jak se autentizovat?
Pro přístup do repozitářů gitlabu si musíte vytvořit SSH klíč (pokud ještě nemáte) a přidat
jeho veřejnou část do Gitlabu na svůj profil. Může to znít složitě, ale ve skutečnosti je to
jen pár příkazů a na stránkách gitlabu je podrobný návod, jak na to.
Po naklonování repozitáře na disku uvidíme nejnovější verzi programu.
O repozitáři jsme v prvním přiblížení mluvili jako o složce. Je to ale trochu
víc – kromě samotné složky, resp. jejího obsahu, je repozitář tvořený také
určitými nastaveními, a zejména seznamem všech verzí programu.2) Právě seznam verzí je důvod,
proč se budeme chtít seznámit s příkazy git pull
a git push
. Pokud
zavoláme git pull
, překopírují se nám na disk všechny verze, které existují
na serveru3), a neexistují u nás.
Naopak, zavolání git push
způsobí, že se všechny verze, které existují u nás
a neexistují na serveru, překopírují na server. Zde předpokládáme, že s
repozitářem pracujete jako jediní a pouze na jednom stroji. Pokud např. na svém
stolním počítači zavoláte git pull
, vyrobíte nové verze, zavoláte git
push
a následně na svém notebooku zavoláte git pull
, bude vše stále
fungovat. Pokud ale vyrobíte nové verze jak na stolním počítači, tak na
notebooku, příkazy se začnou chovat zvláštně a budou si stěžovat. Můžete zkusit
git pull --rebase
, v horším případě budete muset googlit git merge
(nebo se zeptat na fóru).
Už jsme si řekli, jak dostat nové verze ze serveru k nám a naopak, ale ještě
jsme nemluvili o tom, jak nové verze vyrobit. To proto, že vyrábění nových verzí
je maličko trikové. Git odlišuje tři věci: zaverzované (commitnuté) podoby
souborů, podoby připravené k zaverzování (ke commitu) a soubory (resp. podoby
souborů), o kterých vlastně neví. Pokud v repozitáři změníte soubor nebo
vytvoříte nový, git to ignoruje. Je potřeba mu říct, aby si nového souboru,
resp. změny obsahu v souboru všiml. K tomu slouží příkaz git add
. Předávají
se mu všechny soubory, u kterých si má git všimnout změny (přičemž změnou může
být i jejich vytvoření). Voláte tedy např. git add reversi.h reversi.cpp
.
Tím se změny v daných souborech připraví ke commitu. (Obvykle se připraveno ke
commitu označuje jako staged.) K vytvoření nového commitu pak slouží
příkaz git commit
. Do vytvářeného commitu přidá git všechno, co je k němu
připraveno (tedy na co bylo dříve zavoláno git add
). Součástí vytvářeného
commitu je také jeho popis, resp. zpráva o změně (commit message). Po zavolání
git commit
se vám otevře textový editor, kam tuto zprávu zadáte, a teprve
uložením a uzavřením editoru se vytváření nového commitu dokončí. Pokud byste
zadali prázdnou zprávu, vytváření nového commitu se přeruší. Pozor si dejte
zejména na posloupnost editace souboru, git add soubor, další editace, git
commit, kdy se do nového commitu promítnou pouze změny z první editace.
Do svého repertoáru příkazů pro git byste určitě měli zařadit git status
.
Tento příkaz vám, jak název napovídá, vypíše stav repozitáře. Přesněji řečeno,
vypíše vám (na anglicky mluvícím systému):
On branch master
– ten směle ignorujte, byl by důležitý, kdybyste pracovali s větvemi,
git add
)
git add
nevolalo)
git add
)
Pokud by kterákoliv ze zmíněných sekcí neobsahovala žádný soubor, git ji vůbec nevypíše.
Commitování souborů z příkazové řádky může být někdy trochu nešikovné, obzvlášť,
pokud máme změn hodně, chceme commitnout jen některé nebo se chceme při psaní zprávy
dívat, co jsme udělali za změny, aby byl obsah zprávy hezky popisný.
V tom případě se může hodit utilitka git gui
, která nám zobrazí:
Grafické rozhraní sice vypadá jak z minulého tisíciletí, ale je velmi jednoduché a mocné. Utilita je součástí gitu (i když v některých linuxových distribucích je v samostatném balíčku git-gui).
Po kliknutí na jméno souboru se nám zobrazí změny v příslušném souboru, po
kliknutí na jeho ikonku se buď připraví ke commitu (jako po zavolání git
add
), nebo se naopak označí, jako že ho commitovat nechceme (pokud byl před
kliknutím v souborech ke commitu).
Když si svůj projekt zkompilujeme, vygeneruje se spoustu souborů, které se nám
začnou objevovat ve výpisu git status
. Ty ale nikdy verzovat nechceme.
Hodilo by se tedy gitu nějak říct, že má dané soubory ignorovat. Toho dosáhneme
tak, že vytvoříme soubor .gitignore
a do něj napíšeme seznam souborů (nebo patternů),
které ignorovat:
# ignoruj objektové soubory *.o # anebo rovnou celý adresář build build
Soubor .gitignore
se může vyskytovat i v jakékoliv podsložce – pak se ale
bude vztahovat jen na soubory (a adresáře) v ní.
Užitečným příkazem může být také git log
. Ten vypíše seznam commitů, pro
každý z nich vypíše kód commitu, autora, datum vytvoření a popis (commit
message). Pokud by vám vrtalo hlavou, kde se vzal kód commitu, je to SHA hash
kompletního obsahu repozitáře v daném commitu.
Opět můžeme využít standardní grafický nástroj gitk
(v Debianu samostatný balíček gitk).
Ani ten nás neoslní moderním designem, ale zato nás oslní svou praktičností.
K vidění je v něm:
Kontextové menu na na commitu v seznamu commitů opět umožňuje dělat kouzla, např. vytvářet značky (tagy).
V neposlední řadě se pak hodí příkaz git diff
. Ten vám ukáže odlišnosti. V
základním použití (tedy přímo git diff
) vám ukáže, jak se soubory na disku
liší od své podoby v nejnovějším commitu. Pozor, toto volání vám neukáže nově
přidané soubory. Spousta vývojářů běžně používá git diff --cached
, to
vám ukáže vše, co je připraveno ke commitu (tedy vše, co se přidá do nového
commitu, pokud zavoláte git commit
). V některých případech se vám může hodit
přidat k volání diffu --word-diff=color
, v takovém případě nebudou ve
výpisu zvýrazněné celé řádky, ale přímo ty jejich části, které se liší. A
zmíníme i git diff <kód commitu> <kód commitu>
, který vám ukáže odlišnosti
mezi commity identifikovanými svými kódy. K této identifikaci ještě dvě
poznámky:
HEAD
.
Říkali jsme, že každý commit reprezentuje určitou verzi projektu. Tím jsme
měli na mysli pracovní verzi. V určitou chvíli ale budeme se stavem našeho
projektu spokojení, prohlásíme aktuální verzi za konečnou (tedy, konečnou do
doby nalezení prvního bugu) a budeme ji chtít nějak pojmenovat – ať už se jedná
o nějaký open-source program (a chceme udělat release verze X.Y, tedy např.
v0.1
), nebo o semestrálku (chceme ji odevzdat, tedy např. odevzdani-1
).
Toho dosáhneme tak, že daný commit označíme tzv. tagem (česky štítkem). V
historii pak budeme mít jasně označené, který stav (commit) odpovídá které
release verzi.
Tag se dá vytvořit příkazem git tag
, např. git tag -a v0.1
, anebo z
kontextového menu v programu gitk
, při kliknutí na patřičný commit (viz
Zobrazení změn). Samotný git tag
pak vypíše seznam všech tagů.
Seznam všech tagů se nám taky zobrazí na gitlabu v záložce Repository → Tags. A jako bonus můžeme všude místo SHA hashe commitu psát název jeho tagu.
Pokud chcete Gitu porozumět trochu víc, doporučujeme již zmiňovanou knihu Pro Git, dostupnou online v češtině i v angličtině.
Vhod taky přijde tahák se základními příkazy a v neposlední řadě taky Visual cheatsheet.
Doplníme.
git
remote add
. git clone
to udělá automaticky..git
, která tato nastavení a verze obsahuje.