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.
Titulek
Diky za clanek, pekne.
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.
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.
Re: konzervatismus
U mne je to přesně naopak. CVS bylo peklíčko a svn celkem v poho.
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/autorizaci 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í.
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ý?
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ů.
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.
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.
.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.
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?
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.
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. :)
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.
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.
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?
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.
SVN v
Prosim autora, aby se tolik neopiral do SVN. Zbytecne to schazuje mozna dobrou serii.
l
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? :)
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.
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, …
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?
Re: SVN v
O .svnignore nevim, ale urcite lze pouzit global-ignores v ~/.subversion/config
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á.)Mercurial
Počkej, až se začnou ptát: „Proč ne Mercurial?“ :-)
Re: Mercurial
Na to se líp odpovídá .)
Re: Mercurial
Proc tedy ne Mercurial?
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 ?
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é.
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 :-)
Re: Mercurial
Na to není odpověď. Ale dá se o tom hezky hádat, pokud nemáš teď při „dlouhých zimních večerech“, co dělat :-) viz Verzovací systémy – svn, git, hg – svatá válka?
Re: Mercurial
Nebo „proč ne bzr?“
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.)
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.
Re: SVN v
Děkuji. Výborný přehled.
–karmi
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?
Re: SVN v
Ad rychlost: http://whygitisbetterthanx.gitfu.cz/#…
Ad částečné commity: ano, něco _úplně_ jiného, viz
git add --patchv článku (odstavec nad posledním obrázkem)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.
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).
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.
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í.
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.
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átorskému“ vnímání všehomíra. :-)
Těším se na pokračování.
tohle vypadá dobře
Pominu že autor v jednom titulku zmiňuje idioty a java programátory, ale ten postup vypadá, že snadně.
http://trak3r.blogspot.com/…elopers.html
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.
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/#…
Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
Pro pobaveni :-)
http://whyhgisbetterthanx.com/
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.
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.
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
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.
Re: Jednoduchost neni nejsilnejsi vlastnost Gitu
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.git checkout file, ale revertování celého stromu přesgit reset --hard. V Mercurialu to jde podstatně logičtěji přeshg revert fileahg 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.git help Xbude srozumitelnější nežhg help Y(kde Y je mercurialový příkaz ekvivalentní gitovému X), máš u mě pivo/drink :-)Snad to ukazuje, že argumenty pro tvrzení „Mercurial je jednodušší“ se bez problémů dají najít.
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
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.
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.
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 igit diffse 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 -alla ještě to psali _do návodů jak na Git_ jsou toho důkazem.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ý :-)
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ánogit rebase --interactive(oprava commitu), atd atd atd. Obecně: udržovat „dvojí“ stav working copy.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.“
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.
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! :)
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:))
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álohovat/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ěmecky/španělsky/rusky/… – 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.
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!
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í/vylepš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.
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.
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/.gitignorea 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ší“ :)
Re: git je k nicemu
nechce se mi verit, ze by na #git nevedeli o parametru
--depthpro clone. je teda fakt, ze takto vzniknuvsi klon ma urcita omezeni, ktera vam mozna vadila…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.
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?
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řisvn commitjsou pak ukládány změny v těchto souborech, resp. mohu přessvn commit myfile.txtulož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 commitpak 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 vsegit add myfile.txt# Pridej jen jeden souborgit add myfile.txt mydir my-other-dir/*.js# Pridej soubor, cely adresar a pouze javascript soubory z dalsiho adresaregit add -p my-big-file.txt# Otevri interaktivni konzoli pro pridavani jen nekterych zmen v souboruSamozř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říkazemgit committento 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říkazugit commitstaging 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.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.
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 popnebogit stash applysi 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.
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).
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.