Hlavní navigace

GIT: naše první vydání

Karel Žák

Tak a je to konečně tady. Přišel ten Velký Den, kdy je načase udělat první oficiální release (vydání). Co to znamená pro váš repositář v GITu? Jednoduše řečeno „zapíchneme“ do repositáře dostatečně velkou značku, se kterou už nikdy nikdo nepohne. Ta bude navždy označovat místo, kde je verze 0.0.1.

Onu značku uděláme tak, že vytvoříme nový tag a podepíšeme ho pomocí GPG:

$ git tag -s -m "this is the best release" v0.0.1

tag v0.0.1 si můžeme snadno ověřit:

$ git tag -v v0.0.1
object 4ba6758ad5043242933a0c005b416d70fb5e9a1e
type commit
tag v0.0.1
tagger Karel Zak <kzak@....> 1205885297 +0100

this is the best release
gpg: Signature made Wed 19 Mar 2008 01:08:17 AM CET using DSA key ID DC06D885
gpg: Good signature from "Karel Zak <kzak@....>"

SHA-1 každého commitu je počítána z jeho obsahu, a tím je i odkaz na tree (snapshot repositáře v daném čase) a rodiče (předchozí stav). A jak již víme, vše až na úroveň dat je adresováno pomocí SHA-1 počítaného z obsahu. Tedy platí, že každá zpětná změna v repositáři změní i SHA-1 všech následujících commitů. Proto k ověření stavu celého libovolně velkého repositáře stačí porovnat jedno jediné SHA-1. Podobně stačí podepsat jedno jediné SHA-1.

Ale co když jsem udělal nějaký bug a chci tag smazat a udělat znova? Pokud nikdo nemá kopii vašeho repositáře a vše je jen vaše soukromá věc, není problém. Pokud ale již byla věc zveřejněna, tak máte velký problém. GIT nikdy sám nemaže tagy. Pokud si někdo vaše změny aplikuje na svůj repositář (např. git pull), GIT nezmění již existující tag.

Důvod je prostý – bezpečnost. GIT neimplementuje orwellovské „Ministry of Truth“, takže historii za něčími zády nikdy nemění. Každá podobná změna je viditelná.

Nevědět o existenci větví v GITu je nepřípustné ignoranství. Větvení (branchování) není v GITu bonus navíc, naopak, je to základní vlastnost.

K vytvoření větve vedou dvě cesty:

$ git checkout -b <branchname>

a nebo:

$ git branch <branchname>

oba příkazy můžete doplnit o tzv. startpoint – tedy místo, od kterého větev začíná. Většinou to však není nutné a GIT sám použije HEAD (poslední commit aktuálního větve).

Základní rozdíl mezi výše uvedenými příkazy je, že git-checkout přepne i pracovní adresář do vybrané větve, zatímco git-branch ne (a tedy stále pracujete s původní větví). To je důvodem, proč většina uživatelů dává přednost příkazu git-checkout.

Pokud ztrácíte jistou, která větev je aktuální, tak:

$ git branch

vypíše standardní větve a v seznamu označí právě používanou.

Pokud pracujete na repositáři, který je klonem jiného (cizího) repositáře a pravidelně si stahujete změny (např. git-pull) z originálního zdroje, je vhodné nepracovat v „master“. Branch master je standardní „tracking“ větev a aplikují se zde změny z originálního repositáře (pochopitelně záleží na vašem nastavení a používaných příkazech). Souběh vašich změn a změn z originálního repositáři může vést ke konfliktům.

Je tedy lepší pro svou práci používat nějakou lokální větev. Často se těmto větvím říká „topic“ větve.

Dobrá, máme projekt na kterém pracuje více lidí. My máme kopii (klon) repositáře s jeho „master“ větví. Implementujeme nějakou novou vlastnost, a aby nás nic nerušilo, používáme svůj vlastní větev. Tedy:

$ git clone git://project
$ cd project
$ git checkout -b topic
$ git branch
* topic
master

$ $EDITOR file.c
$ git commit -a -s -m "cool new feature"
.
.
.

mezi tím okolní svět nespí, ale aktivně provádí změny v původním repositáři. Nás pochopitelně tyto změny zajímají. Tedy pravidelně voláme:

$ git pull

což vede k tomu, že se mění obsah větve „master“ a naše lokální topic větev zastarává. To není nutně problém, ale jednou přijde doba, kdy chcete své změny poslat ostatním (případně jste maintainer a chcete změny aplikovat do „master“ větve), a pak je vhodné vaši větev „refreshnout“ tak, aby vaše změny bylo možné aplikovat na aktuální stav v hlavním repositáři. Řešením je rebase:

$ git rebase <upstream>

kde <upstream> je branch, který chcete použít jako zdroj, v našem případě „master“:

