Cíl
Naučit se pracovat s verzovacím systémem Git. Jedná se o velmi rozšířený verzovací systém používaný mnoha open source projekty. Konkrétně nás bude zajímat:
- využití Gitu pro distribuovaný vývojový model, který je praktikován mnoha open source projekty,
- efektivní prohledávání historie projektu, které je užitečné například při rozhodování, jak správně vyřešit určitý konflikt a
- řešení konfliktů.
Úvod
Git je poměrně univerzální nástroj pro správu a synchronizaci dat v souborech. Kromě verzování softwaru ho lidé používají k mnoha dalším činnostem (viz Git User’s Survey 2012, otázka 8). Jedna z často zmiňovaných nevýhod Gitu je, že oproti jiným verzovacím systémům je těžší se ho naučit a používat. Možným důvodem je to, že git nabízí větší funkcionalitu než většina ostatních systémů, která se ale využije jen ve speciálních případech – například jen u extrémně velkých projektů jako Linuxové jádro. Ať už to tak je, nebo ne, faktem je, že Git se neustále vyvíjí a mnoho úsilí je věnováno právě zlepšení uživatelské přivětivosti.
Pro pochopení Gitu je důležité mít základní představu o tom, jak Git pracuje s větvemi, což bylo popsáno v přednášce na slidech “Working on branches“ a “Working with remotes“.
V tomto cvičení budeme opět pracovat s projektem Midnight commander z 1. cvičení. Pokud s gitem začínáte, doporučuji v průběhu jednotlivých kroků kontrolovat stav repozitáře pomocí grafických nástrojů:
Příkaz
gitk
zobrazuje graficky historii a dovoluje její interaktivní procházení. Přijímá stejné volby jakogit log
, takže v příkazech níže ho můžete použít i pro „vizualizaci“ výstupugit log
.Příkaz
git gui
je grafický nástroj částečně nahrazující příkazygit status
agit commit
. Pomocí menu je možné provádět i další operace jako např. vytváření větví nebo pracovat se vzdálenými repozitáři.Dále existuje ještě spousta dalších nástrojů. Já osobně používám kromě výše zmíněných příkazů ještě
tig
aqgit
.
Dále se vám určitě bude hodit dokumentace:
git help <příkaz>
git <příkaz> --help
Postup
Základní nastavení. Aby vaše commity obsahovaly správné údaje o vás, nastavte si jméno a email:
git config --global user.name "Your Name Comes Here" git config --global user.email you@yourdomain.example.com
Předpokládáme, že máte zdrojové kódy midnight commanderu někde na disku, takže se přesuňte do adresáře s nimi.
cd ~/mc
Lokální větve
Možná budete chtít zachovat vaší práci z prvního cvičení. Uložíme jí do nové větve cviceni1. Nejprve se ale podíváme v jakém stavu máme zdrojové kódy:
git status
Dostaneme něco jako:
# On branch master # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: lib/keybind.h # modified: src/filemanager/midnight.c # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # misc/ext.d/doc.sh # ... no changes added to commit (use "git add" and/or "git commit -a")
Vidíme, že pracujeme na větvi master a vzhledem k verzi uložené v repozitáři máme několik změněných souborů.
Vytvoříme větev cviceni1 a přepneme se na ni:
git checkout -b cviceni1
Nyní už by měl
git status
ukazovat že pracujeme s větví cviceni1.Provedeme commit, t.j. uložíme všechny naše změny do lokálního repozitáře:
git commit -a -m 'Zmeny z prvniho cviceni'
Parametrem
-a
říkáme, že „commitujeme“ vše (all) a-m
udává komentář ke commitu (message). Kdybychom-m
vynechali, git spustí editor a nechá nás napsat zprávu v něm.Poznámka: Pokud vám nevyhovuje výchozí editor (většinou
vi
), nastavte si, že chcete používat jiný editor (např.nano
):git config --global core.editor nano
Nyní se přepneme zpět na větev master:
git checkout master
V adresáři se vám teď objeví verze bez vašich úprav z 1. cvičení.
Seznam větví v našem repozitáři zjistíme příkazem
git branch
Aktuální větev je označena hvězdičkou
*
.
Práce s více vzdálenými repozitáři
Doposud jsme pracovali pouze s jedním vzdáleným repozitářem. Mezi velké výhody gitu (a ostatních distribuovaných verzovacích systémů) patří schopnost pracovat s více vzdálenými repozitáři.
Které vzdálené repozitáře máme nakonfigurované zjistíme pomocí
git remote -v
Vidíme, že máme nakonfigurovaný repozitář s názvem origin a jeho URL.
Pokud chceme nějaký vzdálený repozitář používat často, vyplatí se ho pojmenovat krátkým jménem (v příkladu níže osp), abychom nemuseli pořád psát dlouhé URL:
git remote add osp ssh://git@rtime.felk.cvut.cz/osp/mc
V tomto repozitáři je uloženo zadání dnešní úlohy. Abyste se k němu dostali, musí server znát váš veřejný SSH klíč. Jak toho docílit najdete na samostatné stránce. Přístup k repozitářům na serveru rtime budete potřebovat i v písemce. Proto vám důrazně doporučujeme zprovoznit přístup už na tomto cvičení, abyste při písemce neztráceli čas.
Nyní můžeme stáhnout obsah právě přidaného repozitáře:
git fetch osp
V případě úspěchu bude výstup vypadat následovně:
remote: Counting objects: 34, done. remote: Compressing objects: 100% (17/17), done. remote: Total 20 (delta 17), reused 6 (delta 3) Unpacking objects: 100% (20/20), done. From ssh://rtime.felk.cvut.cz/osp/mc * [new branch] master -> osp/master * [new branch] only-directories -> osp/only-directories * [new branch] only-directories-old -> osp/only-directories-old
Příkaz nám vypíše, že v repozitáři byly tři nové větve. Všechny větve ze vzdálených repozitářů vypíšeme příkazem
git branch -r
Zjednodušeně řečeno, jediný rozdíl mezi lokální a vzdálenou větví je v tom, že jméno vzdálené větve má prefix
<remote>/
(v našem případěorigin/
neboosp/
).Nyní nás zajímá co je ve větvích, které jsme právě stáhli:
git log osp/only-directories ^master git log master..osp/only-directories
Tyto dva příkazy jsou ekvivalentní a vypisují commity, které jsou ve větvi osp/only-directories a zároveň nejsou (^) ve větvi master.
Chcete-li vidět i změny v kódu (patch) použijte jeden z následujících příkazů:
git log -p osp/only-directories ^master gitk osp/only-directories ^master
Výše uvedené příkazy zobrazují změny provedené jednotlivými commity. Pokud nás zajímá celková změna bez rozdělení na jednotlivé committy, pomůže nám příkaz
git diff
:git diff master..osp/only-directories git diff master osp/only-directories
První příkaz zobrazí změny, které obsahuje verze only-directories a nejsou ve větvi master. Druhý příkaz zobrazí kompletní rozdíl, tj. i změny, které jsou ve větvi master a ne v only-directories.
Podobně můžeme postupovat i s původním repozitářem. Jméno origin je výchozí a proto ho nemusíme zadávat:
git fetch
Co přibylo ve větvi master od prvního cvičení zjistíme příkazem:
git log master..origin/master
Slučování větví (merge)
Operace slučující dvě a více větví do jedné se nazývá merge. V Gitu můžou při slučování nastat tři situace:
- Already up-to-date je situace, kdy už je větev, kterou chceme sloučit, dosažitelná z aktuální větve (už byla sloučena v minulosti). Při sloučení nedojde k žádné změně.
- Fast-forward je opak předchozí situace, tj. aktuální větev je dosažitelná ze slučované větve. To odpovídá situaci, kdy aktualizujeme na novější verzi. Při sloučení je větev (tj. ukazatel na poslední commit) posunuta na novější verzi.
- True merge. Pokud nenastane jedna z předchozích situací, jedná se o skutečné sloučení. Výsledek je nějaká kombinace obou verzí.
Pokud došlo v případě True merge ke změně stejného místa v kódu v obou větvích, dojde k tzv. konfliktu, který musí být vyřešen ručně.
Zkuste provést sloučení své větve master s origin/master
git merge origin/master
Výsledkem bude Fast forward a uvidíme jaké soubory byly změněny:
git merge origin/master Updating 0ebd30c..a99dc51 Fast forward configure.ac | 1 + contrib/Makefile.am | 9 +- ...
Toto je velmi častá operace a proto lze operace
fetch
amerge
nahradit jedním příkazemgit pull
Vždy, když člověk pracuje na nějaké netriviální změně, je užitečné, založit si na to samostatnou větev. Dnešním úkolem bude sloučit větev osp/only-directories s větví master a protože to není triviální založte si na to novou větev:
git checkout -b homework
Pokud provedete sloučení
git merge osp/only-directories
Výsledek bude vypadat pravděpodobně takto:
Auto-merging doc/man/mc.1.in Auto-merging src/filemanager/find.c CONFLICT (content): Merge conflict in src/filemanager/find.c Automatic merge failed; fix conflicts and then commit the result.
Vidíme, že se automaticky povedlo sloučit změny v souboru
doc/mc.1.in
, ale při slučování změn vesrc/find.c
už takové štěstí nemáme a výsledkem je konflikt.
Řešení konfliktů
Konflikt lze řešit několika způsoby (viz také git merge --help
):
Vzdáme to a vrátíme se k verzi před slučováním
git merge --abort
Konflikt vyřešíme a oznámíme to gitu příkazy
git add
agit commit
(jak nám git napovídá v hláškách)
V průběhu řešení konfliktu je užitečné používat příkaz git status
,
abychom zjistili, co je ještě potřeba vyřešit. V našem případě vypadá
výstup zhruba takto:
On branch homework
You have unmerged paths.
(fix conflicts and run "git commit")
Changes to be committed:
modified: doc/man/mc.1.in
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: src/filemanager/find.c
Konflikt lze řešit následujícími způsoby:
- Soubor s konfliktem otevřeme v textovém editoru a najdeme sekvence
<<<<<<<<
,=========
a>>>>>>>>
, kterými jsou označené jednotlivé konfliktní oblasti. Tato místa musíme opravit tak, aby kód dával smysl a poté zmíněné sekvence znaků smažeme. Použijeme příkaz
git mergetool
, který spouští grafický nástroj (např. kdiff3 nebomeld
), který nám se slučováním pomůže.kdiff3
vedle sebe zobrazuje 3 různé verze projektu: poslední společnou verzi (base), verzi z větve před slučováním (local) a verzi ze slučované větve (remote), tj. té uvedené jako parametr v příkazugit merge
.Ve spodní části obrazovky je pak vidět výsledek slučování, který můžeme měnit buď přímou editací a nebo výběrem jednotlivých verzí pomocí tlačítek A, B a C. V tomto okně je potřeba zbavit se všech řádek, které mají v levém sloupci
?
– tj. konfliktů.
Při řešení konfliktů nám může pomoct i příkaz gitk --merge
, který
zobrazí pouze commity, které modifikovaly konfliktní soubory.
Jednoduše tam můžeme zjistit, které změny konflikt způsobily.
Git obsahuje poměrně jednoduchý algoritmus (v porovnání s jinými verzovacími systémy) pro slučování různých verzí souborů. Některým studentům se to nelíbí a stěžují si. Přečtěte si názor Linuse Torvaldse, proč tomu tak je.
Repozitář na GitHubu
K tomu, aby výsledky vaší práce na open source projektech byly snadno dostupné pro ostatní je užitečné založit si vlastní repozitář, odkud si budou moct ostatní vaše změny stáhnout.
Zaregistrujte se na GitHubu. V závislosti na tom, jakým protokolem chcete k repozitářům na GitHubu přistupovat si nastavte buď password caching (pro HTTP) nebo SSH klíče (pro SSH).
Vytvoření repozitáře na GitHubu. Můžete založit buď nový projekt nebo udělat tzv. „fork“ existujícího projektu.
Pro účely tohoto cvičení si založte fork Midnight commanderu. Do takto vytvořeného repozitáře pak nahrajete vypracovaný úkol z dnešního cvičení.
Do svého repozitáře na GitHubu nahrajete větev z lokálního repozitáře některým z těchto způsobů:
git remote add github https://github.com/<mujlogin>/mc.git git push github HEAD:homework
nebo
git push https://github.com/<mujlogin>/mc.git homework
nebo
git push ssh://git@github.com/<mujlogin>/mc.git homework
Zadání
Proveďte sloučení větve ssh://git@rtime.felk.cvut.cz/osp/mc
only-directories
s aktuální vývojovou větví Midnight Commanderu
(origin/master
). Výsledek musí jít zkompilovat a musí obsahovat
funkcionalitu přidanou do větve only-directories
. Výsledek uložte do
vámi vytvořeného repozitáře (forku) na GitHubu do větve
homework
.