DVCS a Git

DVCS a Git

• Webová interaktivní prezentace
• "?" zobrazí krátkou nápovědu
• Tisk jako obvykle
• Pro pokračování stiskněte mezerník
• ondrej.zara@firma.seznam.cz

Moc-li toho bude?

1. DVCS – Filozofie a termitologie
2. Typické scénáře
3. Bonusy

Distribuované verzovací systémy

• Distributed Version Control Systems
• Git, Mercurial, Bazaar
• Protiklad k tradičnímu, centrálně řízenému modelu
• V řadě situací těžko hledat paralely

Základní koncepty a termíny I.

(se zvláštním přihlédnutím ke Gitu)

• Repozitář je projekt včetně celé své historie (rodokmenu)
  • SVN: jednosměrný seznam; Git: acyklický orientovaný graf
• Projekt v SVN, Projekt v Gitu
• Commit je sada změn popisující konkretní stav projektu; má vždy jednoznačný název
  • SVN: revision number; Git: sha1

Základní koncepty a termíny II.

• HEAD označuje aktuální obsah adresáře: konkrétní commit + nad ním provedené změny
  • SVN: working copy
• Branch je jen a pouze pojmenování commitu (které s ním cestuje); implicitní branch je master
  • V SVN je branch něco úplně jiného; oddělená kopie repozitáře, která má se zbytkem pramálo společného
• Checkout značí posunutí HEAD na zadaný commit/branch
• Ukázka checkoutu, Ukázka commitu s posunem branche

Spojení oddělených větví vývoje

• Říkáme, že dvě (různé) posloupnosti commitů se společným rodičem divergovaly
• Často je třeba tyto posloupnosti spojit; při tom může vždy nastat konflikt
• V Gitu existují dva základní algoritmy spojování divergovaných větví:
  1. Merge: v aktuální větvi (automaticky) vytvořit nový commit, obsahující změny z druhé větve (ukázka)
  2. Rebase: nahrát commity z druhé větve před commity z aktuální (ukázka)

Spolupráce mezi různými repozitáři I

• Git používá koncept remote pro označení jiného repozitáře
• git remote add mujAlias git@github.com:seznam/JAK.git
• Na mujAlias se lze odkázat při následných operacích

Spolupráce mezi různými repozitáři II

git clone http://github.com/seznam/JAK.git

• vytvoří nový repozitář
• naplní ho daty ze vzdáleného repozitáře
• vytvoří remote zvaný origin, odkazující se na zadané URL

Spolupráce mezi různými repozitáři III

git push [remote] [branch]

• Nahraje aktuální větev do remote
• Ukázka
• Je povoleno pouze fast-forward, tj. poslední commit v remote musí být v historii aktuální větve
• Nemůžou nastat konflikty, není to merge

Spolupráce mezi různými repozitáři IV

git pull [--rebase] [remote] [branch]

• Pokusí se nahrát obsah remote do aktuální větve
• git pull = git fetch + git merge
• Aktuální a remote větev musí mít společného rodiče
• Pokud nelze fast-forward, automaticky se udělá merge
• --rebase říká, že se má namísto merge použít rebase
• Ukázka

Merge / Rebase?

• Pro různé případy různé techniky
• Merge zachovává strom historie, ale automaticky vyrábí merge commit
• Rebase "zplošťuje" historii a mění ID commitů
• Nepoužívat rebase větve, která byla uveřejněna (ostatním by se pod rukou změnily commity)

Typické scénáře

1. Základní workflow
2. Práce na projektu v Seznamu
3. Sdílení na Githubu
4. Co se to ku*va zase pos*alo @#$%^* !!!

Základní workflow

git init mujProjekt
cd mujProjekt

touch index.html
git add index.html
git commit -m "Prvni soubor"   # vsechny pridane

# work work

git commit -am "Dalsi upravy"  # vsechny zmenene

Práce na projektu v Seznamu I

• Centrální repozitář na CML
• Ve větvi master se nevyvíjí; obsahuje stabilní stav aplikace (balení)
• Vývojář si vytváří svou větev či své feature branche
• Ukázka

Práce na projektu v Seznamu II

Inicializace, práce

git clone git@cml.kancelar.seznam.cz:projekt
cd projekt

git branch vyvojar
git checkout vyvojar
git commit
git commit
...

Práce na projektu v Seznamu II

Aktualizace projektu

git checkout master
git pull  # mel by byt fast-forward; proc?

git checkout vyvojar
git rebase master

Práce na projektu v Seznamu III

Nahrání do repozitáře

# nejprve musime mit aktualni master, neb push povoluje jen fast-forward
git checkout master
git pull
git checkout vyvojar
git rebase master

git checkout master
git merge vyvojar  # nebo rebase; je to stejne fast-forward
git push

Sdílení na Githubu I

• Na Githubu je hlavní repozitář (seznam/JAK)
• Každý uživatel má na Githubu vlastní fork (vyvojar/JAK)
• Cílem je dostat na seznam/JAK svoje featury
• Pracuje se ve vlastní větvi; po nahrání na Github se pošle pull request
• Vlastní master by měl zůstat 1:1 s masterem seznam/JAK
• Ukázka

Sdílení na Githubu II

git clone git@github.com:vyvojar/JAK.git  # klon forku, tj. klon klonu :-)

# promitnout aktualni stav oficialniho JAKu k sobe domu
git pull https://github.com/seznam/JAK.git

git branch novy_widget
git checkout novy_widget
...
git commit

git push origin novy_widget  # pote na Githubu kliknout na "pull request"

Pomoc!

• git status = aktuální větev, výčet změněných souborů, obsah stage
• git log --all --oneline --graph = kompletní historie s grafem v kompaktní formě
• git branch -a = výčet existujících větví
• git remote -v = výčet remote aliasů

Bonus – stage

• Git commituje jen explicitně označené soubory
  • SVN všechny změněné
• Staging area je soupis souborů k commitu
• git add soubor přidá do stage
• git reset soubor odebere ze stage
• git commit -a commit všech změněných

Bonus – stash

• Rozdělám práci a před commitem si všimnu, že jsem ve špatné větvi
• Checkout nelze udělat, pokud není commitnuto

• git stash      # ulozi necommitle zmeny bokem
  git checkout spravna_vetev
  git stash pop  # aplikuje drive ulozene zmeny
  

Bonus – detached head

• Potřebuji se vrátit o kus zpět a provést změny, ale nechci přijít o ty současné
• git checkout HEAD~3 – jdu o tři commity zpět
• Git v tuto chvíli hlásí "detached head", tj. HEAD neukazuje na list grafu (nejsem v žádné větvi)
• Pokud nyní udělám commit, vytvořil jsem novou větev, kterou bych měl pojmenovat
• Ukázka

Bonus – klienti pro Windows

• Git Shell
• Git Extensions
• TortoiseGit
• Github for Windows
• Putty + Samba + CLI

Prostor pro otázky