Working with git

Nastavení upstream

* Přidejte vazbu na centrální repozitář (upstream)

cd ~/[cílová_složka]
pokud nemáte svůj SSH klíč

git remote add upstream https://github.com/VECTOUN/pa165project.git
máte na GitHubu SSH klíč

git remote add upstream git@github.com:VECTOUN/pa165project.git

Jak stáhnout aktualizace kódu (z upstreamu)

git checkout master                     # přepnu na větev master
git fetch upstream                      # stáhnu aktualizaci
git merge --ff-only upstream/master     # aplikuji změny na svůj master
git push origin master                  # pokud chci, mohu si rovnou aktualizovat i svůj master na originu

Jak vytvořím novou pracovní větev

• Následující příkaz vytvoří novou pracovní větev z masteru (ten si nejdříve aktualizujte) a přepne vás na ni.

git checkout -b [jméno_větve] master

Přepínání mezi větvemi/verzemi a rozdělaná práce (stash)

• Pokud přepínáte mezi větvemi a máte rozdělanou (necommitnutou) práci, tak se změny v souborech přepočítávají na aktuální HEAD revizi dané větve.
• Při přepínání tak může dojít ke konfliktům (pokud dojde, přepnutí se nepovolí).
• Řešením je změny uchovat pomocí příkazu @git stash@ a až se chceme vrátit zpět, tak obnovit pomocí @git unstash@. ** Mezitím můžeme přepnout větev na jinou, provést nezbytnou práci a zase se vrátit zpět. ** Pozor na akce měnící původní větev (commit, rebase, merge), protože při následné aplikaci stashe může dojít ke konfliktu, který musíte ručně vyřešit.

Jak aktualizovat svou pracovní větev

• Před aktualizací commitněte všechnu rozdělanou práci nebo si rozpracované soubory schovejte ve stashi.
• Ideálním způsobem aktualizace pracovní větve je její přesunutí na HEAD masteru pomocí rebase.

git checkout [pracovní_větev]
git rebase master

• Pozor, tato akce mění historii. Pokud jste už větev sdíleli (origin, pull request), musíte při dalším pushi použít přepínač @--force@.

git push origin [pracovní_větev] --force

• Je výhodné provádět aktualizaci pravidelně, případné konflikty v souborech jsou menší.
• Provádějte zvláště před podáním pull requestu, aby šel snadno schválit a mergnout.

Jak vyřešit konflikty různých verzí zdroj. kódů

Pokud pracujete se stejnou částí kódů jako někdo jiný, dost často se stane, že se Vaše změny potkají. Když se do stabilní větvě začlení jedna, už bez konfliktu nejde začlenit druhá. Problém nastává v okamžiku, kdy jste zavolali @git rebase@ nebo @git merge@.

• Git na konzoli vypisuje, které soubory mergoval a kde je konflikt.
• Obsah konfliktního souboru může vypadat např. následovně

<<<<<<< HEAD
contact : email.support@github.com
=======

  please contact us at support@github.com

>>>>>>> iss53

• U všech souborů v konfliktu proveďte takové úpravy, aby byl soubor v pořádku a šel celý projekt kompilovat.
• Takto opravené soubory přidejte do changesetu

git add [cesta+název_souboru]

• Dokončete původní akci pomocí

git rebase --continue  # pro rebase
git commit             # pro merge

• Pokud to z nějakého důvodu potřebujete, můžete při výskytu konfliktu vrátit vše zpět pomocí

git rebase --abort    # pro rebase
git merge --abort     # pro merge

Jak smažu pracovní větev (po schválení pull requestu)

• Jestliže byla Vaše práce schválena a mergnuta na @master@, můžete pracovní větev smazat a začít pracovat na nové.

git push origin :[jméno_větve]    # smaže větev z originu
git checkout master               # pokud jste na mazané větvi, přepněte se jinam (např. master)
git branch -D [jméno_větve]       # force smaže vaši větev na disku