Přejít k navigační liště

Zdroják » Různé » Pátý důvod, proč zvolit Git : Zkušenosti uživatelů Gitu

Pátý důvod, proč zvolit Git : Zkušenosti uživatelů Gitu

Články Různé

Náš seriál o Gitu zakončíme netradičně: zeptáme se několika různých uživatelů Gitu, proč si jej zvolili a jaké výhody i problémy jim, podle jejich mínění, přináší. Zároveň pro vás máme i malou soutěž, v níž můžete vyhrát knihu „Pro Git“, která je věnována právě práci s tímto verzovacím systémem.

Tímto článkem náš seriál „pět důvodů, proč zvolit Git“ zakončíme. Společně s pěti zástupci různých skupin a typů uživatelů Gitu se podíváme na to, co jim Git přináší — i na to, co jim „verzovací život“ komplikuje. Každému z nich jsme dali dvě otázky společné a jednu specifickou. Jejich odpovědi vám doufejme pomohou v přemýšlení, jaký verzovací systém zvolit a co od něj očekávat.

Ale ještě než jim dáme slovo, tak je tu čas na vyhlášení soutěže:

Soutěž

Před několika týdny vydalo sdružení CZ.NIC český překlad knihy Pro Git od Scotta Chacona. Kniha je k dispozici i v digitální podobě (můžete si ji stáhnout např. v naší knihovně – Pro Git). Pokud ale dáváte přednost klasickým tištěným knihám, máte šanci ji vyhrát v naší bleskové soutěži.
Pravidla jsou jednoduchá: Napište do komentářů nebo na Twitteru (jako odpověď pro uživatele @zdrojak) své pokračování věty „Git se mi líbí, protože…“ Z došlých odpovědí vybereme ty nejzajímavější, a jejich autoři dostanou právě tuto knihu. (Nezapomeňte na sebe nechat kontakt – mail nebo twitter, na němž s vámi dohodneme podrobnosti zaslání výhry.) Soutěž začíná vydáním tohoto článku a končí po 48 hodinách, tedy o půlnoci ze středy 20. ledna na čtvrtek 21. ledna.

David Grudl

David Grudl je autorem populárního open source software Nette Framework a spisovatelem programů.

Jakou největší hmatatelnou výhodu ti Git přinesl?

Samotné používání verzovacích systémů pro mě představovalo zásadní pokrok, nedovedu si dnes představit, jak bych některé projekty bez nich vyvíjel. Velmi jsem si oblíbil Subversion, které fungovalo svižně, mělo špičkový GUI nástroj TortoiseSVN a pokrývalo většinu mých potřeb. Změna nastala v okamžiku, kdy jsem začal používat veřejný SVN repozitář pro open source projekty. Tehdy jsem si začal uvědomovat, že verzování mi nevyhovuje tolik jako dříve a že vlastně s verzovacím systémem svádím neustálý boj. Proč? Verzování mi nepomáhalo, protože každý commit byl veřejný, nevratný a já si nemohl experimentovat „na vlastním písečku“. Začal jsem lokálně verzovat „postaru“ za pomoci komprimačního programu. Operace jako blame už nešlo ani používat, server Google Code a mé internetové připojení na to asi nestačilo.

Pak jsem se dozvěděl (od karmiho) o existenci decentralizovaných verzovacích systémů. Ty se ukázaly být řešením všech zmíněných problémů. Přechod ze Subversion na Git byl podobnou spásou, jako prvotní přechod z ničeho k Subversion. Tohle je pro mě největší hmatatelná výhoda: verzovací systém, který spolupracuje a se kterým nebojuji. Přitom zvenčí se jakoby nic nezměnilo, TortoiseGit je stejně cool jako TortoiseSVN.

Ještě bych zmínil druhou hmatatelnou výhodu: postupně si zvykám verzovat kde co. Třeba konfiguráky Opery. On je totiž diametrální rozdíl mezi založením repozitáře v SVN, které si navíc nasr… nastrkalo své adresáře do všech složek, a mezi napsáním pouhých sedmi znaků  git init.

Co ti na Gitu nejvíce vadí?

Jakožto člověk zajímající se o oblast user experience jsem rád, že se mi v podobě Gitu dostala do rukou tak košatá sbírka nejrůznějších příkladů na téma „tak tudy ne, přátelé“. Přitom ve stejném žánru vyšla i sbírka ukázkových příkladů nesoucí název Mercurial ;)

Jak velkou roli při přechodu open source frameworku Nette na Git hrála existence hostingu GitHub?

Kupodivu žádnou. Ba naopak, od Gitu mě odrazovalo, že jej nepodporuje Google Code. Z dnešní perspektivy se mi to jeví jako absurdní, GitHub má před Google Code náskok několik koňských délek, ale dokud na to člověk nepřijde, vidí svět ze svého omezeného pohledu.

Github má ambici nastartovat komunitu kolem open source projektů tím, že úložiště pro repositář povyšuje na programátorskou sociální síť. Facebook pro programátory. Zatím to má spoustu nedostatků a nedodělků, což příliš nevadí, když je patrné, jak jde jeho vývoj svižně kupředu.

Největší výhodu GitHubu ale nevidím tolik ve funkcích, jako spíš v přehlednosti a již zmíněném user experience. Se serverem se pohodlně a intuitivně pracuje, jde o dokonalý protiklad SourceForge — a Gitu.

Martin Michálek

Martin Michálek je webdesignérem, HTML kodérem a vedoucím projektů ve studiu Shortcat.

Jakou největší hmatatelnou výhodu ti Git přinesl?

Verzování je pro mě díky Gitu daleko přirozenější součástí života s počítačem. git init používám opravdu široce, nejen pro případy typu „verzování webového projektu“. Dříve byla moje lenost daleko silnější než potřeba pokaždé vytvářet Subversion repozitář někde na serveru.

Co ti na Gitu nejvíce vadí?

„Geekovitost“. Z příkazů Gitu, jeho přepínačů a všech možných kombinací se mi trochu motá hlava. Naštěstí si myslím, že složitější příkazy nepotřebuji. Vedl jsem na Windows zpočátku boj s SSH autorizací, ale ono to člověku prospěje, něco se naučit.

Jsi uživatel-neprogramátor, navíc pracuješ primárně na Windows. Jak z tohoto pohledu Git hodnotíš? Vyplatilo se ti jej začít používat?

Původní rozhraní „msysgit“ bylo příšerné. Naštěstí existuje TortoiseGit, které má rozhraní znovu příšerné, ale způsobem, který znám z TortoiseSVN. Můžu srovnávat jen se Subversion (a kdysi CVS), nicméně naučit se Git se mi jednoznačně vyplatilo. Bez ohledu na platformu navíc považuji Git za výrazně přátelštější k týmové práci než starší verzovací systémy.

Jan Král

Jan Král je softwarovým architektem a vedoucím vývojářského týmu ve společnosti Centrum Holdings, kde má na starosti vývoj, technické zázemí a inovace webových aplikací.

Jakou největší hmatatelnou výhodu ti Git přinesl?

Rozhodně svižnější vývoj – menší režii při zakládání repositáře a mnohem snazší paralelní práci. Na jednom projektu může pracovat více lidí bez zbytečných kolizí a konfliktů (díky využívání větví). Snadné a rychlé commitování nám přináší přehlednější sdílenou historii a snazší práci s ní (můžeme např. nasadit hotfix jen pomocí  cherry-pick).

Co ti na Gitu nejvíce vadí?

Občas nás potrápí Git klient pro Windows, který v závislosti na tajemných okolnostech a různých nastaveních rozhazuje konce řádků (tzv. CRLF). Jinak mě vůbec nic nenapadá…

Co považuješ za největší konkurenční výhodu Gitu ve srovnání s ostatními decentralizovanými systémy na správu verzí?

Git byl u nás zakořeněný již v době, kdy jsme se začali poohlížet po nějakém decentralizovaném verzovacím systému. Líbil se nám, a tak jsme to nějak extra neřešili.

Pro mě osobně je výhodou Gitu jeho filozofie — velmi jednoduché nástroje a principy, které se skládají dohromady a umožňují uživateli udělat cokoli si zamane. Navíc díky rychlosti práce v Gitu nemusím na nic čekat. Především mohu velmi často commitovat a vzniklé commity pak upravit po dokončení ucelené části práce, než je odešlu do sdíleného repositáře.

Jiří Kubíček

Jiří Kubíček je majitelem společnosti KRAXNET, která poskytuje služby registrace domén, hostingu a vývoje software na zakázku.

Jakou největší hmatatelnou výhodu ti Git přinesl?

Flexibilitu. Dříve jsem nový projekt začal verzovat až tehdy, když už to „dřelo“. Teprve velikost projektu mě vždy donutila vzpomínat, jak vlastně přidám na serveru nový projekt do SVN. Měl jsem na to nakonec nějakou sadu utilit, ale stejně to moc pohodlné nebylo. Na malé věci jsem měl jeden společný SVN repositář a všechno jsem do něj míchal. S Gitem si mohu založit nový repositář, kdykoliv začínám něco nového, a to klidně i na chatě, protože nepotřebuji ani přístup k serveru. Teprve když zjistím, že projekt za něco stojí, nahraju ho na server a zpřístupním ostatním kolegům nebo komunitě.

Druhým velkým přínosem byl pro mě GitHub. Umožňuje velmi snadno „naforkovat“ cizí projekt, udělat úpravy (ty jednoduché lze provádět přímo v rozhraní webu) a poslat tzv. pull request (žádost o začlenění mé změny do původního repositáře). To dle mého názoru velmi pomáhá rozvoji open source software.

Co ti na Gitu nejvíce vadí?

Malá osvěta a malé nadšení pro Git ve společnosti. Nebaví mě pořád se hádat, proč je Git lepší než jiný SCM, který je integrován v kdejakém IDE. Škodovkáři ale asi budou pořád tvrdit, že jejich vytuněná „stodvacítka“ je to nejlepší, čím se dá jezdit. Možná mi trochu vadí jeho možnosti, které jsou obrovské. Znát všechny Git příkazy je snad až nadlidský úkol a vždy mě překvapuje, co ještě v něm lze udělat — a navíc docela snadno.

Jako hostingová společnost máte zkušenosti s požadavky Gitu na infrastrukturu (instalace, zálohování, podpora uživatelů,…). Jak jej z tohoto pohledu hodnotíš?

Git se nám moc líbí, takže poskytujeme i služby Git hostingu ke všem našim placeným hostingovým tarifům (nebo jako zvláštní službu). Z pohledu administrátora serveru je Git velmi jednoduchý a nezáludný. Začlenění Gitu do infrastruktury našeho hostingu bylo velmi snadné, takže jsme se mohli zabývat spíše funkcemi pro snadné sdílení repositářů, nebo uživatelským rozhraním. Trochu však zápasíme s podporou uživatelů, kteří se přihlašují SSH klíči (využíváme klíče místo hesla) — zejména u těch, kteří používají Windows.

Petr „pasky“ Baudiš

Petr Baudiš je programátor působící v řadě open source projektů. Dříve byl také jedním z hlavních vývojářů Gitu a jeho nyní již historického přátelštějšího rozhraní Cogito. V současnosti se zabývá low-level linuxovým programováním a umělou inteligencí.

Jakou největší hmatatelnou výhodu ti Git přinesl?

Pohodlí. V tom se snoubí všechny pěkné vlastnosti Gitu — rychlost, možnost offline práce, možnost úprav historie, flexibilita…

Co ti na Gitu nejvíce vadí?

Stále nedokonalé uživatelské rozhraní na úrovni příkazové řádky. Příkazy v Gitu se vyvíjely hodně živelně a ze spousty historických důvodů je řada méně obvyklých operaci matoucí a různé funkcionality se náhodně prolínají několika příkazy.

Nejzřejmější příklad je manipulace s jednotlivými soubory v indexu a pracovní kopii, kterou pokrývají příkazy add, rm, reset, checkout (a možná některé další); inverzní operací k add  může být rm nebo reset, inverzní k rm  zase add nebo checkout, atd. Občas při neobvyklejším použití příkazu reset a checkout zaváhají i samotní vývojáři Gitu.

Pak jsou tu samozřejmě ty opravdu těžké problémy, které uspokojivě nevyřešil zatím žádný verzovací systém – skutečně kvalitní grafické rozhraní pro propojení obsahu a jeho historie nebo přirozená podpora situací, které se lopotně snaží řešit TopGit.

Mezi uživateli panuje téměř univerzální shoda v tom, že větvení a slučování větví je v Gitu jednodušší než v ostatních verzovacích systémech, typicky v Subversion. Můžeš vysvětlit, jaké architektonické, implementační či jiné důvody to může mít?

V Subversion jsou primárními objekty soubory a adresářové stromy, i v GUI vidíme většinou v prvé řadě soubory. Tento způsob myšlení pochází už z CVS, což bylo v podstatě jen vylepšení RCS tak, aby člověk mohl commitovat a updatovat postupně více souborů najednou, a mohl tak činit i po síti. Toto dědictví tu je vlastně dodnes, kdy všechno důležité se v Subversion děje na úrovni stromů, a jen tak náhodou a mimochodem tyhle stromy mají i jakousi historii — a můžeme se vracet ke starším verzím. Nejdříve ale řekneme jméno souboru či adresáře, a teprve pak řešíme revizi.

V Gitu je to opačně – i GUI nám ukáže nejdříve commity! Git vychází z Monotone a jeho modelu stromu objektů (commit, tag, tree, blob, …). Díky tomu je primární paradigma graf historie – všechno zajímavé se děje uvnitř tohoto grafu: revize jsou uzly a větev je vlastně jen pojmenovaný odkaz někam dovnitř grafu. Naopak méně důležité je to, co v těch uzlech máme, že tam jsou odkazy na nějaké další objekty a „náhodou“ se dostaneme i k nějakým souborům. Nejdříve se rozhodneme, která revize nás zajímá, pak teprve řekneme název souboru v dané revizi.

To má samozřejmě spoustu důsledků, architektonických i implementačních. Ať už jde o eleganci pojmu branch a tag (a díky tomu i o snadnost zacházení s nimi) nebo o to, že najít v takovém případě bázi pro operaci merge, a vůbec merge reprezentovat, je úplně přirozená věc. (Naopak, mnohem méně přirozené je v Gitu třeba zjišťovat historii týkající se jen některých souborů, i když z uživatelského hlediska je to samozřejmě triviální i zde).

Tato změna pohledu také umožnila snadno vymyslet úžasně efektivní „kompresní“ algoritmus tzv. pack souboru. Vychází z toho ale též nechuť skalních „gitovců“ k lineárnímu číslování commitů, ukládání informací o přejmenování souborů nebo k udržování informace o tom, do které branche byl uložený který commit.

Závěr

V sérii článků jsme si představili některé zajímavé nebo unikátní rysy systému pro správu verzí Git a ukázali jsme si jeho možnosti. Git nám přitom do jisté míry sloužil jako zástupce tzv. decentralizovaných nebo distribuovaných verzovacích systémů (DVCS). Přestože je v mnohém jiný než ostatní, jeho základní myšlenka, tedy přijmutí a využití decentralizace, je jim společná a jasně ukazuje do budoucnosti. Koneckonců, nejvýznamnější zástupce centralizovaného modelu, Subversion, má mezi dlouhodobými cíli jasně uvedeno: hybridní decentralizova­ný/centralizo­vaný model verzování

(Autor děkuje za odpovědi všem dotázaným.)

Komentáře

Subscribe
Upozornit na
guest
13 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
David Majda

Git se mi líbí, protože mě přinutil přemýšlet:

  • nad designem verzovacích systémů
  • nad designem software obecně a jeho hodnotami (mj. funkčnost, uživatelské rozhraní, použitelnost, rozšiřitelnost, flexibilita, výkonnost, minimalističnost)
  • nad důležitosti těchto hodnot a jejich vzájemným vztahem
  • nad tím, zda osobně považuji za důležité věci, které jsou ostatním jedno, a naopak
  • nad důvody, proč tomu tak je
  • nad faktory, které mimo kvality ovlivňují rozšířenost software
  • nad tím, zda je opravdu horší lepší
  • nad důležitosti být při vývoji open source projektů kompatibilní s okolním světem
  • nad tím, jestli je Linus geniální nebo ne :-)
  • nad obrovskými rozdíly v mentalitě uživatelů různých OS, které se často zdají být nepřekonatelné
  • nad obrovskými rozdíly v mentalitě různých společností a vývojových týmů, které se často zdají být nepřekonatelné
  • atd., atd., atd.

Je toho docela dost na kus softwaru, který v podstatě nepoužívám :-)

Borek Bernard

To je ale lišácký komentář :)

uf

Zatim (asi, do podrobna ho neznam) umi i mercurial.

Kit

Zkoušel jsem Git na SSHFS, ale neprojde ani základní git init. Místo toho hlásí chybu:

error: could not commit config file .git/config
error: could not commit config file .git/config
error: could not commit config file .git/config
Initialized empty Git repository in .git/

Poslední hláška říká, že je vše založeno, ale 3 errory výše oznamují, že to v pořádku není. Adresář .git je založen, ale zřejmě nebude kompletní a tím pádem ani funkční. Naznačuje to chybu v SSHFS, ale i tak je to podivné chování.

Na svazcích připojených přes Sambu funguje Git normálně.

Martin Kopta

Věříím, že tenhle postřeh více ocení vývojáři SSHFS a Gitu, než čtenáři Zdrojáku, a také s ním patrně jsou s to něco udělat, narozdíl od čtenářů Zdrojáku. ;-)

pr.rybar

dělá spolehlivě to, co od nej očekávám.

Matej Kravjar

Git sa mi páči najmä preto, že mi umožňuje neskutočne elegantne robiť operácie, na ktoré človek predtým ani nepomyslel, vcelku často využívam napríklad:

$ git add -p ...
$ git rebase -i ...

A rozhodne i pre vychytávky v command-line ako auto-less dlhého výstupu :)

fos4

je to něco nového a to mně zajímá :-)

Riny

při přechodu na něj jsem absolutně nemusel měnit styl práce a přesto mi ji značně usnadnil.

:3

Git nemaster

… hodně mi tu chybí odvrácená tvář, tedy konfigurace serveru. Nešlo by přidat ještě jeden díl, ve kterém by se probrala tato problematika?

Michal

Zapomneli jste na (pro me) nejzasadnejsi duvod a tim je komunita a vyborne fungujici knowledge base na netu. Zkuste si treba dat do smart address bar „git untrack files“. Umi toto jiny prostredek?… :-)

Riny

Popravdě řečeno jsem zrovna u tohoto programu vůbec nepotřeboval obrátit se na komunitu :3.

Btw. OT., na praxích, kde teď pracuji, musíme používat SVN a čím dýl s tím pracuji, tím víc mi chybí git. Navíc teď už ani nemůžeme mít svoje vlastní branche, takže všichni commitujeme jen do jednoho jediného adresáře; jinými slovy, můžeme commitovat až hotový task a nemáme vlastně prostředky pro takové situace, jako uprostřed rozdělané práce přijde aktuní bug. Snad ani nemusím psát, že jsem si zařídil aspoň lokální git repozitář :3. (Třeba taky pro případ, kdy se chci pustit do experimentu uprostřed práce a nemůžu to commitnout, protože bychom pak měli na SVNce rozdělanou práci :3.)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.