GIT — stále překážkou?

Nestačí mě překvapovat situace na projektech, kde se všichni snaží používat GIT, ale procentuálně je dost lidí, kteří tomu až nápadně nerozumí. Přiznejme si, pořád je to lepší než se potit například se starým SVN.

Marně však pořád přemýšlím s každým projektem, kde se jako firma potkáváme s dalšími vývojáři, že by stálo za to udělat nějaké seznamovací školení s GITem, proč je vlastně takový problém se ho naučit. Lidi se dost často bojí zeptat na nějaká zákoutí, přitom je to to nejlepší, co mohou v dané chvíli udělat.

A kde je vlastně ten zakopaný pes? Čím dál tím více si myslím že v nástrojích. To není samozřejmě problém jen GITu, s tímto se potkávám kdekoli se kliká. Člověk tedy kliká s úmyslem něčeho docílit a když se mu to povede, je rád že je rád. V tu chvíli mu však uniká, jak to celé vlastně funguje. Zastávám názor (a ten se mi, řekl bych, pořád potvrzuje), že je nejlepší začít příkazovým řádkem. Alespoň rada pro toho, kdo se s GITem opravdu chce naučit. V tom jsou pak k nezaplacení ta prostředí, kde si nemůžete nainstalovat co chcete. To vás nejvíce naučí.

Na začátek tedy moje doporučení je používat GIT z “černočerné tmy”. Většina lidí u toho potom zůstane, a kdo né, ví alespoň přesně co dělá. Přitom těch hlavních příkazů, které potřebujeme znát, je možná do deseti. Já se na některé rád ptám i na pohovorech (občas váhám, zda to není až pod úrovní kandidáta), avšak realita je taková, že tím dotyčného překvapím. GIT mám sám velice rád, pro verzování ve firmě vlastně nepoužíváme nic jiného, ať již je to github.com, kde máme například opensouce platformu OpenHub, nebo interně používáme https://bitbucket.org.

Aby to nebylo jen povzdichu, pojďme si ty nejdůležitější příkazy připomenout:

git clone git@github.com:OpenWiseSolutions/openhub-framework.git

vytvoření lokální GIT repository z “remote” repository

git status

výpis aktuálního stavu “workspace”

git pull

synchronizace změn z “remote” repository

git checkout -b [branch-name]

vytvoření nové větve (standardně feature/<task_name>) a přepnutí se do ní

git add .

přidání všech změn do stage (pouze tyto soubory se verzují)

git commit -m [text]

verzované soubory v stage se zapíší do lokální repository (nejsou sdíleny s ostatními)

git push

synchronizace lokální repository s “remote”

git push --force-with-lease origin [branch_name]

v rámci přepisování historie je nutné udělat “force” update, pro jistotu s bezpečnější varianta která se povede, pokud máte up-to-date větev

git pull --rebase origin develop

pro posunutí vlastní větve “nad” develop, jinými slovy synchronizace vlastní práce s develop branch

git rebase -i HEAD~3

interaktivní rebase neboli přepisování historie, ano přiznávám, trošku pokročilejší, nicméně s ohledem na GIT flow nezbytné.

git commit --amend --no-edit

pokud potřebujete k poslednímu commitu něco přidat

Jak vidno, těch příkazů není zase tolik. Samozřejmě, důležité je vědět i princip fungování. Každopádně si myslím, že zrovna tato znalost by měla být vlastní pro každého vývojáře, určitě pro ty, kteří to mají v životopise :).