$ git rebase master

v tomto případě vezme GIT jednoduše patche z „master“ které nejsou v našem „topic“ a aplikuje je před naše změny. A následně se pokusí na takto refreshnutou větev aplikovat naše patche s „topic“.

Pomůžeme si obrázkem z man stránky git-rebase, stav před:

                     A---B---C topic
                    /
               D---E---F---G master

stav po rebase:

                             A´--B´--C´ topic
                            /
               D---E---F---G master

Pochopitelně může dojít ke konfliktům, pokud se modifikuje v „master“ to samé jako v „topic“. Proto je vhodné provádět při dlouhodobější práci v „topic“ rebase častěji a řešit tak jen menší konflikty.

Takto občerstvené patche je možné následně odeslat ostatním a nebo je aplikovat do jiné větve apod. Pokud chcete překopírovat větší množství patchů do jiné větve, lze použít příkaz:

$ git checkout -f master
$ git pull . topic

aplikuje patche z „topic“ do větve „master“. Pokud jste před tím neprovedli rebase, může opět dojít ke konfliktu který musíte vyřešit (tedy editor, commit, ..apod).

Pokud chcete aplikovat jen jeden patch, a to doslova bez ohledu na to, jak hluboko a kde je zakopán, použijte příkaz:

$ git cherry-pick <SHA-1>

kde SHA-1 je checksum commitu, který bude aplikován do aktuálního repositáře.

Větve lze pochopitelně používat na mnoho dalších činností, ale již ponechám případným zájemcům na jejich studiu. Podobě jako další možnosti, které GIT vývojářům dává…

Další informace

Presentace Git
(zdrojové kódy v LaTeX)

Našli jste v článku chybu?

27. 5. 2008 10:55

gapon (neregistrovaný)
Ja myslim, ze rebase slouzi k tomu, kdyz ma clovek svou sadu patchu, kterou mu bud nechteji autori programu prijmout zpet nebo ji proste nechce zverejnovat - pak:
- mam zdrojaky programu (branch main), na to hodim ty svoje patche (branch topic)
- pullnu main, tudiz moje topic branch uz neni "nad" aktualnima zdrojakama programu, ale nekde uvnitr (pro vizualizaci lze pouzit #gitk --all) - mam ted dve moznosti - merge main nebo rebase - protoze ale chci ty svoje patche stale "nad&quo…

26. 5. 2008 23:25

Jazz (neregistrovaný)
Abych přiznal barvu, tak na tuto poznámku jsem narazil někde mezi porcelain/core dokumentací a on-line příspěvky na internetu. Myslím, že to dokonce řekl sám Linus, ale musel bych ten materiál dohledat.

Samotného mě to dost zarazilo.

Vzhledem ktomu, že jsem to doteď rebase nepotřeboval použít,
tím pádem jsem si to ani hlouběji nestudoval.

Každopádně bych rád věděl jak to je ^_^






Podnikatel.cz: Změny v cestovních náhradách 2017

Změny v cestovních náhradách 2017

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...

Podnikatel.cz: K EET. Štamgast už peníze na stole nenechá

K EET. Štamgast už peníze na stole nenechá

120na80.cz: 5 nejčastějších mýtů o kondomech

5 nejčastějších mýtů o kondomech

Vitalia.cz: Taky věříte na pravidlo 5 sekund?

Taky věříte na pravidlo 5 sekund?

Podnikatel.cz: Podnikatelům dorazí varování od BSA

Podnikatelům dorazí varování od BSA

Podnikatel.cz: Chaos u EET pokračuje. Jsou tu další návrhy

Chaos u EET pokračuje. Jsou tu další návrhy

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

Měšec.cz: Air Bank zruší TOP3 garanci a zdražuje kurzy

Air Bank zruší TOP3 garanci a zdražuje kurzy

Měšec.cz: Jak levně odeslat balík přímo z domu?

Jak levně odeslat balík přímo z domu?

120na80.cz: Co všechno ovlivňuje ženskou plodnost?

Co všechno ovlivňuje ženskou plodnost?

Lupa.cz: Insolvenční řízení kvůli cookies? Vítejte v ČR

Insolvenční řízení kvůli cookies? Vítejte v ČR

Vitalia.cz: Proč vás každý zubař posílá na dentální hygienu

Proč vás každý zubař posílá na dentální hygienu

Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

Lupa.cz: Propustili je z Avastu, už po nich sahá ESET

Propustili je z Avastu, už po nich sahá ESET

Vitalia.cz: Pamlsková vyhláška bude platit jen na základkách

Pamlsková vyhláška bude platit jen na základkách

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

Měšec.cz: mBank cenzuruje, zrušila mFórum

mBank cenzuruje, zrušila mFórum

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky