Názory k článku
Třetí důvod proč zvolit Git : Decentralizace

Zdravím, nemáte někdo radu nebo doporučený postup, jak při komunitních projektech na GitHubu používat začleňování u forknutého repozitáře tak, aby se autorovi původního repozitáře ve Fork Queue nezobrazovaly mnou integrované jeho změny, které jsem přijal pomocí Fork Queue?

Reprodukční postup:
1) Forknu si repozitář projektu, který je veden jen ve větvi master a vydání jednotlivých verzí probíhá otagováním.
2) Provedu si ve svém forku změny.
3) V původním repozitáři mezitím pokračuje dál vývoj.
4) Tyto změny si pomocí Fork Queue průběžně integruju. Ve výsledku mám v jedné větvi změny mé i původního autora, tak aby reflektoval aktuální stav projektu.

Při tomto postupu to dopadne podobně, jako to bylo popisováno v minulém článku ala použití jako Subversion 2.0 (nekoordinovaná práce v master větvi). Původnímu autorovi se ve Fork Queue zobrazí jak moje změny tak i jeho, které jsem průběžně integroval a ještě vzniká ona nepěkná pavučina při zobrazení historie repozitáře grafem.

Zajímalo by mě tedy, jakým postupem (ať už sekvence příkazů nebo struktury větví) lze (nebo zda-li vůbec lze) dosáhnout toho, aby původní autor viděl ve Fork Queue na GitHubu jen mé změny, nikoliv integrace. Pokud ale někdo forkne můj forknutý repozitář a provede změny, které pomocí Fork Queue přijmu, tak aby je původní autor ve své Fork Queue u mě taky viděl.

Nevím, jestli úplně přesně rozumím, kdyžtak zkuste poslat i URL na nějaké repo, kde je to vidět.

Ale obecně, ideální je ty „patche“ dělat v nějaké zvláštní větvi, na kterou pak směřuje pull request. Mnoho projektů vyžaduje zvláštní branch pro každý patch.

Tzn. nenavrhovat, aby přebírali z vašeho master, ale z těch větví, kde je to izolovaně. Tyhle zvláštní větve je pak potřeba pravidelně _rebasovat_ oproti jejich master, takže váš patch je pořád „aktuální“ a maintainer nemá práci s mergem. Github by se sice mohl poprat i s merge commity, ale detaily nevím, stejně jako nevím, jestli dělá cherry-pick nebo merge při zpracování Fork Queue. Chtělo by to ty URL :)

Jde to vidět například u repozitáře dibi u jednoho z jeho forků. GitHub při zpracovávání Fork Queue dělá prý cherry-pick.

Myšlenku jsem z vašeho snad vysvětlení pochopil, horší to bude s realizací, protože v některých věcech stále tápu :)

Netuším například jak přesně vypadají příkazy, které se dějí na pozadí toho grafického klikátka Fork Queue na GitHubu nebo jak mu vnutit, aby přebíral z jiné větve než master. Mohl bych pro jistotu poprosit ještě o případnou kratičkou ukázku sekvencí příkazů tohoto postupu, který jste popsal?

S URLs je to už lepší, už se mi rozsvítilo :) Jde tedy o ty commity, kde se liší autor a commiter, např. http://github.com/…d918825e3523 vs http://github.com/…5d6c67ac51f3

Tím pádem paranoiq aplikoval na ten svůj fork commity od dg přes Fork Queue. A protože tím dělá cherry-pick, commity se začnou zdvojovat, _pokud_ je dg zamerguje.

A tím pádem asi nejjednodušším rešením bude to, co jsem navrhoval minule, tzn. dělat své patche ve zvláštní větvi, a na tu posílat dg pull requesty. Tím pádem se do vašeho master dostanou až když pullnete z upstreamu, od dg. Je to jasnější?

(Kdyžtak pište mail, nebo běžte na IRC Freenode #github, ať z toho tady neděláme fórum o Gitu :)

OK dobře :-) Děkuji za info a za čas.

Rapidně rostoucí popularita decentralizovaných, nerelačních databází …

relačnost a decentralizovanost spolu nějak souvisí?

Mám takový dotaz a je to tak trochu OT, za což se omlouvám, ale tohle je momentálně jeden z nejaktuálnějších článků ohledně GITu. Osobně se asi tak 3. dnem učím git a pomalu na něj přecházím (doposud jsem nepoužíval nic, jen vlastní kopie, což tak nějak vypovídá o mých zkušenostech a znalostech) a chtěl bych se zeptat, jak je to s tagy.

Pomocí metody pokus-omyl jsem zjistil, že nastavování tagů pomocí „git tag xyz“ nastavuje poslední commit a že tag se uloží jen k jednomu commitu. Můj problém je, že nevím, jak zobrazit aktuálně nastavené tagy. Tedy, vím, že to jde pomocí gitk, ale v podstatě s gitem pracuji na příkazové řádce a i když preferuji klikací nástroje, s gitem pracuji v ní a když už, ta bych v ní chtěl dělat všechno, gitk pak používám pro vizuální kontrolu. Když použiji příkaz „git tag“, zobrazí se mi seznam všech tagů, ale neví někdo, prosím, jak zobrazit jen ty aktuální? Vezmu-li v potaz, že k jednomu commitu může být přiřazeno více tagů, padají metody jako „git tag | tail“, což by stejně moc nefungovalo z důvodu abecedního řazení.
Pořád si dokola pročítám ‚git help tag‘, ale na nic nemůžu přijít…

Nejdůležitější otázka je, k čemu přesně ty tagy využíváte, to z vašeho komentáře není úplně jasné.

> nastavování tagů pomocí „git tag xyz“ nastavuje poslední commit a že tag se uloží jen k jednomu commitu.

Tag vytvoříte nějak takto: git tag -a v.0.1 -m "First version" fccbbk, tedy „vytvoř tag s názvem v.0.1 ukazující na commit s ID fccbbk“. Tag je (víceméně a zjednodušeně) pouze „přezdívka pro commit“ (viz příkaz git show v.0.1).

> nevím, jak zobrazit aktuálně nastavené tagy

Tady nerozumím, co jsou „aktuálně nastavené“ nebo „aktuální“ tagy.

Eh, to se omlouvám za nepřesný výraz – myslím tím tagy týkající se posledního commitu.

Obecně jde o to, že když chci označit svůj commit na základě předchozího, udělám něco jako „git ziskej-posledni-tag“ a podle toho jej adekvátně upravím (např. inkrementuji).

> když chci označit svůj commit na základě předchozího, udělám něco jako „git ziskej-posledni-tag“ a podle toho jej adekvátně upravím (např. inkrementuji).

Teď se zas omlouvám já, ale pořád přesně nerozumím :) Ale v každém případě, tagy byste neměl nijak měnit. Pokud chcete „posuvný identifikátor revize“, tak na to je _branch_, tag je „neposuvný identifikátor revize“. Pořád ale není jasné, jak a k čemu ty tagy používáte.

Dobře, dám příklad:
Zadání: číselně označit každý commit jako revizi a to revXYZ, kde XYZ je číslo revize.

> git init
přidání souborů…
> git add .
> git commit -a
napíšu zprávu
> git tag rev0
úpravy
> git commit -a
zpráva…
> git tag rev1
další úpravy

… několik dní práce …

úpravy
> git commit -a
zpráva
! A hele, nepamatuji si číslo revize
> git ???
[výstup] rev123
> git tag rev124

> Zadání: číselně označit každý commit jako revizi a to revXYZ, kde XYZ je číslo revize

Aha, takže děláte tagy rev0 a rev1, _po každém commitu_?

Chcete mít nějaké „krásně sekvenční“ posloupnosti čísel „jako v SVN“? To nemá v Gitu a dalších DVCS valný smysl. Ten účel (otázka „k čemu“, ne otázka „co“) z toho pořád není jasný.

No, nedělám. I když neříkám, že nebyly časy, kdy jsem doufal, že by to tak šlo :3. Uznávám, že se git teprve spíš učím, každopádně:

– Svoje projekty – jak jsem výše psal – jsem doposud zálohoval do složek a to tak, že jsem měl složku „záloha“ a v ní složky „01“, „02“, „03“ atd. a chtěl bych to převést do gitu (šetří mě to přes 90% místa a je to rychlejší, když chci něco vytáhnout z archivu), ale číslování bych tam chtěl nechat, protože ty staré zálohy už tak mám označené a nemusel si někde dělat tabulku „To, co bylo ve staré záloze 32 je v nové záloze 3d67c…“ (v podstatě ty tagy mi umožní vytvoření této tabulky přímo v gitu)

– Druhá věc je když si chci označit libovolný release – bylo by úžasně pohodlné napsat něco jako „git tag –last-tagged-commit“ a jen inkrementovat dle potřeby

Jinak pokud jde o to „jako v SVN“: svn jsem nikdy nepoužíval a začal (a skončil) jsem se ho učit asi tak před půl týdnem. Pak jsem dospěl k závěru, že git je lepší (i když mě trochu mrzí to, že neukládá rozdíly mezi soubory, ale vždy celé soubory – blbě se tak budou verzovat binární soubory, které se trochu mění, ale co už).

Aha, super.

> „To, co bylo ve staré záloze 32 je v nové záloze 3d67c…“

Jako referenční „slovníček“ mezi „revizemi“ ve starém systému a v Gitu to smysl dává velmi dobrý, a tak je to správně a velmi dobrý nápad.

> bylo by úžasně pohodlné napsat něco jako „git tag –last-tagged-commit“

Aha aha, tak to asi hledáte git describe [http://www.kernel.org/…escribe.html]

Jo jo, to je ono, moc díky :). Nechápu, že jsem si to nenašel ve všech těch tutorialech a manuálech co jsem po netu sehnal :3. Moc díky

Super! :)

Jinak se můžete ptát na anglickém http://freenode.net IRC kanále #git nebo #github, hodně gitsterů taky máme na českém Rails IRC kanále #rubyonrails na serverech http://ircnet.cz.

Fajn, díky za info :)

Pripada mi, ze praci za nekolik dni davate do jednoho commitu. Pri delani zaloh kopirovanim to asi bylo nejschudnejsi, ale ze zkusenosti muzu rict, ze ve VCS je dobre delat vic jednoduchych commitu s kazdou zmenou/opravou­/vyvojem. Lepe se pak hleda kde se neco pokazilo, muzete si davat opravy do nejake hlavnejsi vetve atd. Sice nemam takovou disciplinu, abych commitoval casto, ale s gitem jsem uz tak zvlcel, ze po tech par dnech rozcommitovavam do ruznych vetvi a pak je rebasuju :-)

Doporucuju to zkusit az se szijete a dokoncite migraci… (tedy ty male commity)

Popravdě řečeno jak kdy – ale (pokud jsem se do práce fakt „nezažral“) většinou to bývalo minimálně jednou za den. Začal jsem s tím, abych si uložil stabilní verze (bod obnovy) a pak před tím, než jsem se pustil do nějaké větší úpravy, která by to mohla všechno rozbít (k čemuž se v gitu – pokud to chápu správně – používají větve (branch)).

No, rozhodně si teď dělám nesmyslné „projekty“ a testuji, co dělá větvení a tak rebasování (zrovna jsem jednu rebasi potřeboval na migraci projektu – měl jsem tam prázdnou složku, která ovšem byla nutná k chodu a samozřejmě se neuložila, tak jsem tam všude do historie musel strčit nějaký soubor – .htaccess postačil :3).

Pokud jde o to commitování po každé změně – no, právě proto, že jsem si nebyl jistý, jak to dělat jsem si stáhl git repozitáře samotného gitu a pak linux jádra (byl jsem zvědavý, jak vypadá velký projekt) a v gitk jsem si prošel historii, jak se dělají jednotlivé commity (Linus je vážně ukecaný chlapík, většina ostatních vývojářů tam stručně popíše, co se děje, Linus tam u verze gitu 0.99 popisoval, jak kdysi pracoval na jakémsi projektu, kde verzí 0.99 bylo obrovské množství a jedna (asi 0.99.5 nebo tak) prošla všemi písmeny abecedy XD). Nicméně si nejsem jistý, jak by bylo nejideálnější to dělat (spolu s větvemi). Např. pokud chci psát changelogy rychle a snadno, napadlo mě, že bych využil tipu z knihy Git Magic a to „git log > Changelog“. Jenže ten výpis by byl značně nepřehledný kvůli té hromadě malinkých commitů, proto mě napadlo, že bych měl větvi master jen na jednotlivé verze softwaru (0.1, 0.2, …) a dále větev např. working, kde by byly průběžné úpravy, commity a tak (a ze které by se pak větvilo na různé experimenty a tak) a nové commity v master-větvi by vznikali čistě pomocí merge master a working a do popisu daného master commitu bych sepsal základní informace o změnách ve working větvi, což by se pak přeneslo právě do changelogu :).

Eh, omlouvám se, mělo tam být „vznikaly“…

Tak na to, že děláte s Gitem 3 dny, postupujete a přemýšlíte naprosto správně!

(Jinak se koukněte na přepínače pro ten git log, asi byste z toho changelog mohl generovat docela hezky.)

Pekny serial, jen by se podle me pro lepsi nazornost hodil nejaky ten diagram ci obrazek

BTW: abych tu jen pořád nekydal o tom, že Mercurial mám radši než Git :-) Zjistil jsem, že Gitorious je svobodný software (šířený pod licencí GNU Affero GPL). To mi přijde jako dobrý argument pro Git – např. vývojářská* firma si může rozjet svůj vlastní Gitorious (no, často to bude kanón na vrabce**, ale což).

*) nebo jiná skupina, verzovat se nemusí jen zdrojáky, že?

**) chudáci vrabci, mám pocit, že poslední dobou dostávají čím dál víc zabrat :-)

clanek nema nalepku, na rozdil od 1., 2. a 4. dilu.

Díky za upozornění, už ji má.

chtel jsem se zeptat, zda je nejak mozne snadno zjistit po slouceni, co bylo delano ve ktere vetvi – priklad:

$ git log --graph --oneline
* 6e9525d test verze
* be492d3 verze
* a8b0a13 svn verze 220
*   723446b Merge branch 'master' into #45
|\
| * 2248269 pridan novy model M1
* | 7e5a3f8 procisteni formalnich warningu
* | 235a345 vyhozeni nepouzitych promennych
|/
* e29f2b0 uvodni import z SVN 217 - 2010.01.23

Jde nejak snadno zjistit, ze „7e5a3f8 procisteni formalnich warningu“ a „235a345 vyhozeni nepouzitych promennych“ bylo ve vetvi #45" a „2248269 pridan novy model M1“ bylo ve vetvi master? Jde nejak snadno vypsat _vsechny_ commity, ktere byly ve vetvi #45 (tedy 235a345, 7e5a3f8 a 723446b, ale nikoli 2248269 a nikoli uvodni e29f2b0 ktery vzniknul pred odstepenim vetve)?

Nebo nedavaji tyto otazky rozumny smysl?

(ano, v tomto grafu, kde je par radku je to asi „videt“, ale ja s gitem zacinam a jak to vidim, tak tech vetvi budu pouzivat mraky a commitu v nich taky)