Komentáře k článku

První důvod, proč zvolit Git: Neříká vám, jak máte pracovat

Přinášíme vám první část pětidílného seriálu o tom, co vám může nabídnout verzovací systém Git. Budeme se v něm spolu s Karlem Minaříkem, propagátorem tohoto systému v ČR, věnovat jak obecným důvodům, tak okrajovým či unikátním vlastnostem Gitu. V dnešní části se zaměříme na svobodomyslnou povahu Gitu.

Zpět na článek

75 komentářů k článku První důvod, proč zvolit Git: Neříká vám, jak máte pracovat:

  1. alblaho

    konzervatismus

    No, MVC se ve Smalltalku používá už hezkých pár desítek let. Analogii k RESTu bychom v historii taky určitě našli.

    K tomu konzervatismu. Ono přejít z jednoho verzovacího systému na jiný není vůbec žádná sranda. Jsme malá mladá firma a s přechodem svn->git se trápíme několik měsíců. Je na to zkrátka navázáno spousta věcí. Z tohoto důvodu leckde používají CVS, což je to pravé peklo.

    1. Milan

      Re: konzervatismus

      No ja nevim. Ja zazivam peklo teprv se SVN. s CVS jsem nemel nikdy problem. Vlastne jo. Obcas nam spadlo spojeni pri komitu :), ale i tak naprosto nechapu, proc je vsude SVN.

    2. Karel MinaříkAutor příspěvku

      Re: konzervatismus

      > MVC se ve Smalltalku …

      Ano, to leckde :), ale v kontextu vývoje pro web to „prosazení“ přišlo docela pozdě. Viz např. http://en.wikipedia.org/…VC_Framework :)

      > … s přechodem svn->git se trápíme několik měsíců …

      Obecně by v tom neměl být velký problém – záleží ale na tom, co máte na verzovací systém navázáné: build process, spoustu hooků, autentizaci/au­torizaci oproti LDAP, apod. Tam pak může být dost práce s migrací takové infrastruktury okolo; s Gitem to ale nesouvisí. Napište případně víc, gitsteři rádi poradí.

  2. AraxoN

    spolupráca viacerých vývojárov

    Ako sa v Git rieši spolupráca viacerých vývojárov? Každý má svoj strom a potom sa raz za čas stretnú a „dokopú“ ho aby bol u každého rovnaký?

    1. Aleš Roubíček

      Re: spolupráca viacerých vývojárov

      git samozřejmně umožňuje spolupráci mnoha autorů a to různými způsoby. Myslím, že se k nim Karel dostane v některém z dalších dílů.

    2. Karel MinaříkAutor příspěvku

      Re: spolupráca viacerých vývojárov

      > … spolupráca viacerých vývojárov?

      Chci se k tomu dostat v dílu o „decentralizaci“. Ale základní informace najdete v češtině již v přehledu na http://whygitisbetterthanx.gitfu.cz/#…, příp. v angličtině v článku odkazované knize: http://progit.org/book/ch5-1.html

      > Každý má svoj strom a potom sa raz za čas stretnú a „dokopú“ ho aby bol u každého rovnaký?

      Většinou ne, pokud správně chápu otázku. Normálně se používá centralizovaná workflow, tedy „jako v Subversion“: každý má „svůj“ repositář a průběžně odesílá práci do repositáře „centrálního“, resp. „sdíleného“. Důležité je to, že „centrální“ je prostě jen na základě domluvy, není ničím speciální – jen má nějakou adresu, kam se všichni dostanou, nastavená práva, atd.

      Pro další workflow koukněte na ty odkazy.

      1. AraxoN

        Re: spolupráca viacerých vývojárov

        Ďakujem za odpoveď, za odkazy a za nakopnutie. Už nejakú dobu riešim čím nahradiť CVS, tak sa teším na ďalšie časti seriálu.

  3. Aleš Roubíček

    .gitignore vs. .svnignore

    Myslím, že v článku je trochu zavádějící příklad s .gitignore v kontrastu se šaškárnou svn:ignore. SVN má samozřejmě stejný koncept jakoo git a to soubor .svnignore. ;) A má ho snad většina verzovacích systémů z těch, se kterými jsem pracoval.

    Jinak moc pěkný článek a těším se na další díly.

    1. Karel MinaříkAutor příspěvku

      Re: .gitignore vs. .svnignore

      > SVN má samozřejmě stejný koncept jakoo git a to soubor .svnignore

      Já už sice SVN aktivně nějakou dobu nepoužívám, ale o .svnignore nic nevím, a ani jsem o něm nikdy nic neslyšel. Nemáš nějaký odkaz?

      1. Petr Tesařík

        Re: .gitignore vs. .svnignore

        Já bych řekl, že Aleš si to spletl s .cvsignore. Ale také nejsem žádný SVN guru, tak se případně nechám rád poučit.

      2. Aleš Roubíček

        Re: .gitignore vs. .svnignore

        A teď jsem možná za vola :) Nemám po ruce stroj s windows abych dokázal své tvrzení a možná jsem se ukvapeně spletl (TFS na Codeplexu má .tfs-ignore a pro přístup na Codeplex jsem používal SVN bridge a TortoiseSVN). Omlouvám se za neověřený nesmysl. :)

  4. Lukáš

    GIT IDE integrace

    Chtěl jsem zavést Git u jednoho projektu (Ani ne kvůli nespokojenosti s ostatníma VS jako kvůli tomu, že pro projekt jsou GIT specifické funkce jako ušité) ale zastavil jsem se u dobře fungujícího pluginu do Eclipse, případně Netbeans. Po zkušenosti se SVN vím, jak TortoiseSVN dokáže zpomalit systém a taky že dobrá integrace v primárním programátorském IDE dokáže slušně akcelerovat práci.

    1. HKou

      Re: GIT IDE integrace

      V pripade GITu sice pluginy celkem funguji (Idea, Eclipse), ale drive ci pozdeji prestanou a je potreba pouzit radkoveho klienta. Pozor na toho ve Win, starsi verze (nevim presne ktera) likviduje konzistenci repository.

  5. Rdm

    malý dotaz :)

    Pracuji na jednom projektu – webové aplikaci a potřeboval bych mít jedno úložiště společných souborů (administrace atd.), kdy jakmile provedu změnu a uložím do tohoto úložiště, tak toto úložiště se přes FTP spojí s nastavenými servery a tyto změny nakopíruje na ostré projekty. Umí toto Git? nebo jiný systém?

    1. Karel MinaříkAutor příspěvku

      Re: malý dotaz :)

      > jakmile provedu změnu a uložím do tohoto úložiště, tak toto úložiště (…) tyto změny nakopíruje na ostré projekty

      Nevím, jestli přesně rozumím, ale jedno z (netradičních!) použití decentralizovaného systému na správu verzí je právě „content distribution“.

      Můžete mít někde „váš“ repositář, do kterého ukládáte nějaký obsah (text, obrázky, atd.). Pak existují další repositáře, dostupné přes síť. Jakmile do „vašeho“ repositáře uložíte data, která chcete poslat na ty ostatní, dáte příkaz git push, tedy např. git push praha deploy, git push brno2 deploy, atd. Tento push můžete samozřejmě obalit nějakým skriptem, nebo pouštět hookem, apod. Takto můžete posílat reklamy na obrazovky běžící v obchodech, apod.

      Možná se vám ale jedná prostě jen o to, mít určitou část kódu vyčleněnou a sdílenou. To je něco, co se v SVN nazývá „externals“ a v Gitu byste to pravděpodobně řešil jako „submodules“, viz kniha http://progit.org/book/ch6-6.html. Na straně „ostrých projektů“ pak musíte zajistit, že při pushi do daného repositáře se zaktualizují soubory v pracovním adresáři, nebo musíte použít jiný deploy mechanismus, jako např. Capistrano.

    1. Karel MinaříkAutor příspěvku

      Re: SVN v

      Chápu, ale když mně se pořád a každý ptá, proč Git a ne SVN. Tak co naděláme? :)

      1. Bubak

        Re: SVN v

        Tak to dejte do samotneho clanku. Muzete treba take zminit git-svn portaci.

        Pokud za kazdou vetou bude poznamka, ze SVN je na prd, tak se to fakt neda cist. Navic SVN ani dostatecne nerozumite na podobne kritizovani, cast s .gitignore versus .svnignore to dokazuje.

        Dale bych byl opatrnejsi tvrdit, ze GIT je jednodussi nez SVN. V SVN staci jeden commit a je hotovo. V Gitu jsou opicarny jako vycefazovy commit, lokalni commit… Z vlastni zkusenosti vim, ze zacatecnik se spis nauci s SVN.

        1. Karel MinaříkAutor příspěvku

          Re: SVN v

          > Pokud za kazdou vetou bude poznamka, ze SVN je na prd, tak se to fakt neda cist.

          Nic takového ale v článku není. V článku jsou zmíněny konkrétní postupy a případy, kdy je práce s Gitem jednodušší než se SVN (zřzení repositáře, ignore, atd.)

          > Navic SVN ani dostatecne nerozumite na podobne kritizovani, cast s .gitignore versus .svnignore to dokazuje.

          Ale ale, tak brzy a už tu máme urážky? :) Máte nějaký odkaz na Alešem zmíněný mýtický .svnignore? Nevím tedy, co to „dokazuje“, ale o něm jsem doopravdy nikdy neslyšel.

          > Dale bych byl opatrnejsi tvrdit, ze GIT je jednodussi nez SVN.

          Git je jednodušší než SVN ve většině operací, které cílový uživatel provádí. Mějte na paměti, že to není jen commitování, ale i zřízení repositáře, nastavování ignores, prohlížení historie, práce s větvemi, …

        2. Karel MinaříkAutor příspěvku

          Re: SVN v

          > Navic SVN ani dostatecne nerozumite na podobne kritizovani, cast s .gitignore versus .svnignore to dokazuje.

          Tady nám to nějak ztichlo. Nechcete se prosím vrátit a vysvětlit jak je to s tím mysteriózním .svnignore?

            1. Karel MinaříkAutor příspěvku

              Re: SVN v

              Ano, ale to je něco _úplně_ jiného než mojerepo/.gitignore, že? Konfigurace ignorovaného obsahu a správa pravidel prostě _je_ v SVN objektivně složitá. (Můžeme se hádat o to, jestli to „vadí“ nebo nevadí. Ale objektivně _je_ složitá.)

            1. uf

              Re: Mercurial

              Mercurial jsem tak do hloubky nestudoval, ale ignore list ma taky, je decentralizovany atd. SVN & co. byl zacatek, vzdycky se prislo na neco, co je potreba vylepsit. Ted jsou nutne distribuovane spravy verzi. A ty musely samozrejme resit stejne problemy.
              Takze PROC NE MERCURIAL, ale git ?

              1. Karel MinaříkAutor příspěvku

                Re: Mercurial

                Tak aby to nevypadalo, že se vyhýbám odpovědi :)

                > Takze PROC NE MERCURIAL, ale git ?

                Na to není žádná „objektivní“ odpověď. Budou na to jen velmi, velmi subjektivní odpovědi.

                Já vám řeknu, „protože Git je výkonnější a flexibilnější“. Někdo jiný řekne, že „na to jde do Mercurialu doinstalovat plugin XYZ“ a že „Mercurial je jednodušší“.

                Já řeknu, že „protože GitHub“ a někdo jiný řekne, že „BitBucket taky není špatný“, resp. „BitBucket je stejně lepší“ (a už to lítá).

                Taková debata je „náboženská“ v tom smyslu, že (většinou, ne vždy) jen utvrzuje účastníky v jejich přesvědčeních, ale přináší málo informací.

                Je to stejná debata, jako jestli je lepší Ruby nebo Python. Každý si to musí vyzkoušet sám a jedno mu prostě sedne do ruky líp než to druhé.

                1. František Kučera

                  Re: Mercurial

                  Takže se na to vlastně líp neodpovídá :-)

                  > Je to stejná debata, jako jestli je lepší Ruby nebo Python.

                  Stejně každý ví, že nejlepší je Java :-)

    2. Lukáš

      Re: SVN v

      SVN používám jen pasivně, měl jsem za to, že je to v současnosti standartní VS (nejlepší volba). Zajímaly by mě vaše negativní zkušenosti se SVN (prosím, žádné srovnávání s GITem.)

      1. ijacek

        Re: SVN v

        SVN byl sveho casu spasa z nebes, pak standard a dodnes je to asi dobry zpusob, jak si vyzkouset praci s VCS. Ja sam jsem byl dlouholetym zastancem a nedal jsem na nej dopustit – az do chvile, nez jsem se podival na par prednasek a evangelii o GITu. Pak mi doslo, ze pouziti SVN je slozite a nuti uzivatele ke kompromisum a obezlickam, jen jsem si toho za ty roky nevsiml, protoze me proste nenapadlo, ze se to da delat i jinak. Je to tak vazne, ze tezko pochopite nevyhody SVN, pokud jste zvykly uvazovat jen v nem.

        Ale dobre, jelikoz nechcete srovnani, sdelim to jako absolutni pravdy
         – SVN je strasne pomale, update, commit, switch, operace na minuty. Jen zjisteni zmen na cele vetvi trva asi 10–20 minut.
         – inicializace neohrabana, vzdy nez jsem se do pustil verzovani nejakeho projektu, uz jsem mel rozkopirovane ruzne verze, protoze to proste bylo v tu chvili rychlejsi nez se parat se zalozenim rep, init, checkout…
         – neumi to castecne commity, to je proste opruz, kdyz mam v jednom souboru novy vyvoj, opravu a ladici kod a ted chci aspon rozdelit do zvlastnich commitu vyvoj a opravu a ladeni nechat byt
         – vetveni – ano, je atomicke, ale jen na serveru, rezie kolem je tak velka, ze se do toho clovek nepusti pokud nema vazny duvod
         – nevim jak je to s merge tracking v novych verzich, drive jsme museli drzet hodne informaci bokem abysme spravne sloucili vetve

        Obecne mi doslo, proc jsou uzivatele GITu tak povyseni nad SVN. SVN je proste spravne CVS, odstranilo jeho neduhy, ale porad je to pokracovani 20 let stare koncepce.

        1. vandrovnik

          Re: SVN v

          Nevím, jak máte velký projekt, ale SVN se u mě chová výrazně lépe (používám ve Windows TortoiseSVN). Update/commit: max. 20 sekund (pokud jsem ve složce nepracoval a nic není v cache), zpravidla řádově sekundy. Inicializace trošku neintuitivní, pravda. Částečné commity – prostě mohu označit soubory, které chci/nechci commitnout, nebo máte na mysli něco jiného?

          1. ijacek

            Re: SVN v

            Jo, ten projekt je trochu vetsi, ~50k souboru, 1GB dat. Taky pouzivame TSVN. Myslel jsem, ze ty operace trvaji dlouho, protoze je ten projekt velky, ale git me vyvedl z omylu. Vetsina akci trva radove 1s. Nevim jak se to bude chovat pri velkych merge apod. ale zatim to vypada slibne.
            Castecny commit – vyber radku.

            1. vandrovnik

              Re: SVN v

              V mem pripade ma slozka projektu 37k souboru a 6,8 GB dat (pocitaje v to v obou pripadech i skryte soubory, ktere si udelalo SVN), takze ten nepomer v rychlosti me stale docela zarazi. Provozovano na dnes uz obstaroznim jednojadrovem AMD 3 GHz procesoru a 2 GB RAM. Commit jako takovy trva dlouho jen kvuli pomalemu uploadu na ADSL, update jde svizneji. Nemuze byt rozdil treba v antiviru nebo necem podobnem? Jestli treba TSVN klient nedela neco navic, co vyprovokuje antivir k zasahu, zatimco Git ne? Schvalne jsem to ted zkusil se stopkama v ruce a od zvoleni prikazu Commit do chvile, nez mi nabehne okno se zmenenymi soubory, to trvalo 3,67 s (je pravda, ze jsem ve slozce pred chvili pracoval).

              1. ijacek

                Re: SVN v

                Jsem se na to jeste podival, celkove i s prelozenymi soubory to ma 140k souboru. Opakovany commit trva 12s, celou dobu to zralo cpu. Take uz mam starsi stroj a je fakt, ze to se da snest. Studeny commit je ovsem mnohem pomalejsi – 5 minut, zadny AV nemam, na disk to predtim ani potom nehrabalo. Z externiho disku to trvalo 25 minut.

        2. Jirka P

          Re: SVN v

          Skoro všechny tyhle výhrady odstraňuje na SVN klient SVK (až na tu první). Ale i s ním je to mnohem méně použitelné, než GIT, IMHO proto, že (kromě té nevázanosti, o které se píše v článku) GIT má v sobě „zadrátovaný“ koncept historie coby DAGu, zatímco SVN (třeba při práci s větvemi) zůstává při práci s lineární historií.

    3. Tomas

      Re: SVN v

      Souhlasim, autor by mel vyzdvyhnout prednosti Gitu a ne shazovat SVN.
      Prepokladam, ze to nema byt clanek o tom jak je SVN spatne, ale o Gitu.

      Pouzival jsem SVN mnoho let a nemel jsem s nim skoro zadne problemy. Musim uznat, ze od doby co jsem poznal Git uz SVN moc nepouzivam.

      Pokud bych Git neznal a autor se jen porad opiral do SVN, tak bych si rekl, ze to neni objektivni clanek o Gitu, ale ze autor pouze nesnasi SVN a clanek bych v pulce prestal cist. Obdobne jako podobne clanky o Linuxu, ktere o Linuxu nic moc nereknou ale jen se porad navazeji do Windowsu.

  6. Martin Michálek

    Konzervy od počítačů / GIT na Windows

    Lidé od počítačů jsou — možná docela paradoxně — velmi konzervativní

    Karle, vím, že to úplně není k věci, ale myslím, že konzervatismus IT-lidí jenom kopíruje stav v populaci. Ano, lidé od počítačů jsou většinou více nebo méně konzervativní než ty sám, ale osobně na tom nevidím nic znepokojivého.

    Doufám, že je na dcérce Rootu alespoň trochu smysluplné, když bych článek raději doplnil o informaci, že všechny podstatné funkce GITu lze provozovat i v grafickém rozhraní TortoiseGIT na Windows. To bude blíže „neprogramátor­skému“ vnímání všehomíra. :-)

    Těším se na pokračování.

  7. Stepan

    Jednoduchost neni nejsilnejsi vlastnost Gitu

    Predesilam – git pouzivam v nekolika projektech, je to velmi flexibilni a silny nastroj a nektere jeho vlastnosti si nemuzu vynachvalit. Nicmene rict ze git je jednoduchy je hrube zjednoduseni. Rozhodne je komplikovanejsi nez jeho o neco min flexibilni dvojce Mercurial.

    1. Karel MinaříkAutor příspěvku

      Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

      > Rozhodne je komplikovanejsi nez jeho o neco min flexibilni dvojce Mercurial.

      Můžete takové tvrzení podepřít nějakou argumentací, odkazem, nebo je to spíše subjektivní názor? Nic proti subjektivním názorům!, ty jsou zcela v pořádku, ale je to pak jiné tvrzení.

      Pro srovnání s Mercurialem viz http://whygitisbetterthanx.gitfu.cz/#…

      1. Sid

        Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

        Ako je na tom momentalne Git s Windows? Ked sme sa vo firme rozhodovali pre novy VCS system tak sme zavrhli Git prave pre toto a zvolili Mercurial. Od tej doby som to uz nesledoval takze by ma celkom zaujimalo ako git pokrocil.

        1. Karel MinaříkAutor příspěvku

          Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

          Podle zpráv, které mám – sám Mercurial aktivně pro verzování nepoužívám, jen ho sleduju –, se v jistém bodě vývoj zvrhnul a na Windows se Git stal lépe použitelnější než Mercurial.

          1. Jiří Landsman

            Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

            Na win mám já osobně s gitem takový problém, že neumí moc česky. Tedy né git ale ty nástroje. Když se snažím používat msysgit nebo tortoise tak si například neporadí s mým jménem a mrví pak diakrtitiku. Možná to je nějakým nastavením které jsem nenašel, ale každopádně to celkem odrazuje

            1. uf

              Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

              Me zklamala cestina i u Mercurialu. A u dlouhych jmen adresaru a v cestine. Takze nepisu česky ale cesky.

      2. David Majda

        Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

        1. Index. Tobě se líbí, využíváš ho, zbavuje tě omezení. Pro mě je to zcela zbytečná věc navíc, která především komplikuje a zamlžuje sémantiku mnoha příkazů. (Příklad: Když napíšu git diff, co s čím se bude porovnávat? Working copy s indexem, index s poslední revizí nebo working copy s poslední revizí? Jako nepoučený laik fakt netuším. A pro ty další dvě možnosti si navíc musím najít a pamatovat optiony.)

          Na víc věcech naráz nedělám a nepřestává mě facinovat, jak jsi nadšený z toho, že v Gitu můžeš :-) Já tuhle nemožnost u Mercurialu beru jako pozitivní omezení – tj. stejně jako omezení „dotazovací funkce nemá mít side effecty“, „třídy mají být immutable jak jen to jde“, „v controllerech nemá být logika, ta patří do modelů“. Záležitost programátorské hygieny. Když mi náhodou přijde něco do rozdělané práce, tak použiju v Mercurialu plugin mq, který umí zhruba totéž jako  git stash.

          S indexem mám naopak nepříjemné zkušenosti, kdy se mi několikrát podařilo commitnout neúplnou změnu (něco dodělám, dám git add, pak ještě něco pozměním a zapomenu před commitem refreshnout index). Prostě zbytečná kopie stromu, kterou je nutné v 99% ručně udržovat synchronizovanou s kopií jinou.

        2. Příkazy. Příkazy Gitu a jejich optiony jsou tvořeny „od zdola“, tj. podle toho, co dělají na úrovni implementace. Takže například revertování jednoho souboru se udělá pomocí git checkout file, ale revertování celého stromu přes git reset --hard. V Mercurialu to jde podstatně logičtěji přes hg revert file a hg revert --all. Mám pocit, že podobných příkladů by se našlo víc. Mercurial je zkrátka psán mnohem víc s ohledem na uživatele.
        3. Manuálové stránky/nápověda. Pokud mi ukážeš alespoň jeden příkaz X, kde obsah git help X bude srozumitelnější než hg help Y (kde Y je mercurialový příkaz ekvivalentní gitovému X), máš u mě pivo/drink :-)
        4. Jednoduchost implementace. Mercurial je modulární (složitější/o­krajovější věci jsou řešeny pluginy) a je psán v Pythonu, což je jazyk známý svou srozumitelností. Git je monolitický a je psán ve směsce C, Perlu a shell skriptů, což jsou (možná s výjimkou C) jazyky známé svou nesrozumitelností. Přiznávám ale, že do zdrojáků Gitu jsem nekoukal, takže moje argumentace je tady trochu na vodě.
        5. Přechod ze Subversion. Přeběhlíkovi ze SVN se bude zdát, že je Mercurial jednodušší už kvůli jeho relativní příkazové kompatibilitě.

        Snad to ukazuje, že argumenty pro tvrzení „Mercurial je jednodušší“ se bez problémů dají najít.

        1. Renda

          Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

          Dobrý den,

          vidím, že máte dobrý přehled o Mercurialu. Plánujeme nasazení nějakého verzovacího systému a mám rozhodnout mezi triem Mercurial – Bazaar – Git. Nemáte nějaké srovnání (zkušenosti) Bazaar vs. Mercurial ? Zatím mě z předběžného „mapování terénu“ právě Bazaar zaujal asi nejvíce.

          Hezké svátky

          1. David Majda

            Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

            Bazaar jsem zkoumal cca před rokem a zavrhl ho právě ve prospěch Mercurialu. Pokud si dobře vzpomínám, bylo to kvůli jeho údajné pomalosti (nijak jsem si neověřoval) a nesedělo mi něco v jeho příkazovém rozhraní. Mám neurčitý dojem, že mi na něm vadilo ještě něco víc, ale teď už si nevzpomenu co.

            1. tom

              Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

              Právě v posledním roce se vývojáři bzr na rychlost zaměřili a je to silně znát. Více google, sám referuju jen o subjektivní zkušenosti.

        2. Karel MinaříkAutor příspěvku

          Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

          Ad 1/ Index. Tak ho _nepoužívej_! :) Pokud chceš SVN-like chování, používej git commit --all, a i git diff se bude chovat, jak čekáš. V čem je problém? Vzletná slova o sémantice stranou, index je core koncept Gitu a okolo něj se točí hodně zajímavých workflow, vč. git stash.

          „Pozitivní omezení“ etc – tyhle analogie nechápu. To co uvádíš jsou obecné zásady, nikoliv otázky architektury nebo implementace. Kdybys uvedl analogii typu „nepoužívám Ruby, používám Javu, protože má statické typování, a já prostě statickému typování věřím“, tak bych to chápal a ten názor by byl srozumitelný.

          Ad 2/ Příkazy – ano, z obecného pohledu to platí. (Já osobně si myslím, že co se týče každodenního používání, je to docela jedno, ale to je subjektivní.)

          Ad 3/ Důležitější než „manuálové stránky“ jsou návody, knížky a komunita. Manuál Gitu je záměrně docela hard-core. Proč ne. Někomu to nevadí, komu to vadí, přečte si knížku nebo se podívá na screencast. Každý si chce najít svoji cestu.

          Ad 4/ Implementace – zdroják Gitu je samozřejmě dobrý cirkus. Ale koho z „uživatelů“ to zajímá? :)

          Ad 5/ Ano. Bohužel někdy ke škodě toho přeběhlíka, takže bude používat Git jako „novou verzi SVN“. Ty spousty lidí, kteří používali git commit -all a ještě to psali _do návodů jak na Git_ jsou toho důkazem.

          1. David Majda

            Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

            Ad 1) Ano, nepoužívat index lze, ale stejně na něj pořád nějak narážíš (přinejmenším při čtení dokumentace). Ty „zajímavé workflow“ by mě docela zajímaly, protože hlavní výhoda indexu – „commitování po kouscích“ – mě jaksi nepřesvědčila.

            „Pozitivní omezení“ – podle mě je „nedělám na víc věcech najednou“ zásada stejného typu, jako ty, co jsem vyjmenoval. Něco, co tě sice občas omezuje a přidělává ti práci, ale ty to i tak dodržuješ, protože víš, že je to rozumné a dlouhodobě se ti to vyplatí. V takovou chvíli mi nevadí, že si nějaký kus software dodržování toho či onoho pravidla vynucuje (aspoň pokud nemám potřebu z něj často dělat výjimky).

            Ad 3) Já si vždycky nejraději čtu originální dokumentaci, tutoriály/manuály přímo na webu projektu apod. – a to ze dvou důvodů: jsou obvykle relativně aktuální a především ukazují, jak to s danou věcí myslí sami její autoři. Ale tady je to fakt u každého asi jiné.

            Ad 4) Zdrojáky zajímají takového uživatele, co bude potřebovat Git upravovat (viz Google a jeho výměna storage enginu u Mercurialu), nebo si v něm bude chtít opravit nějakou chybu, nebo ze zdrojáků zjistit, jak něco funguje. Uznávám, to je skoro nikdo.

            Já jsem holt na kvalitu zdrojáků asi trochu přecitlivělý :-)

            1. Karel MinaříkAutor příspěvku

              Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

              Ad 1/ – to je ale stejné s každou subjektivní preferencí. Např.: já používám Ruby, protože je flexibilní a umí method_missing, někdo jiný naopak Ruby nepoužívá, protože je flexibilní a umí  method_missing.

              Ad workflows: o tom jsme se ale všude možně bavili mockrát – index umožňuje (interaktivní) staging commitu, umožňuje práci s git stash --keep-index, udržování „fungující“ verze kódu při divokých experimentech, je na něj navázáno git rebase --interactive (oprava commitu), atd atd atd. Obecně: udržovat „dvojí“ stav working copy.

      3. Lukas

        Re: Jednoduchost neni nejsilnejsi vlastnost Gitu

        http://code.google.com/…DVCSAnalysis

        Analysis of Git and Mercurial, done in summer 2008, when we first began scoping work for DVCS support in Google Code.

        Vynatek ze Summary:

        „In terms of features, Git is more powerful, but this tends to be offset by it being more complicated to use.“

  8. tom

    slozky

    Nepracuje GIT spis s adresari? Adresar je prostredek operacniho systemu, do ktereho muzete udelat chdir a pod. Slozka je pojem z desktopoveho prostredi a nemusi vzdy odpovidat adresari. Prikladem budiz treba prace s archivy v KDE.

  9. Pavel Šimek

    commituji přání hezkých Vánoc

    Konečně článek, kde se „commituje“ místo aby člověk musel tápat, co to je ten svobodný software plný běhových prostředí a stylových předpisů. ;-) Hezké svátky, Karle! :)

  10. D3T

    Konzerva

    Ja sem taky konzervativni. Pouzivam SVN, zatim k plne spokojenosti. Tolik predstaveni. No a ted muj komentar: Souhlasim s tim, ze vsechno se da udelat v ASM, proto nema smysl rikat, ze „v tomhle to jde taky“. Na druhou stranu, nevidim jako !jednoznacne! plus, kdyz je neco tak flexibilni, ze me to nenuti pracovat nejakym konkretnejsim (a potencialne dobrym) zpusobem. Nechci tvrdit, ze plati opak (tj. ze nejlepsi je zadna svoboda), ale argument s flexibilitou uplne neberu. Priklady – mam radsi Python nez Perl, protoze Perl je jazyk bez stylu. Neumim se rozhodnout mezi C++ a Javou, prestoze C++ nevynucuje zadny styl programovani, Java pomerne striktni, oba maji sve vyhody. Proste argument flexibility v souboji Git-SVN nejak neberu. Dale argument s jednoduchosti: kdyz autor napise „ty silenosti se svn admin a svn import“, mam chut clanek zmackat a zahodit, to je jak kdyz reklama tvrdi, ze „tenhle fotak je jednodussi, protoze na tohle ma specialni tlacitko, kdezto u konkurence je potreba vybrat top-level polozku v menu“. Samorejme zalezi na tom, jak casto je funkcnost potreba. Zakladani repository neberu jako tu nejcastejsi cinnost… Dobra poznamka s tim, ze „nekdo na to ma skript“ nebo whatever, ale kdyz se vezmu v uvahu, kdo pouziva verzovaci system (BFU z ucetniho oddeleni tezko), tak mi „jednoduchost“ prijde trosku min vyznamna. Podobne s tim, ze do SVN se neco commitne a uz je to v haji, pokud v tom byla chyba, kdezto „u Gitu to tak neni“. Ja teda Gitu nerozumim (a proto sem si clanek precet), ale kazdopadne, abych svoje vyplody mohl s nekym sdilet, musim je commitnout do sdileneho uloziste. A kdyz je tam commitnu, tak „uz je to v haji“, protoze zadna nasledna oprava nevrati ty uz stazene kopie meho vytvoru. Tudiz mi tahle vlastnost Gitu prijde jako „feature by obscurity“, proste aby se neco stalo, musim to udelat dvakrat, az pak se to opravdu stane. Nebylo by teda lepsi udelat to 10×, aby si byl system opravdu jist, ze uzivatel uz to mysli vazne?

    Muj komentar asi zni jako plamenna obhajoba SVN, ale to ne, ja o Gitu vim kulovy, proto ho tezko muzu kritizovat a favorizovat oproti nemu jiny system. Ja jen nesouhlasim se stylem, jakym je napsan tento clanek. Ale zaroven bych chtel rict, ze mi ten clanek prijde v zasade dobry, jen moc „militantni“ ve prospech Gitu. Tak jsem to „militantne“ zkritizoval:))

    1. Karel MinaříkAutor příspěvku

      Re: Konzerva

      Díky za názor, taková pořádná kritika se mi líbí.

      Nechci v žádném případě pokračovat v „militantní“ argumentaci. Nicméně, mám pocit, že některé z věcí, které popisujete, jsou ovlivněny právě delší prací s SVN – jak např. naznačuje na svém příkladu i jeden z diskutujících vý­še.

      Např. zakládání repository. Pro mně osobně je to jedna z velmi častých činností, protože jsem si díky Gitu zvyknul verzovat/zálo­hovat/atd i relativně nicotné věci. (Plus používám Git jako „deployment mechanismus“, skrze remote repo a hooky.) Takže snadnost _právě_ této operace je pro mne zásadní, a dle debat s kolegy má podobný názor hodně ostatních.

      Dále. Je běžné, že verzovací systém používají i ne-vývojáři, ne třeba BFU z účetního oddělení, ale BFU který/á umí (na rozdíl od vývojářů) anglicky/němec­ky/španělsky/rus­ky/… – takže _jednoduchost_ (ať už znamená cokoliv) důležitá je.

      > abych svoje vyplody mohl s nekym sdilet, musim je commitnout do sdileneho uloziste.

      Nemusíte. Pokud budeme spolu na jedné síti a uvidíme na sebe, můžete si vy stahovat ode mne a já od vás, bez sdíleného úložiště. To „rozdělení“ commit x push přináší mnoho výhod navíc, pokusím se je srozumitelně popsat v příslušné části.

      1. D3T

        Re: Konzerva

        Dobra, je mozne, ze na spoustu veci jsem z prace s SVN zvykly delat. Pak jsou tedy na miste dve otazky:
        1) Je pro mne, jako stavajiciho uzivatele SVN, ktery je na praci s nim zvykly a nema s nim zadne podstatne problemy, prinosne ten system zmenit? O tom by zrejme mel byt Vas serial a pak bych ze sveho pohledu spis myslel, ze svym pristupem (vymezovat se proti SVN) sveho cile ve velke mire nedosahnete, protoze to vymezovani se proti SVN ty zabehle uzivatele SVN spis odradi od cteni. Zabere to asi na lidi, kteri praci s SVN proklinaji, ale takovi uz se zrejme davno po necem aktivne poohledli.
        2) Co s novymi uzivateli nenavyklymi (nejak zasadne) na zadny verzovaci system? Vas serial pro ne neni moc vhodny, protoze SVN zas tak neznaji a tudiz nebudou presne rozumet, proc by si radsi meli zvolit Git. To ovsem neznamena, ze nekteri z nich se pod vlivem Vaseho clanku nedostanou do stavu, ze „SVN je shit a Git je buh“, ale kvalifikovane rozhodnuti to spis nebude. Nechci to nejak zasadne tvrdit, jiste ze spousta informaci z Vaseho clanku je relevantnich a uzitecnych a prave porovnani systemu je jednim z vhodnych zpusobem, jak nekomu pomoct se rozhodnout. Pokud se bude jednat o relativne ne-technickeho uzivatele, pak souhlasim, ze jednoduchost je zasadni, ovsem rekl bych, ze TortoiseSVN to dokonale splni (protoze BFU+cmdline proste dohromady nejde). Navic pak (se mi zda) tak uplne presne neplati Vas dalsi argument s tim commit x push – ne-technicky uzivatel asi nebude sdilet data nejak ve stylu peer-to-peer a navic bych rekl, ze prave u tech ne-technickych uzivatelu bude prilisna flexibilita systemu spis na skodu – je lepsi, kdyz je takovy uzivatel tlacen alespon trochu spravnym smerem. No a technicky uzivatel si napise ten skript a je mu treba relativne jedno, jakym zpusobem se nauci pracovat, jestli vytvaret hodne repositories s gitem nebo malo se svym skriptem nad SVN.

        Cili abych to shrnul. Pockam si na dalsi dily, abych videl, jaka bude odpoved na otazku 1. V otazce 2 se pak, zda se mi, zraci to (co jsem uz zminoval v prvnim komentari), ze prilisna flexibilita muze byt na skodu (na to jste nereagoval), tudiz ze se nejedna o absolutni argument, a taky to, ze je potreba rozlisit argumenty pro ruzne typy uzivatelu. Neni mozny nasypat tu deset argumentu, z nichz pet plati pro jeden typ uzivatelu (ale pro jiny typ uzivatelu by vlastne byl lepsi presny opak) a dalsich pet argumentu pro tento typ uzivatelu neplati, ale to nevadi, protoze plati pro presne opacny typ uzivatelu a tudiz to tam muzeme napsat obecne…

        Nicmene podle poctu komentaru bych rekl, ze Vas clanek splnil svuj ucel:) Debata probiha, preju hodne sil do dalsich dilu!

        1. Karel MinaříkAutor příspěvku

          Re: Konzerva

          Díky!

          Ad 1/ – stavajiciho uzivatele SVN … O tom by zrejme mel byt Vas serial …

          Jak lze zvláště o Vánocích dobře pozorovat, zklamání je funkce očekávání :) Moje články by měly přinést reálné, z-prstu-nevycucané důvody proč: a) pořádně se podívat na to co umí Git (a potažmo ostatní DVCS) a začít využívat jeho výhody, viz úvod článku.

          Když se zamyslíme nad potenciálními čtenáři, dostaneme různé skupiny:

          1. „Používám SVN a nic jiného nechci, protože nemám se SVN žádné problémy“

          Tady má smysl ukázat, že Git (a ostatní DCVS, uff ta politická korektnost je náročná na klávesnici) přináší zjednodušení některých operací nebo konceptů (git init, ignores) a nic přitom „neubírá“. Proto má smysl se podívat na na Git (a nezapomínejme na ostatní DVCS!! :), protože mohu zjistit, že ani s ním/nimi nebudu mít žádné problémy. Hodně lidí teď žije v mírné schizofrenii, že staré projekty nechává v SVN, a nové zakládá v Gitu (nebo v některém z ostatních DVCS!)

          Tahle skupina má varianty „používám SVN, protože nic jiného pořádně neznám“, „používám SVN, protože se nechci učit nic nového“, „používám SVN, protože ho máme v práci“, atd. Já chci upozornit na to, že jsou tu i jiné alternativy.

          2. „Používám SVN, protože na něj mám navázáno spoustu infrastruktury“

          Tohle je např. mimo záběr „běžného uživatele“. Build proces, ticket system, oprávnění, sofistikované hooky, atd atd navázané na SVN je samozřejmě problém jen tak zbůhdarma migrovat na jiný systém, jedno jaký. Tady musím být přesvědčen, že mi migrace přinese nějakou hmatatelnou výhodu.

          Nezapomínejme přitom, že SVN ve své době přišlo také jako „vyzyvatel“, jako „CVS killer“ – oficiální přízvisko je přece „CVS done right“.

          Samozřejmě, že někoho, kdo s láskou používá SVN a má ho skrz naskrz probádané, může nezakrytá a otevřená argumentace typu „Git je _v tomhle_ lepší“ strašlivě nadzvednout. (Git to dostal do vínku: viz video s Linusem Torvaldsem v úvodu.) A jak je vidět v komentářích, platí to i pro „zastánce“ ostatních (D)VCS. Ale já vyměním risk několika naštvaných uživatelů SVN za to, že se několik jiných podívá na alternativní koncepty – např. na to, jak Git řeší branch/merge v dalším článku.

          Ad 2/ – Co s novymi uzivateli nenavyklymi (nejak zasadne) na zadny verzovaci system?

          Tady je samozřejmě _jedno_ co budou používat, hlavně když budou verzovat a nebude to pomocí názvů typu web_kofola_design_main2_FINAL_FINAL2.psd. Tím pádem můžou klidně používat Git a když jim někdo napíše hezký návod a udělá dvě hodinky ukázku a školení, tak na žádné komplikace ani nenarazí. Prostě pojedou podle nějakého <ol>.

          > Pokud se bude jednat o relativne ne-technickeho uzivatele, pak souhlasim, ze jednoduchost je zasadni, ovsem rekl bych, ze TortoiseSVN to dokonale splni

          Ano, ale. Mám např. zkušenost, kdy jsem kolegovi kodérovi ukázal, jak v Gitu pracovat s branchemi, tzn. udělat si svoji privátní branch, něco si tam patlat a teprve když to má hotovo, sloučit s ostatními a poslat do master/deploy branche. Nejdřív to samozřejmě šlo ztuha, ale nedal se, a pak twitteroval štěstím z toho, že si něco někde vskrytu může ladit a má to verzované.

          Flexibilitu Git lze snadno skrýt nebo obejít. I když např. i ne-techničtí uživatelé tohoto typu podle mých zkušeností _okamžitě_ pochopí k čemu je dobrý index (na který v jiném komentáři nadává David Majda) – okamžitě pochopí, „aha, super, takže tady mu řeknu že main.css a homepage.css chci uložit do revize, ale print.css tam ještě nedávej, ten ještě potom doladím“.

          Jednoznačnou výhodou je ale to, že _kdyby mi na tom záleželo_, můžu po ne-technických uživatelích provádět v historii opravy: když si nenastavili dobře Git author/email a commitují jako fananek32@seznam.cz, když pošlou 10 commitů týkajících se jedné věci (protože ještě neznají git commit –amend), atd.

          Shrnuto a podtrženo: Git přináší nějaké další a zajímavé možnosti, jak využívat VCS, případně přináší zjednodušení/vy­lepšení starých konceptů jako je branch/merge, jak píšu v druhém článku. Rozhodně to není tak, že „a teď honem všichni odinstalovat SVN a nainstalovat Git“. Ale např. „aha, když můžu takhle snadno zřídit repo, to bych si mohl verzovat i nějaké nicotnosti“, nebo „aha, ty topic branche vypadají jako úžasná věc, v SVN děláme branche jen když vyloženě musíme, to bych měl zkusit“, to je to, co jsem chtěl říct.

  11. lenin.power

    git je k nicemu

    1. neumi versionovat adresare
    2. CLI je priserne komplikovany
    3. ukladat vice vetvi do jednoho adresare je pitomost
    4. neni k tomu poradny web viewer na revize

    dobry priklad slozitosti gitu bylo kdyz jsem shanel nekoho kdo mi rekne jak vycheckoutovat poslednich 5 revizi z 1 branche aniz bych musel delat git clone na cele repo. Na #git nebyl schopen nikdo poradit.

    1. Karel MinaříkAutor příspěvku

      Re: git je k nicemu

      Nechci vám brát spravedlivé rozhořčení, jen k tomuto:

      > 1. neumi versionovat adresare

      Git kašle na adresáře, pokud v nich něco není. Automaticky tedy neverzuje prázdné adresáře. Typický workaround je proto $ touch tmp/.gitignore a je po problému.

      To jen aby si to zas nepřečetl nějaký kolega, podobně jako s tím .svnignore a nebyl pak chudák někde za blbce.

      (A jen úplně na okraj. 3: ale v Gitu nejsou větve adresáře. V Gitu jsou větve odkazy na SHA commitu/snapshotu. Přepínání mezi větvemi přepíná mezi těmi snapshoty. 4: Tož, máme a) Gitweb, b) Gitorious, zadarmo (open-source) nebo za peníze Github a pak ještě spoustu dalších projektů. Kór u toho Githubu nevím, co by mohlo být „pořádnější“ :)

    2. herne the hunter

      Re: git je k nicemu

      nechce se mi verit, ze by na #git nevedeli o parametru --depth pro clone. je teda fakt, ze takto vzniknuvsi klon ma urcita omezeni, ktera vam mozna vadila…

  12. fallanck

    Ke Gitu

    Hezký agitační článek :-), díky za něj.

    Ad konzervativizmus: taky jsem si toho všiml, že někteří lidi z IT fochu jsou někdy až ultrakonzervativní, což v prostředí, kde změn je hodně a přicházejí rychle, je až zarážející. Jde o zřejmě o obranný mechanizmus, kterou používá určitý typ lidí (podle psychologů to bývají hlavně prvorození, ale kdo ví…).

    A právě tyto lidi jsou někdy až nepřiměřeně bojovní, když jim jde o to, aby si svoje konzervativní názory „ubránili“. Protože ve většině případů je svn současně nejčastěji používaný verzovací systém, zmínění konzervativisti se projevují jeho zuřivou obhajobou.
    Zřejmě i tento jev vedl k tomu, že článek je psán v duchu co všechno je v gitu lepší než v svn.

    Já sám nejsem softverový vývojář, nicméně verzovací systémy při své práce používám, (zkoušel jsem svn, bazaar, mercurial a teď „jedu“ na gitu) a práve proto bych uvítal, kdyby autor napsal o možnostech použití gitu pro lidi, kteří většinou neverzují textové soubory – díky.

  13. David Grudl

    index area

    V článku je vyzdvihovaná index area, které umožňuje nejprve soubory přidat přes git add a teprve poté komitovat přes git commit. Jak se tohle liší od jiných verzovacích systémů, např. od svn add + svn commit?

    1. Karel MinaříkAutor příspěvku

      Re: index area

      > Jak se [staging area Gitu] liší od jiných verzovacích systémů, např. od svn add + svn commit?

      Zásadně. svn add „jen“ přidává soubory, které chci verzovat. Při svn commit jsou pak ukládány změny v těchto souborech, resp. mohu přes svn commit myfile.txt uložit změny jen v některých z nich.

      git add „při prvním použití“ rovněž přidává soubory, které chci verzovat. git commit pak ukládá změny, které jsou „připraveny ke commitu“ ve staging area. Do staging area přidávám změny právě pomocí „dalšího použití“ git add:

      • git add . # Pridej vse
      • git add myfile.txt # Pridej jen jeden soubor
      • git add myfile.txt mydir my-other-dir/*.js # Pridej soubor, cely adresar a pouze javascript soubory z dalsiho adresare
      • git add -p my-big-file.txt # Otevri interaktivni konzoli pro pridavani jen nekterych zmen v souboru

      Samozřejmě, tyto operace mohu provádět také pomocí GUI klientů.

      Staging area mi umožnuje průběžně a interaktivně připravovat obsah, který chci commitovat. Prohlížet si ho mohu pomocí gi diff --staged. Jakmile jsem spokojen, příkazem git commit tento připravený obsah uložím jako revizi do repositáře.

      Mohu pomocí přepínače --all, resp. -a, nebo uvedením cest jako parametru příkazu git commit staging area obcházet, připravím se ale o jemnou kontrolu nad obsahem commitu a mnoho dalších výhod, které mi přináší. Jedna z nich je např. git stash --keep-index.

      1. Borek Bernard

        Re: index area

        Staging area je určitě zajímavý koncept, jen si z popisu v článku nejsem jistý, jak ověřím, že jsou „nastagované“ změny v pořádku, tj. že projekt v tomto stavu půjde zkompilovat, že projdou testy apod. Jak se tohle v gitu řeší? Nebo někdo commitne podmnožinu změn jen na základě přesvědčení, že na nic nezapomněl?

        Hodně tohle vynikne v kompilovaných jazycích – pokud např. ve Flexu zapomenu do staging area dát obrazek.jpg, který staticky referencuju ve zdrojáku, kompilátor selže, ačkoliv jsem v ActionScriptu žádnou chybu neudělal. Před commitem ze stage bych proto rád, aby za mě podobné věci zkontroloval kompilátor.

        1. Karel MinaříkAutor příspěvku

          Re: index area

          > … jak ověřím, že jsou „nastagované“ změny v pořádku …

          Na to slouží právě příkaz git stash save --keep-index, který ponechá změny připravené ke commitu, a ty ostatní dočasně odloží.

          V takové situaci mohu spustit testy, kompilaci, etc etc, pokud vše projde, commit uložím, a pomocí git stash pop nebo git stash apply si dočasně odložené změny zase vrátím a pokračuju v práci.

          Při test-driven (nebo obecně jakkoliv test-based) development je staging area v tomto pojetí a využití dost velký nářez. Já bych se bez ní již neobešel.

          1. Borek Bernard

            Re: index area

            Díky, to zní dobře.

            Mimochodem, myslím, že VCS, které nemají koncept staging area, používají k něčemu podobnému tzv. shelving, tj. dočasné odložení změn ve working copy „někam“ a jejich snadné vrácení poté, co mám za sebou např. rychlý bug fix. Staging area bude patrně mocnější, ale pro hlavní scénáře by to možná mohlo stačit (budu muset někdy zkusit).

      2. Karel MinaříkAutor příspěvku

        Re: index area

        > připravím se ale o jemnou kontrolu nad obsahem commitu a mnoho dalších výhod, které mi přináší.

        Zapomněl jsem dodat, že velká výhoda staging area je např. při využívání workflow s git commit --amend. O ní se ale bude mluvit až v přespříštím článku.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3139