Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Ondřej Novák 30. 07. 2014, 13:19:12
-
Poslední dobou jsem obklopen lidmi, kteří "jedou na gitu" doslova to tak cítím, protože se kolikrát chovají jak ujetý jako by jeli v nějakých drogách. Git je úžasný, git je světový trend, zapomeň na cokoliv jiného, všechno bude git
Jsem šťastný uživatel SVN pro jeho jednoduchost. Ke své práci potřebuji commit, update a občas nějaký to branch a merge. Bohužel jsem už několikrát narazil na nutnost s gitem pracovat a vždycky jsem se ztratil v přehršli příkazů v příkazové řádce a možnostech, o kterých pochybuju, že někdy využiju (momentálně zápasim s chromiem, který má ještě nad gitem nějakou vlastní šílenou nadstavbu - proč asi?)
Předem upozorňuji, že nechci a v budoucnu neplánuji pracovat na distribuovaných repozitářech a spolupracovat na opensource projektech. Takže rovnou vynechte tuhle "výhodu".
-
Používej Perforce :-P
-
Precitaj si toto http://stackoverflow.com/questions/871/why-is-git-better-than-subversion (http://stackoverflow.com/questions/871/why-is-git-better-than-subversion) (myslim aj ostatne reakcie) a sprav si vlastny nazor. :)
Vzdy lepsie, ako tu zacinat flame. 8)
-
Git má mnohem lepší merge conflict resolver pro případy, kdy se rozejde tvoje a remote branch, a má mnohem rychlejší branchování. Těch příkazů je hodně právě kvůli problémům v distribuovaném verzování (např. možnost spojení historií lokální a remote branche, podpora digitálních podpisů, řízené přetahování commitů, práce na tisících paralelních branchí ap.). Pokud na něčem děláš sám, tak ani jedno nevyužiješ a je pak zbytečné opouštět SVN, pokud jsi na něj zvyklý.
-
Git má mnohem lepší merge conflict resolver pro případy, kdy se rozejde tvoje a remote branch, a má mnohem rychlejší branchování. Těch příkazů je hodně právě kvůli problémům v distribuovaném verzování (např. možnost spojení historií lokální a remote branche, podpora digitálních podpisů, řízené přetahování commitů, práce na tisících paralelních branchí ap.). Pokud na něčem děláš sám, tak ani jedno nevyužiješ a je pak zbytečné opouštět SVN, pokud jsi na něj zvyklý.
Tady bych se možná zastavil, protože z mého pohledu práce na tisících paralelních branchí a velkých projektech obecně není podle mě dobrý styl. Konečně podívej se na zdrojáky webkit/chromium. To je slepenec bez vnitřní organizace, ve kterém se prakticky nedá vyznat, na různých místech se střídají programátorské styly, někde dokonce i několik na jedné řádce. Git možná vede k takovým možnostem, ale je to opravdu správný způsob vývoje? z mého pohledu má git spoustu možností, které bych spíš zakázal pro vývoj v menším teamu.
-
Tady bych se možná zastavil, protože z mého pohledu práce na tisících paralelních branchí a velkých projektech obecně není podle mě dobrý styl. Konečně podívej se na zdrojáky webkit/chromium. To je slepenec bez vnitřní organizace, ve kterém se prakticky nedá vyznat, na různých místech se střídají programátorské styly, někde dokonce i několik na jedné řádce. Git možná vede k takovým možnostem, ale je to opravdu správný způsob vývoje? z mého pohledu má git spoustu možností, které bych spíš zakázal pro vývoj v menším teamu.
Za to ale Git nemoze. To je vecou code review a workflow. Rovnaky bordel spravis podla mna aj pomocou SVN.
To je to iste, ako nadavat na kombinacky, ze poohybali klince, ktore nimi nejaky "odbornik" zatlkal.
-
z mého pohledu práce na tisících paralelních branchí a velkých projektech obecně není podle mě dobrý styl
Tisíce paralelních větví umožňují například mít repository s kódem, který lze vždy přeložit, aniž by všichni museli mít nejaktuálnější verze všeho. Prostě bude několik větví, každá z nich samostatně půjde přeložit, ale např. ve větvi s optimalizací JavaScriptu budu mít původní vykreslovací jádro a nemusí mne trápit, že ve vedlejší větvi kolegové zrovna optimalizují vykreslovací jádro a ne všechny jejich pokusy jsou stabilní a vhodné pro situace, kdy mi má prohlížeč běžet déle než jednu sekundu.
Další možností je třeba to, že na jedné části kódu může pracovat víc lidí, a nemusí si upravené zdrojáky posílat e-mailem nebo předáváním svých částí zaplevelovat hlavní vývojovou větev.
Konečně podívej se na zdrojáky webkit/chromium. To je slepenec bez vnitřní organizace, ve kterém se prakticky nedá vyznat, na různých místech se střídají programátorské styly, někde dokonce i několik na jedné řádce.
To s verzovacím systémem nemá vůbec nic společného.
Pokud verzovací systém používáte jenom sám, viděl bych dvě výhody použití distribuovaného VCS oproti SVN: za prvé lepší podpora větví a řešení konfliktů, za druhé to, že celé repository máte v jednom adresáři a nepotřebujete žádný server.
-
Precti si tohle: http://hginit.com/00.html
Je to velice dobre vysvetleni rozdilu distribuovany VCS vs. centralizovany VCS, i kdyz je to o Mercurial.
-
GIT není složitější používat než SVN. Není třeba používat komplikované příkazy. Commit, checkout, branch, merge a tak 3 další člověk používá pořád a mají své účely, žádný zmatek/složitost nehrozí. Já nepoužívám SVN když nejsem donucený, takže nemůžu moc porovnávat. Kvůli tomuhle dva projekty co znám přešly na GIT:
1. možnost commitovat offline a dělat vlastně cokoliv offline (úprava SW robota v terénu);
2. možnost využívat větve, commity atd. na lokálu, jednoduše a rychle (pro malé úpravy, vlastní potřebu aj.)
3. úžasná rychlost _všeho_ (oproti SVN);
Možná některé důvody pramení pouze z neznalosti správců projektu, nevím :-) SVN mi přijde jako že je jen taková lehká nadstavba nad ručním kopírováním složek, kdežto GIT posouvá abstrakci výš. Práce s ním je mnohem čistší a působí robustněji.
-
z mého pohledu práce na tisících paralelních branchí a velkých projektech obecně není podle mě dobrý styl
Tisíce paralelních větví umožňují například mít repository s kódem, který lze vždy přeložit, aniž by všichni museli mít nejaktuálnější verze všeho. Prostě bude několik větví, každá z nich samostatně půjde přeložit, ale např. ve větvi s optimalizací JavaScriptu budu mít původní vykreslovací jádro a nemusí mne trápit, že ve vedlejší větvi kolegové zrovna optimalizují vykreslovací jádro a ne všechny jejich pokusy jsou stabilní a vhodné pro situace, kdy mi má prohlížeč běžet déle než jednu sekundu.
Další možností je třeba to, že na jedné části kódu může pracovat víc lidí, a nemusí si upravené zdrojáky posílat e-mailem nebo předáváním svých částí zaplevelovat hlavní vývojovou větev.
Ale to SVN umi taky a neni to problem. Jde jen o to, ze ty vetve jsou verejne a dostupne vsem (takze se neztrati, kdyz kolega jednoho dne neprijde do prace a nikdo dalsi nebude mit heslo k jeho PC)
Hodně často narážím u evangelistů GITu na základní neznalosti práce v SVN. Je to úsměvné.
Konečně podívej se na zdrojáky webkit/chromium. To je slepenec bez vnitřní organizace, ve kterém se prakticky nedá vyznat, na různých místech se střídají programátorské styly, někde dokonce i několik na jedné řádce.
To s verzovacím systémem nemá vůbec nic společného.
No spíš to souvisí s myšlenkou distribuovaného vývoje. Nikdy jsem tu myšlenku moc nepobral. To už víc podporuju myšlenku centralizovaných ostrovních problémů, které se vyvýjejí separátně. Shodou okolností to vychází vstříct TDD.
Pokud verzovací systém používáte jenom sám, viděl bych dvě výhody použití distribuovaného VCS oproti SVN: za prvé lepší podpora větví a řešení konfliktů, za druhé to, že celé repository máte v jednom adresáři a nepotřebujete žádný server.
SVN umí být taky v jednom adresři, ale spatřuju jeho hlavní výhodu oddělené WC od repozitáře. Dokonce dneska už ani neplatí to, že by adresář .svn byl v každém podadresáři, takže to oddělení je úplné (i od metadat). U soliterního vývoje mívám repozitář na jiném disku než je WC...proč asi? Ale spíš vyvíjím přes vlastní server, umožňuje mi to na různých zařízeních mít okamžite přístup k aktuální verzi zdrojáků (jasně, taky mám dropbox, ale tohle je víc pod kontrolou)
Velké projekty řeším přes externals a přes schopnost SVN mergovat napříč repozitáři (jo, drtivá většina uživatelů to neví, že to jde - tohle by možná bylo dobré podpořit, třeba nějakým automatizovaným nástrojem)
-
Moje zkusenosti:
SVN:
+ snadno sem rozjel server na Linuxu a bezi bezproblemove
+ snadno sem se se SVN naucil
+ dobra podpora ve windows (dobre fungujici tortoiseSVN)
+ dobra podpora pro VisualStudio snad od 2005 (ankhSvn)
+ intuitivni gui ve widlo pruzkumniku - co je cervene, tam je zmena, to bych mel commitnout, aby to videli ostatni
+ par verzi zpet podle me normalne fungujici branch a merge branchu/trunku, vytvoritelny snadno na par kliku pres tortoise
- nema lokalni commity
GIT:
+ ma lokalni commity
- neni schopen rict zadna kloudna chybova hlaseni, 10 minut provadi pull aniz by rekl, ze k serveru se neda pripojit
- server sem rozjizdel asi 3 hodiny (gitblit), protoze maji v dokumentaci odkaz na uplne starou verzi
- naprosto divne ovladani konzoly
- neexistence pluginu pro Visual Studio (ty, ktere jsou uplne k nicemu, nepocitam), snad 2013 pry ma podporu z vyroby, nezkousel jsem
- tortoise Git sice docela jede, ale take neni schopny normalne reagovat na chybove stavy (asi proto, ze git samotny je toho neschopen, viz druhy bod)
- gui rozsireni tortoisu pro pruzkumnika neni tak intuitivni jako pro svn. co je zelene, je commitle, ale nikde neni videt, ze od posledniho commitu sem neudelal push, takze kdyz mam projekt z X repozitaru, tak pro sichr pushuju jak debil X repozitaru, abych mel jistotu, ze se to dostane ostatnim (ano, jiste existuji nejaka super kouzla, ale ja chci jen rychle dostat veci na server)
- chyby v samotnem gitu, kdy behem pushe git zamrzne a 30 minut je tuhy a pomuze jen zabit. known bug, zkuste verzi X.y, tam to jeste nedelalo nebo a.b tam uz to nedela. verze a.B se vam pobije s nastrojem git slave, ktery jede jen s verzi q.w atd.
Git je jiste mocny nastroj, o tom neni pochyb. Ale na to, jak je to udajne super vec a vsichni ji uzivaji atd, tak mi prijde jako docela nedomrdly. Podpurne nastroje jsou take nedotazene. Sami lide, kteri s gitem delaji treba 5 let, maji obcas problem s nim nektere veci vybojovat.
Znam velke a slavne firmy, ktere jedou na svn a ziji v pohode a problem nemaji. Ovsem lokalni commity se mi libi, to ne ze ne :-)
Opravdu neni mim cilem tvrdit, ze git je smejd. Rad si necham poradit nejake figle. Ovsem toho, co se kolem gitu clovek musi naucit je tak 5x tolik, co potrebuje znat pro svn.
-
1. možnost commitovat offline a dělat vlastně cokoliv offline (úprava SW robota v terénu);
Nikdy jsem nic takového nepotřeboval a nevidím jediné využití. Pro historii používám Eclipse Local History. A bez toho není problém pustit skript na generování patchů oproti Base a ty ukládat někam bokem (vyřeší se tím funkce jak stach tak commit),
2. možnost využívat větve, commity atd. na lokálu, jednoduše a rychle (pro malé úpravy, vlastní potřebu aj.)
WC je vždycky bráno jako větev vůči stavu na serveru. Vytvářet větve ve větvi mi nepřišlo nikdy zajímavé. V rámci SVN si mohu vytvořit víc WC a pak každou považuju za větev. Pokud ukončím vývoj ve větvi, je nutné to commitnout na sevrer, protože hrozí, že to zapomenu (což je větší průser, než tam commitnout blbost)
3. úžasná rychlost _všeho_ (oproti SVN);
Nikdy jsem neměl problém s rychlostí operací. Rychlost sítě byla vždycky víc limitující faktor (práce přes mobilní připojení) A rychlost překladu ještě víc limitující. Tohle mi příjde jako virtuální problém.
-
Osobně používám Mercurial (má mj. logičtější ovládání než Git... ale tenhle flame sem teď nechci zatahovat), nicméně ty výhody jsou společné pro distribuované verzovací systémy obecně.
Velkou výhodou je možnost pracovat offline, můžeš dělat commity, procházet historii nebo zkoumat starší verze... klidně i na pomalé nebo padající VPNce nebo úplně bez připojení. Více najdeš v seriálu Distribuované verzovací systémy (http://www.abclinuxu.cz/serialy/distribuovane-verzovaci-systemy)
-
1. možnost commitovat offline a dělat vlastně cokoliv offline (úprava SW robota v terénu);
Nikdy jsem nic takového nepotřeboval a nevidím jediné využití. Pro historii používám Eclipse Local History. A bez toho není problém pustit skript na generování patchů oproti Base a ty ukládat někam bokem (vyřeší se tím funkce jak stach tak commit),
Jo, tak tohle se mi uz hodilo.
Tri tydny u zakaznika na miste, delam zmeny. Kolegove zatim v materske firme vyvijeji dal.
Po navratu chci moje zmeny i s historii mergovat do hlavni verze, na ktere zatim kolegove pracovali.
Se Subversion docela narez.
Resil jsem to pomoci hgSubversion (Mercurial jako Subversion-Klient).
-
1. možnost commitovat offline a dělat vlastně cokoliv offline (úprava SW robota v terénu);
Nikdy jsem nic takového nepotřeboval a nevidím jediné využití. Pro historii používám Eclipse Local History. A bez toho není problém pustit skript na generování patchů oproti Base a ty ukládat někam bokem (vyřeší se tím funkce jak stach tak commit),
Jo, tak tohle se mi uz hodilo.
Tri tydny u zakaznika na miste, delam zmeny. Kolegove zatim v materske firme vyvijeji dal.
Po navratu chci moje zmeny i s historii mergovat do hlavni verze, na ktere zatim kolegove pracovali.
Se Subversion docela narez.
Resil jsem to pomoci hgSubversion (Mercurial jako Subversion-Klient).
Tohle umím. Repo si vyexportuju a vlozim do lokalni SVN repozitory. To je operace na par kliknuti. Nasledne do toho normalne commituju. Az se vratim do materske firmy, vytahnu si revizi, ze ktere jsem to vyexportoval, zamerguju cely lokalni repozitar do te revize, zamerguju tam zmeny provedene mezitim (nebo proste udelam update), zkontroluju, commitnu. Pokud se to protahne, protoze tam je moc konfliktu, resim to pres branch, do ktereho nakopiruju moji verzi z lokalniho svn. Cele to zabere par minut a hodi se to jen... obcas
-
Tohle umím. Repo si vyexportuju a vlozim do lokalni SVN repozitory. To je operace na par kliknuti. Nasledne do toho normalne commituju. Az se vratim do materske firmy, vytahnu si revizi, ze ktere jsem to vyexportoval, zamerguju cely lokalni repozitar do te revize, zamerguju tam zmeny provedene mezitim (nebo proste udelam update), zkontroluju, commitnu. Pokud se to protahne, protoze tam je moc konfliktu, resim to pres branch, do ktereho nakopiruju moji verzi z lokalniho svn. Cele to zabere par minut a hodi se to jen... obcas
a s gitem je to "git push"
tady jeden uživatel píše něco o bránění se moderním technologiím:
http://forum.root.cz/index.php?topic=8389.msg86471#msg86471
-
pri ucenim gitu som prisiel na toto:
v gite treba zabudnut na vsetko, co ste kedy poznali zo sveta svn a naucit sa to nanovo, poriadne a citanim manualu a skusanim.
lebo mnoho veci je takych, ze "dokelu, preco to nie je ako v svn" (preco musim robit komit na dvakrat a nie ako v svn, preco ma eclipse divny plugin), a pritom je to o inej filozofii, ktoru treba pochopit
akurat na to treba mat cas a pozornost, ja som nedokazal ist do gitu hrrr hrrr stylom, lebo to bol suicide, nadavanie a frustracia
ja pouzivam git kvoli githubu, kvoli lokalnej historii a tagom (lebo eclipse local history je cool, ale sa mi stalo, ze nevidel do velmi dalekej minulosti)
ale stale uznavam, ze ked centralny server nie je bremeno ani prekazka, tak svn na zakladne veci staci v pohode
-
Otazka zni naopak: proc bys nemel? Treba podelana pomalost, zavislost na serveru, "reseni" konfliktu... A az jednou zkusis delat v tymu aspon dvou lidi nebo projektu vetsim nez prezentacni web tak SVN nebudes chtit vice videt. Pridej k tomu treba Atlassian Stash a zjistis proc je SVN mrtvy nepouzitelny sajrajt.
-
Pokud nepotřebuješ lokální commity (z diskuse mi přišlo že je potřebuješ a obcházíš) a branche, netrápí tě těch pár věcí, co má git rychle a svn ne, pokud ti nikdo git nevnucuje, tak zůstaň u svn. Git je mocnější nástroj s jednou úrovní fíčur (a míst, kde se něco může pokakat) navíc. Pro práci jednoho člověka na malém projektu je git jednoznačně overkill, tady bych ho doporučil jen, pokud ho máš rád a jsi na něj zvyklý - nebo si ho chceš vyzkoušet. Pro malý tým je to na zvážení, já bych tady asi už git doporučil, ale záleží, na co jsou lidé zvyklí. Pro zběsilé projekty typu jádro Linuxu určitě git. Ale tohle všechno, Ondro, víš, tak proč se na to ptáš? :-)
-
Git je jiste mocny nastroj, o tom neni pochyb. Ale na to, jak je to udajne super vec a vsichni ji uzivaji atd, tak mi prijde jako docela nedomrdly. Podpurne nastroje jsou take nedotazene. Sami lide, kteri s gitem delaji treba 5 let, maji obcas problem s nim nektere veci vybojovat.
Ktere podpurne nastroje jsou nedotazene? V terminalu jede vse jak ma, v Netbeanech jede vse jak ma, SourceTree je uzivatelsky skvely lokalni nastroj, github nebo Stash jsou perfektni server GUI a workflow nastroje.
-
Git je jiste mocny nastroj, o tom neni pochyb. Ale na to, jak je to udajne super vec a vsichni ji uzivaji atd, tak mi prijde jako docela nedomrdly. Podpurne nastroje jsou take nedotazene. Sami lide, kteri s gitem delaji treba 5 let, maji obcas problem s nim nektere veci vybojovat.
Ktere podpurne nastroje jsou nedotazene? V terminalu jede vse jak ma, v Netbeanech jede vse jak ma, SourceTree je uzivatelsky skvely lokalni nastroj, github nebo Stash jsou perfektni server GUI a workflow nastroje.
v terminalu mi zdaleka nejelo vse jak ma. git pull ani po 30 mintach nerkene, ze server neni dostupny. overeny stav. pokud uz k chybe dojde, vidim akousi dvojtecku, misto toho, abych videl tu chybu, kterou to vybleje po te, co zmacknu tusim Q ;-) vim ze to zni srandovne, ale ja marne dumam, co tim nekdo chtel rict :-)
neuzivam netbeans, uzivam VisualStudio, tam plugin de facto neni (snad ve 2013 je nativni pry).
tortoise svn neumi rict, ze se nelze spojit se serverem, stejne tak jako konzolovy git. zrejme to spolu souvisi ;-)
mi doporuceny gitblit se chlubil, ze easy and quick. prvni detektivka je, najit tu spravnou dokumentaci :-))
proste me to tak uplne neprsevedcilo a stale mam spis pocit, ze mi to v hodne vecech haze spis klacky pod nohy. ale jak tu nekdo psal, je to zrejme o jine filosofii. uvidime casem, jestli ten cas proklety u gitu se ukaze jako dobre vynalozeny.
-
@JmJ: Ja pouzivam Git uz niekolko rokov a mne chyby vzdy hlasil. Dokonca mi ponukal aj riesenia a daval mi navody, co presne mam robit, aby som dosiahol to, co sa mi prave nepodarilo.
Ala ja pozivam skutocny Git, nie tretostranne graficke nadstavby (tzv.wizardy). Skutocny Git je mnohomocny nastroj, ale iba ak ho pouzivas "dumb" sposobom. Cize zidne nadstavby, ziadne wizardy, ziadne pluginy, lebo spravidla tie su vyprodukovane zle a nepokryvaju a nevyuzivaju jeho potencial.
Skutocnym Git-om mam na mysli nativnu konzolovu aplikaciu s nazvom Git s mnozstvom lahko zapamatatelnych prikazov a prepinacov.
Cize ja to vidim skor na problem u Teba, ze zazivas negativne skusenosti. Ale vedz, ze to nie su skusenosti s Git-om, ale s tretostrannou nadstavbou.
To ale nie je problem Git-u ;)
-
Tak nejak nevim, co pan Novak timto dotazem sleduje. Kdyby chtel OPRAVDU znat vyhody a nevyhody gitu , nebo jeho porovnani se svn, vygoogluje za par minut vic nez dost relevantnich informaci. Kdyby ho zajimalo nejake specificke pouziti gitu, tak by se zeptal konkretneji. Kdyby ho vubec zajimal nazor ostatnich, neodpovidal by vsem stylem: "to ja nepotrebuju, to pro me neplati, to ja delam tak a tak". Takze ja osobne si myslim ze se jedna o trolling (at uz umyslny nebo neumyslny), ostatne jako v naproste vetsine ostatnich diskuzi pana Novaka.
Pokud se ale NEJEDNA o trolling, tak bych rad upozornil na to, ze COKOLIV si pane Novak myslite o nejakem distribuovanem verzovacim systemu, bude pravdepodobne spatne. Jediny a nejlepsi zpusob jak si udelat svuj nazor je chvili git (nebo mercurial nebo cokoliv jineho) pouzivat.
Za sebe bych to shrnul asi tak, ze vsechno co bylo v svn neuveritelne slozite komplikovane, az nemozne, je v gitu nebo mercurialu superjednoduche a snadne. SVN jsem uplne prestal pouzivat pred 3 roky a ani jednou me nenapadlo ze bych chtel zpatky. Jinak par prikladu, ktere jsou pro me hodne dulezite:
* mazani a presouvani souboru a adresaru - v svn jde o horor, v git/hg je to absolutne bezproblemove
* branching a mergeovani branchu - v svn jsem sice mel branche pro starsi verze produkcniho kodu, pro vyvojovou vetev apod, ale jejich mergeovani byla prace na cely den, ne-li vice. V git/hg vec na par sekund.
* zadny centralni server neni nutny - pokud chci JEN verzovat nejaky testovaci programek, v svn se to nevyplati verzovat - zvlast pokud nemate zalozene centralni uloziste - v git/hg je to "git/hg init" a jedu.. po skonceni muzu cely adresar s testovacim programkem smazat a je pryc i se svym lokalnim ulozistem.
* a obecne snad uplne VSECHNO je v git/hg rychlejsi... radove rychlejsi a pohodlnejsi
Duvodu je hodne, ale dokud si to clovek nevyzkousi, tak neuveri a jak znamo - zkusenost se tezko sdeluje. Prirovnal bych to treba k akumulatorovemu sroubovaku - dokud jsem ho nemel, rikal jsem ze to je kravina, a ze co potrebuju vyvrtat, vyvrtam normalni vrtackou do zastrcky a na sroubovani mam normalni sroubovak, tak k cemu by mi byl akumulatorovy sroubovak. Jenze pak jsem ho dostal k narozeninam jako darek. A musim rict, ze na starou vrtacku jsem od te doby ani nesahl a veci co jsem driv srouboval pul hodinu mam ted hotove za 5 minut, nikde se mi nemota kabel, muzu s tim vlezt kamkoliv, diky akumulatorovemu packu se to da snadno odlozit a pak zase vzit, atd, atd. A podobne je to se SVN (stara vrtacka s kabelem) a git/hg (akumulatorovy sroubovak).
-
Ale to SVN umi taky a neni to problem. Jde jen o to, ze ty vetve jsou verejne a dostupne vsem (takze se neztrati, kdyz kolega jednoho dne neprijde do prace a nikdo dalsi nebude mit heslo k jeho PC)
Hodně často narážím u evangelistů GITu na základní neznalosti práce v SVN. Je to úsměvné.
Ze zkušenosti to problém je. SVN prostě není moc dobré ve chvíli, kdy máš dvacet větví, kde se vyvíjí různé nové vlastnosti či opravují problémy (= jeden vývojář nerozbíjí práci druhému), a po dokončení vývoje se to merguje. Nebo pokud vyvíjíš software v několika verzích, protože máš několik klientů, kdy se jednomu klientovi snažíš vyladit vydávanou verzi podle jeho přání a reportů, a přitom zároveň vyvíjíš nové vlastnosti (které by tu vydávanou verzi mohly snadno rozbít) pro jiného. A pak se ozve klient, kterému jsi vydával software před rokem, že rozhodně nechce nové vlastnosti (protože by to znamenalo nové testování), ale potřebuje opravit jednu chybu, kterou jsi opravil v nových verzích. V SVN budeš mít rychle velmi mnoho konfliktů a velmi mnoho ruční práce, obzvlášť pokud jedna větev nějaký soubor přesunula a druhá upravila nebo se nějaký soubor rozdělil, což se stává až překvapivě často. Git takové věci většinou zvládne automaticky a jen jedním příkazem (např. cherry-pick v Subversion rozbije budoucí merge).
SVN umí být taky v jednom adresři, ale spatřuju jeho hlavní výhodu oddělené WC od repozitáře. Dokonce dneska už ani neplatí to, že by adresář .svn byl v každém podadresáři, takže to oddělení je úplné (i od metadat). U soliterního vývoje mívám repozitář na jiném disku než je WC...proč asi? Ale spíš vyvíjím přes vlastní server, umožňuje mi to na různých zařízeních mít okamžite přístup k aktuální verzi zdrojáků (jasně, taky mám dropbox, ale tohle je víc pod kontrolou)
Tohle samozřejmě Git umí taky: git clone --separate-git-dir někde/jinde ssh://server/var/git/repo.git. Navíc s Gitem máš najednou jak okamžitý přístup k aktuální verzi zdrojáků (svn update je totéž jako git pull), tak přístup k plné historii, i když nemáš připojení k internetu.
Nikdy jsem neměl problém s rychlostí operací. Rychlost sítě byla vždycky víc limitující faktor (práce přes mobilní připojení) A rychlost překladu ještě víc limitující. Tohle mi příjde jako virtuální problém.
V Gitu ale rychlost sítě na mobilním připojení řešit nepotřebuješ, protože to commituješ jen lokálně a pushneš to, až budeš mít pořádné připojení. Navíc během pushe či pullu, které trvají velmi dlouho, můžeš stále vyvíjet dál, nemusíš čekat, až skončí.
-
v terminalu mi zdaleka nejelo vse jak ma. git pull ani po 30 mintach nerkene, ze server neni dostupny. overeny stav. pokud uz k chybe dojde, vidim akousi dvojtecku, misto toho, abych videl tu chybu, kterou to vybleje po te, co zmacknu tusim Q ;-) vim ze to zni srandovne, ale ja marne dumam, co tim nekdo chtel rict :-)
Podle té dvojtečky a klávesy Q se jedná o less (nebo nějakou jeho pochybnou náhradu). Možná zkusit
export GIT_PAGER=cat
-
Proc jsem se ptal? Protoze si musim pripravit dobrou argumentaci proti nekomu, kdo me to chce vnutit. K tomu potrebuju znat argumenty protistrany dopredu.
Nepouzivam zadne gui ,git jsem zkousel z konzole, TortoiseGit jsem stahnul pozdeji v domeni, ze me to pomuze v zakladnich operaci. Kde je sakra prikaz update?
Lokalni commity nepouzivam, jen jsem navrhoval, jak by to slo jednoduse vyresit bez nutnosti menit navyky a menit infrastrukturu. Eclipse Local History je fajn a pokud nekomu vadi ze neni tak hluboka tak by se mel zamyslet nad tim, jak dlouho necommitoval... asi tam bude problem
ad git push - fajn jeden prikaz pro 1 promile pripadu, ale musim uplne zmenit system prace z jednodussiho na slozitejsi v 99.9% pripadu ,diky
Merge a reseni konfliktu svn neresi na serveru ,ale na klientovi. SVN merge lze nahradit vlastnim merge nastrojem (zakladni neznalost SVN)
-
Tisíce paralelních větví umožňují například ...
Ale to SVN umi taky a neni to problem.
Problém to není asi jak kde, každopádně z mého pohledu to Git umí podstatně lépe. Vlastně neznám SVN repository, kde by se tisíce paralelních větví používalo. Zato znám ze světa SVN případy "To by chtělo vytvořit branch. No tak já to radši nebudu commitovat, nechám si to u sebe na disku a pak to commitnu všechno najednou na konci". Nebo když je potřeba stejnou změnu promítnout do více větví, dělá se to ručně, protože SVN neumí commit aplikovat do jiné větve.
Jde jen o to, ze ty vetve jsou verejne a dostupne vsem (takze se neztrati, kdyz kolega jednoho dne neprijde do prace a nikdo dalsi nebude mit heslo k jeho PC)
Kolegovo repository může být zálohované na serveru nebo klidně sdílené ve veřejném nebo poloveřejném repository.
Hodně často narážím u evangelistů GITu na základní neznalosti práce v SVN. Je to úsměvné.
Nebo jsou to prostě jen uživatelé, kteří dříve používali SVN a pak začali používat i nějaký DVCS - a těžko vám budou vysvětlovat, že SVN taky větve umí a není to žádný problém, ale teprve s DVCS je používá často a rád.
Ale poradím vám jeden silný argument proti DVCS. Je to něco jiného, než SVN. Pracovat s Gitem jako by to bylo SVN je oproti SVN opruz. Místo update - merge - commit z SVN děláte s DVCS odložení změn (stash) - pull - rebase - unstash - commit - push. Některé kroky sice některé DVCS provedou automaticky, ale stejně člověk musí vědět, že se to dělá takhle. Takže přecházet na DVCS, aby to člověk dál používal jako SVN, to se nevyplatí.
Konečně podívej se na zdrojáky webkit/chromium. To je slepenec bez vnitřní organizace, ve kterém se prakticky nedá vyznat, na různých místech se střídají programátorské styly, někde dokonce i několik na jedné řádce.
To s verzovacím systémem nemá vůbec nic společného.
No spíš to souvisí s myšlenkou distribuovaného vývoje. Nikdy jsem tu myšlenku moc nepobral.
Jako že by bylo lepší, kdyby se všichni programátoři střídali u jednoho počítače? To jste asi nemyslel, že... Distribuovaný VCS s distribuovaným vývojem nijak nesouvisí, to "D" v "DVCS" znamená, že je distribuované úložiště zdrojáků, tedy celá historie projektu není jenom na jednom serveru, ale má ji každý vývojář u sebe. Třeba je pryč s notebookem, nemá připojení do internetu, a přesto může commitovat, procházet historii, vytvářet branche apod. Ale když se pak připojí k internetu, tak své repository sesynchronizuje s firemním, uvidí všechny nové změny a ostatní uvidí jeho změny, a nemusí nic mergovat nebo to jinak řešit.
-
Vlastní zkušenost:
v SVN: branchování, mergování, revokace blbého commitu, kopírování adresářů, záchrana po blbě provedené operaci: časté problémy a nadávky
v GIT vše +- bez problémů
Ne, že by to vše v SVN nešlo, jen prostě s gitem mi vše přijde jednodušíí.
Jistě, možná jen neumím s SVN. Ale používal jsem dosti dlouho SVN i GIT a s gitem jsem se to vše naučil. Křivka učení také svědčí o kvalitě nástroje.
-
Proc jsem se ptal? Protoze si musim pripravit dobrou argumentaci proti nekomu, kdo me to chce vnutit. K tomu potrebuju znat argumenty protistrany dopredu.
Proc k tomu pristupovat takto konfrontacne, s predpokladem, ze by se vam Git nikdy nemohl libit? Zkusenost jinych lidi hovori jasne o opaku - neznam snad nikoho, kdo by presel z Gitu na SVN, ale naopak hodne lidi a pochvaluji si to.
Nebylo by lepe toho vaseho kolegu pozadat, aby vam sam ukazal, jak s tim efektivne pracuje? Nejenze se tak dozvite jeho argumenty primo, ale mozna vas i presvedci, a usetrite si tak zbytecny konflikt.
-
Zakladni rozdil pro praci s GITem je treba si uvedomit, ze je rozdelena operace commit a push (i kdyz v Eclipse pluginu lze obe operace provest najednou, pro usetreni klikani).
Jinak na GITu si hlavne pochvaluju snadnou praci s vetvema (a pak je dobrym zvykem v GITu delat pro kazdou ficuru branch), taky z tohoto lze dodrzovat dobry zvyk commitovat casto (napriklad drzet pravidlo, ze v jednom commitu se opravuje pouze jeden jedinny bug).
Nejcastejsi operace v GITu jsou: pull (kombinace fetch a merge), add (vyberu, co chci commitnout), commit (mozno pouzit -a pokud se nechces zabyvat funkci add), push.
Je zde nutno podotknout, ze commit pouze vytvari novou verzi (pracuje nad lokalnim repem), pro komunikaci se vzdalenym repem slouzi fetch (obvykle v kombinaci s merge jako pull) a push.
-
Proc bych chtel v gitu casto commitovat? Neco jako autocommit by tam nebyl? svn commit neboli git push by mel byt oficialni akt publikovani svych zmen na verejnem serveru. Abych si pro sebe commitoval kazde uprdnuti, nechapu vyznam. Nicmene funkce lokalni historie v eclipse funguje perfektne a nic commitovat nemusim
-
mame tu git bisect na loveni commitu, kdy se nam zavlekla chyba, takze castejsi commitovani vede k tomu, ze se snaz dopatram, u kteryho refaktoringu jsem udelal neco blbe
-
Proc bych chtel v gitu casto commitovat? Neco jako autocommit by tam nebyl? svn commit neboli git push by mel byt oficialni akt publikovani svych zmen na verejnem serveru. Abych si pro sebe commitoval kazde uprdnuti, nechapu vyznam.
Dívejte se na to tak, že SVN a DVCS jsou úplně různé systémy. SVN je centrální úložiště zdrojových kódů, které má jako bonus udržování historie a dokonce i větvení. Prostě máte na jednom místě zdrojové kódy, a ty různí programátoři upravují - a SVN řeší, aby se při tom měnění moc nepoprali.
Naproti tomu DVCS je úložiště změn ve zdrojových kódech. Uděláte nějakou změnu a jako balíček ji uložíte do úložiště. DVCS řeší práci s těmito změnami - můžete je různě přesouvat, řadit je do větví apod.
V SVN děláte commit, když chcete svůj kód zpřístupnit ostatním. V DVCS commitujete, když uděláte jednu změnu. Význam? Můžete pak s tou změnou pracovat. Přesunout ji jinam, vyřadit jí, zařadit jí později.
Pokud nechcete pracovat se změnami a chcete jenom úložiště zdrojových kódů, použijte SVN.
-
Ja bych rekl ze argumenty ztratily smysl. Pan Novak nam jasne rekl, ze jedine, o co mu jde, jsou argumenty PROTI GITu, ktere by mohl nekomu "vmest do tvare" a dale pouzivat SVN. S timto pristupem asi nema cenu cokoliv psat, protoze pan Novak chce slyset "SVN je lepsi nez GIT protoze X,Y", a to mu asi nikdo, kdo kdy pouzival SVN a pak GIT (nebo jiny DVCS) nerekne. Rikat mu "GIT je lepsi nez SVN protoze A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y", nema cenu, protoze tuto informaci nehleda a tak ji bude ignorovat, nebo odpovi necim ve stylu "nevim, proc bych na rozdelavani ohne potreboval sirky, normalne ohen rozdelavam trenim drevene hulky a nemam s tim zadny problem, sirky asi doporucuji lide, co neumi poradne pouzivat drevenou hulku".
-
pan Novak chce slyset "SVN je lepsi nez GIT protoze X,Y", a to mu asi nikdo, kdo kdy pouzival SVN a pak GIT (nebo jiny DVCS) nerekne
Řekne, už se stalo:
Ale poradím vám jeden silný argument proti DVCS. Je to něco jiného, než SVN. Pracovat s Gitem jako by to bylo SVN je oproti SVN opruz. Místo update - merge - commit z SVN děláte s DVCS odložení změn (stash) - pull - rebase - unstash - commit - push. Některé kroky sice některé DVCS provedou automaticky, ale stejně člověk musí vědět, že se to dělá takhle. Takže přecházet na DVCS, aby to člověk dál používal jako SVN, to se nevyplatí.
-
Ja bych rekl ze argumenty ztratily smysl. Pan Novak nam jasne rekl, ze jedine, o co mu jde, jsou argumenty PROTI GITu, ktere by mohl nekomu "vmest do tvare" a dale pouzivat SVN. S timto pristupem asi nema cenu cokoliv psat, protoze pan Novak chce slyset
FYI - taky už git používám, ale většinou u toho "rostu".
Dívejte se na to tak, že SVN a DVCS jsou úplně různé systémy. SVN je centrální úložiště zdrojových kódů, které má jako bonus udržování historie a dokonce i větvení. Prostě máte na jednom místě zdrojové kódy, a ty různí programátoři upravují - a SVN řeší, aby se při tom měnění moc nepoprali.
Přesně tak, hlavně zásadní "výhodu" spatřuju v tom, že v centrálně řízené organizaci není DVCS nutný, naopak jednotlivý programátoři musí být zastupitelní, aby každý měl v danou chvíli možnost pokračovat na práci někoho jiného. Chápu, že tohle lze vyřešit i v gitu, ale otázkou je, proč bych měl přecházet na GIT na serveru a strávit hodiny pouhým překlápěním repozitářů do GITového formátu. O ten správný argument možná jde. Zatím jsem jen slyšel, že je to moderní standard. Jinak o existenci git-svn vím.
Naproti tomu DVCS je úložiště změn ve zdrojových kódech. Uděláte nějakou změnu a jako balíček ji uložíte do úložiště. DVCS řeší práci s těmito změnami - můžete je různě přesouvat, řadit je do větví apod.
... pak s tou změnou pracovat. Přesunout ji jinam, vyřadit jí, zařadit jí později.
Pokud nechcete pracovat se změnami a chcete jenom úložiště zdrojových kódů, použijte SVN.
Obdivuju váš čas si s tím hrát. Já zpravidla programuju lineárně. Bych si klidně udělal tisíce větví, beztak by tam jen hnily.
-
Nepouzivam zadne gui ,git jsem zkousel z konzole, TortoiseGit jsem stahnul pozdeji v domeni, ze me to pomuze v zakladnich operaci. Kde je sakra prikaz update?
Jmenuje se pull.
Možná by ale bylo vhodnější zadat do Googlu „základy Gitu“.
Lokalni commity nepouzivam, jen jsem navrhoval, jak by to slo jednoduse vyresit bez nutnosti menit navyky a menit infrastrukturu. Eclipse Local History je fajn a pokud nekomu vadi ze neni tak hluboka tak by se mel zamyslet nad tim, jak dlouho necommitoval... asi tam bude problem
Nejde o lokální commity, ale o to, že díky velmi rychlému větvení a mergování commituješ jen malé změny, ne jeden velký balík, jako se to dělá v SVN. Jak důležitý rozdíl to je, zjistíš ve chvíli, až budeš potřebovat cherry-pick konkrétní opravy do jiné větve. Nebo až zjistíš, že merge větve tvého kolegy, který provedl v pátek těsně před tím, než na dva týdny zmizel na dovolenou, něco rozbil (git bisect pak dost pomůže najít, co by to tak mohlo být).
ad git push - fajn jeden prikaz pro 1 promile pripadu, ale musim uplne zmenit system prace z jednodussiho na slozitejsi v 99.9% pripadu ,diky
Ten systém práce není zase o tolik složitější. Když ses zvládl naučit šablonování v C++, tak Git je oproti tomu hračka.
Mimochodem proč používáš na vývoj v C++ Eclipse? Vždyť je to oproti textovému editoru a terminálu hrozně složité :D
Merge a reseni konfliktu svn neresi na serveru ,ale na klientovi. SVN merge lze nahradit vlastnim merge nastrojem (zakladni neznalost SVN)
To by mě zajímalo, jak ten nástroj pozná přejmenovaný soubor bez patřičné informace od verzovacího systému. A jestli hodláš předhodit svn mv, tak jsi právě vytáhl velmi složitý postup oproti Gitu, který pozná přejmenované soubory sám.
Obdivuju váš čas si s tím hrát. Já zpravidla programuju lineárně. Bych si klidně udělal tisíce větví, beztak by tam jen hnily.
Obdivuju, že si to můžeš dovolit. Já vyvíjím nové vlastnosti a zároveň podporuju vydaný software pro několik desítek klientů. A nemůžu říct klientovi, že tu padačku opravím, až za dva měsíce naimplementuju to, co mám právě rozdělané, nebo že dostane další beta verzi, která sice opraví nahlášené chyby, ale možná bude mít úplně nové chyby, protože je v ní spousta nového kódu.
-
Taky jsme přešli na Git. Hračičkové co milují "konfigurování" a "totální kontrolu" a možnost "všechno detailně ovládat" si libují, ti co to prostě mají na práci a svů intelekt raději napřou k předmětu projektu a ne na onanii nad verzema zdrojáků s tím moc spokojení nejsou, a nakonec, aby se to přestalo prasit, začali správcové implementovat hooky na serveru které tu celou práci ještě ztěžují jak se snaží zabránit bordelu.
Neboli, pokud víte do čeho jdete a chcete to, tak jo. Pokud je důvodem hype a nutkavá potřeba nějakých nerdů si dokazovat jak komplexní systém dokážou ovládnout svým mocným mozkem, tak si na to dejte bacha.
-
Jmenuje se pull.
Možná by ale bylo vhodnější zadat do Googlu „základy Gitu“.
To jsem právě udělal a napsalo to "příkaz skončil nenulovým statusem" - jo zatím používam gclient sync ale trvá to strašně dlouho
Obdivuju, že si to můžeš dovolit. Já vyvíjím nové vlastnosti a zároveň podporuju vydaný software pro několik desítek klientů. A nemůžu říct klientovi, že tu padačku opravím, až za dva měsíce naimplementuju to, co mám právě rozdělané, nebo že dostane další beta verzi, která sice opraví nahlášené chyby, ale možná bude mít úplně nové chyby, protože je v ní spousta nového kódu.
Od toho je přece tagování. Vytáhnu si ze SVN jeho verzi (patřičně otagovanou) do branche, opravím chybu, vydám hotfix, commitnu do branche, otáguju a ještě si změnu zamerguju do trunku, pokud ta chyba nebyla již opravena v budoucnu. Co z toho navíc umí git?
-
Proc bych chtel v gitu casto commitovat? Neco jako autocommit by tam nebyl? svn commit neboli git push by mel byt oficialni akt publikovani svych zmen na verejnem serveru. Abych si pro sebe commitoval kazde uprdnuti, nechapu vyznam. Nicmene funkce lokalni historie v eclipse funguje perfektne a nic commitovat nemusim
protoze pak chces nejaky ten prd vratit a udelas git revert. protoze kdyz pouzivas nejaky workflow management jako je treba stash tak v commit messages lze vyhledavat, mas to treba propojene na jira atd.
Zkus SourceTree, ten je skvely.
-
Ja bych rekl ze argumenty ztratily smysl. Pan Novak nam jasne rekl, ze jedine, o co mu jde, jsou argumenty PROTI GITu, ktere by mohl nekomu "vmest do tvare" a dale pouzivat SVN. S timto pristupem asi nema cenu cokoliv psat, protoze pan Novak chce slyset
FYI - taky už git používám, ale většinou u toho "rostu".
to jsou slaba slova oproti tomu co zazivam kdyz musim pro jednu zpatecnickou firmu na jednom projektu pouzivat SVN.
-
svn commit neboli git push
Jde o různé věci, git push pošle již vytvořené commity do vzdáleného repozitáře, třeba commity za celý den práce najednou.
Commity je dobré mít co nejmenší, aby se snadno daly rychle revertnout v případě problémů. To se hodí dost často.
Osobně mi na gitu vyhovuje styl práce, kdy commituji postupně malé commity, po chvíli objevím, že jsem zapomněl do některého commitu ještě něco dát, udělám nový commit s poznámkou, k čemu to patří, až než to pushnu na centrální server pro ostatní vývojáře (třeba i jen jednou za den), v interaktivním rebasu ty commity během pár sekund sloučím, zpřeházím dle potřeby, prostě učešu.
Samozřejmě pro firemní použití jsme si napsali jednoduché skripty, které samy řeší stash/unstash a další věci. Takže při updatu ze serveru (git pull --rebase + stashování) napíšu např. "up" a vše se pořeší za mě.
Síla gitu se ukázala při potřebě synchronizovat projekt při přístupu jen přes citrix, kdy jediné spojení se vzdáleným strojem je přístup na lokální disk v GUI citrixího klienta. Git umí vyexportovat rozsah commitů do souboru - bundlu. Ten překopíruji citrixem na vzdálený stroj, tam ten soubor-bundle nastavím jako remote repozitory a normálně z něj pullnu. Chová se to jako síťový repozitář, tudíž plná funkce gitu. Mohu klidně do něj i pushnout případné vzdálené změny, zkopírovat jej zpět (nebo si vyrobit nový, menší jen se vzdálenými commity) a změny opět pullem natáhnout na lokální mašině. Ty pak snadno mohu pushnout do centrálního serveru a kromě potřeby generování/kopírování toho bundlu se to chová, jako by byl vzdálený stroj připojený po síti k repozitáři. Velice užitečné.
IMO kdybys čas strávěný touto diskusí věnoval studiu gitu, už bys to neřešil.
-
protoze pak chces nejaky ten prd vratit a udelas git revert. protoze kdyz pouzivas nejaky workflow management jako je treba stash tak v commit messages lze vyhledavat, mas to treba propojene na jira atd.
Zkus SourceTree, ten je skvely.
Na to používám Control+Z (Undo)
-
protoze pak chces nejaky ten prd vratit a udelas git revert. protoze kdyz pouzivas nejaky workflow management jako je treba stash tak v commit messages lze vyhledavat, mas to treba propojene na jira atd.
Zkus SourceTree, ten je skvely.
Na to používám Control+Z (Undo)
A co kdyz chces vratit neco, cos na tom souboru udelal nekdy driv?
//MODS: navrhuju lock, zacina mi to pripominat diskuzi s trollem
-
Na to používám Control+Z (Undo)
Bavíme se o revertu commitu starého i několik dnů, překrytého spoustou jiných, který je již třeba nasazený na finálním stroji v produkční větvi. Proto je potřeba, aby byly commity malé, aby se mimo jiné minimalizovalo riziko konfliktu při revertu nebo cherry picku.
-
Na to používám Control+Z (Undo)
A co kdyz chces vratit neco, cos na tom souboru udelal nekdy driv?
//MODS: navrhuju lock, zacina mi to pripominat diskuzi s trollem
[/quote]
Na to použiju visualni compare. Vrátím poškozený kód a commitnu to. Je to lepší, mám aspoň přehled o tom, co se vrací (visuální porovnávače jsou dost schopné nástroje)
-
Jmenuje se pull.
Možná by ale bylo vhodnější zadat do Googlu „základy Gitu“.
To jsem právě udělal a napsalo to "příkaz skončil nenulovým statusem" - jo zatím používam gclient sync ale trvá to strašně dlouho
Tohle rozhodně neudělal Git, ale nějaká „chytrá“ nadstavba, kterou používáš.
Obdivuju, že si to můžeš dovolit. Já vyvíjím nové vlastnosti a zároveň podporuju vydaný software pro několik desítek klientů. A nemůžu říct klientovi, že tu padačku opravím, až za dva měsíce naimplementuju to, co mám právě rozdělané, nebo že dostane další beta verzi, která sice opraví nahlášené chyby, ale možná bude mít úplně nové chyby, protože je v ní spousta nového kódu.
Od toho je přece tagování. Vytáhnu si ze SVN jeho verzi (patřičně otagovanou) do branche, opravím chybu, vydám hotfix, commitnu do branche, otáguju a ještě si změnu zamerguju do trunku, pokud ta chyba nebyla již opravena v budoucnu. Co z toho navíc umí git?
Ta to jsi právě popřel to, na co jsem reagoval. Git oproti SVN umí opravdové cherry-picky a je v tomhle mnohem rychlejší. A nemusím mít pro padesát větví padesát workspaců v Eclipsu.
Na to použiju visualni compare. Vrátím poškozený kód a commitnu to. Je to lepší, mám aspoň přehled o tom, co se vrací (visuální porovnávače jsou dost schopné nástroje)
V Gitu použiji jeden příkaz a vidím, co vracím. Navíc pokud jsem to ještě nepushnul, můžu ten vadný kód úplně odstranit z historie. Ale to je asi příliš složité...
-
Od toho je přece tagování. Vytáhnu si ze SVN jeho verzi (patřičně otagovanou) do branche, opravím chybu, vydám hotfix, commitnu do branche, otáguju a ještě si změnu zamerguju do trunku, pokud ta chyba nebyla již opravena v budoucnu. Co z toho navíc umí git?
Ta to jsi právě popřel to, na co jsem reagoval. Git oproti SVN umí opravdové cherry-picky a je v tomhle mnohem rychlejší. A nemusím mít pro padesát větví padesát workspaců v Eclipsu.
Že bys taky neuměl pracovat v SVN? Kde jsi vzal 50 workspaců. Víš že existuje svn switch?
Na druhou stranu, mě právě vyhovuje mít víc workspaců, pokud potřebuju pracovat na víc větví. Mohu třeba pracovat naráz na obou, třeba během překladu jedné větve vyrábím hotfix v druhé větvi. Možná že to v tom gitu nějak jde taky, ale zatím se mi podařilo jen pro každou větev mít jednu aktivní a další větve ... někde skryté... ale třeba se tu dozvím, jak se to dělá.
Když už o tom mluvíme, napadá tě, jak bych mohl verzovat větev, aniž bych si musel držet celý repozitář? Já zatím do SVN ukládám patche.
Na to použiju visualni compare. Vrátím poškozený kód a commitnu to. Je to lepší, mám aspoň přehled o tom, co se vrací (visuální porovnávače jsou dost schopné nástroje)
V Gitu použiji jeden příkaz a vidím, co vracím. Navíc pokud jsem to ještě nepushnul, můžu ten vadný kód úplně odstranit z historie. Ale to je asi příliš složité...
Nemožnost opravovat historii jsem bral (a doposud beru) jako obrovský plus SVN (s výjimkou toho, když se někomu opravdu inteligentnímu podaří do SVN commitnout heslo k databázi). I když byla revize vadná, pořád stojí za to, aby tam zůstala. Protože to je evidence
-
Ano, CTRL+Z a visual compare je opravdu super náhrada za git...
(http://img1.wikia.nocookie.net/__cb20130217001558/dragonball/images/6/64/Implied-facepalm1.jpg)
-
Ctrl-Z chapem pri jednom subore, ale co ked ta zmena je refaktoring cez pat suborov?
I když byla revize vadná, pořád stojí za to, aby tam zůstala. Protože to je evidence
mne sa zda, ze editovat komity je mozne len ak neboli pushnute
-
Ano, CTRL+Z a visual compare je opravdu super náhrada za git...
Ano, já bych fakt chtěl tohle vidět v praxi.
1) Semhle dopíšu for (auto &x: observers) x.update(..)
2) zmáčknu Ctrl+S
3) přepnu do terminálu a napíšu git commit -a;
4) přepnu zpět
5) ah, ještě bych tam mohl napsat observers.clear()
6) zmáčknu Ctrl+S
7) přepnu do terminálu a napíšu git commit -a;
..
..
..
Jaký máte výkon source-lines/hour?
-
Ano, já bych fakt chtěl tohle vidět v praxi.
..
..
..
Sakra, já zapoměl, no jasně, ještě napsat popis commit "připsal jsem notifikaci observů"
no a ještě bych to měl mít v komentáři, takže opět 1,2, git commit -a "dopsal jsem to do komentaru"
-
Pushnutí vadného commitu je chyba, ne výhoda. Zaneřádím historii projektu a hlavně tím otravuji život i ostatním vývojářům, kteří si vadnou verzi stahnou a budou se s tím muset potýkat. Před pushem je potřeba se rozmyslet, zda je to opravdu správně - třeba zrovna to heslo v commitu vyrobeném před několika hodinami, po kterém následuje deset dalších. Pak už se historie opravit nedá (nebo jen pracně). V git rebase commit vyhodím/opravím.
Pěkná práce s commity je při přispívání do kernelu. Správci dostanou celý commit (např. přes git-send-mail), zrevidují jej, skriptem (zřejmě automaticky spouštěným) zkontrolují štábní kulturu a když je to v pořádku, přidají jej rovnou z mailového klienta do svého repozitáře, např. do některé své větve na git.kernel.org. Pak ve vhodný čas Linusovi jen pošlou commity, které chtějí mergnout do nové verze kernelu. Commity si rozdělují na kritické, které chtějí do ostré verze dostat co nejdříve, a normální, které počkají na další otevřené okno pro mergování do nové verze. Proto musí být co nejmenší a musí řešit jen jeden problém, aby se s nimi dalo pracovat jako s ucelenými bloky dobře popsaných změn, které jsou natolik jednoduché, že je lze snadno projít a zkontrolovat.
-
Od toho je přece tagování. Vytáhnu si ze SVN jeho verzi (patřičně otagovanou) do branche, opravím chybu, vydám hotfix, commitnu do branche, otáguju a ještě si změnu zamerguju do trunku, pokud ta chyba nebyla již opravena v budoucnu. Co z toho navíc umí git?
Ta to jsi právě popřel to, na co jsem reagoval. Git oproti SVN umí opravdové cherry-picky a je v tomhle mnohem rychlejší. A nemusím mít pro padesát větví padesát workspaců v Eclipsu.
Že bys taky neuměl pracovat v SVN? Kde jsi vzal 50 workspaců. Víš že existuje svn switch?
Ano, vím, ale switch je spíš hack než reálně použitelná náhrada git checkout, vyžaduje to plné URL a rychlost (nebo spíš pomalost) je otřesná. Proč myslíš, že se v SVN běžně používá pro každou branch vlastní adresář?
Na druhou stranu, mě právě vyhovuje mít víc workspaců, pokud potřebuju pracovat na víc větví. Mohu třeba pracovat naráz na obou, třeba během překladu jedné větve vyrábím hotfix v druhé větvi. Možná že to v tom gitu nějak jde taky, ale zatím se mi podařilo jen pro každou větev mít jednu aktivní a další větve ... někde skryté... ale třeba se tu dozvím, jak se to dělá.
V Gitu to jde úplně bez problému, dokonce několika způsoby, podle toho, jak to potřebuješ:
- pokud chceš nové commity ukládat do toho nového repozitáře, ale historii brát z jiného, tak pomocí git clone --reference cesta URL
- pokud chceš oddělený repozitář a několik adresářů, kde budeš vyvíjet, tak pomocí git clone --separate-git-dir cesta_k_repozitáři URL a následujícím krokem
- pokud ti stačí odkazovat se na jiný vyklonovaný adresář, tak jde vytvořit prázdný adresář, přidat tam .git jako symlink na existující repozitář (resp. .git v něm) a spustit git reset --hard
Když už o tom mluvíme, napadá tě, jak bych mohl verzovat větev, aniž bych si musel držet celý repozitář? Já zatím do SVN ukládám patche.
git clone --single-branch --branch větev URL
Ctrl-Z chapem pri jednom subore, ale co ked ta zmena je refaktoring cez pat suborov?
I když byla revize vadná, pořád stojí za to, aby tam zůstala. Protože to je evidence
mne sa zda, ze editovat komity je mozne len ak neboli pushnute
Jde editovat i commity, které již byly pushnuté, ale historii na serveru to nezmění a bude potřeba merge (tedy jde to vynutit, ale to je bad practice). Tohle se týká spíš stupidních chyb jako překlep v dokumentaci.
Ano, CTRL+Z a visual compare je opravdu super náhrada za git...
Ano, já bych fakt chtěl tohle vidět v praxi.
1) Semhle dopíšu for (auto &x: observers) x.update(..)
2) zmáčknu Ctrl+S
3) přepnu do terminálu a napíšu git commit -a;
4) přepnu zpět
5) ah, ještě bych tam mohl napsat observers.clear()
6) zmáčknu Ctrl+S
7) přepnu do terminálu a napíšu git commit -a;
..
..
..
Jaký máte výkon source-lines/hour?
git commit -a --amend ;)
-
Pushnutí vadného commitu je chyba, ne výhoda. Zaneřádím historii projektu a hlavně tím otravuji život i ostatním vývojářům, kteří si vadnou verzi stahnou a budou se s tím muset potýkat. Před pushem je potřeba se rozmyslet, zda je to opravdu správně - třeba zrovna to heslo v commitu vyrobeném před několika hodinami, po kterém následuje deset dalších. Pak už se historie opravit nedá (nebo jen pracně). V git rebase commit vyhodím/opravím.
Pěkná práce s commity je při přispívání do kernelu. Správci dostanou celý commit (např. přes git-send-mail), zrevidují jej, skriptem (zřejmě automaticky spouštěným) zkontrolují štábní kulturu a když je to v pořádku, přidají jej rovnou z mailového klienta do svého repozitáře, např. do některé své větve na git.kernel.org. Pak ve vhodný čas Linusovi jen pošlou commity, které chtějí mergnout do nové verze kernelu. Commity si rozdělují na kritické, které chtějí do ostré verze dostat co nejdříve, a normální, které počkají na další otevřené okno pro mergování do nové verze. Proto musí být co nejmenší a musí řešit jen jeden problém, aby se s nimi dalo pracovat jako s ucelenými bloky dobře popsaných změn, které jsou natolik jednoduché, že je lze snadno projít a zkontrolovat.
A oni se dívají i na historii? nebo je zajímá finální stav. Protože pokud vím, úplně stačí posílat patch. Na vadnou revizi samozřejmě často přijde někdo jiný. Když pracuji ve větvích, není možné někomu zaneřádit projekt. Nebo to něčemu odporuje? Evidence vadné revize ve větvi je užitečná, ale pokud byla ta revize rollbacknuta, pak by snad neměla nikomu škodit
Naopak si nedokážu představit, že před odchodem ze zaměstnání na poslední chvíli čistím commity (to už bych tedy raději dělal ráno, ale to zas spousti věci prostě nemá člověk v hlavě)
-
Commituji, až je úprava hotová. Opravy commituji hned. A pak se mohu vrátit k vývoji feature, protože když bude potřeba (např. zapomenutý necommitnutý soubor při refaktoringu, bez kterého commit nepůjde nezkompilovat), následující commit přes interaktivní rebase snadno spojím s některým z předchozích. Samozřejmě commituji přes IDE (IntelliJ), kde řeším i rozdíly mezi commity. Jen je škoda, že zatím IntelliJ neumí snadno commity jen chunků a rozpad commitu na dva, to by se hodně moc hodilo.
-
pokud ti stačí odkazovat se na jiný vyklonovaný adresář, tak jde vytvořit prázdný adresář, přidat tam .git jako symlink na existující repozitář (resp. .git v něm) a spustit git reset --hard
Oprava, symlink na celý .git nefunguje. Je potřeba udělat symlink na .git/objects a zbytek zkopírovat.
-
A oni se dívají i na historii? nebo je zajímá finální stav. Protože pokud vím, úplně stačí posílat patch.
Samozřejmě každý commit řeší konkrétní problém, je vzniklý právě spojením (squash v interaktivním rebase) všech tvých malých commitů, které se toho týkaly, které sis vyrobil třeba během týdne. Mrkni např. na http://mailman.alsa-project.org/pipermail/alsa-devel/2014-July/079445.html a následné zprávy - 13 po sobě jdoucích commitů. Ty určitě nevznikly najednou, ale spojením spousty menších, aby v tom nebyl bordel. A pak se diskutuje už o konkrétních commitech, některé opraví a pošle je znovu.
Samozřejmě ve firemním vývoji to takto pečlivě neděláme, spojují se jen commity, kde je to jasné, ale je potřeba na to myslet a mít nástroj, který tohle umožňuje.
Jinak to "čištění" commitů před pushem ve firmě obnáší jen jejich případné spojení či přeřazení, práce na pár sekund. S commity do kernelu je to jiné, tam se musí daleko pečlivěji. Ale pak ten commit zůstane v kernelu nafurt, veřejně všem na očích.
-
Ano, vím, ale switch je spíš hack než reálně použitelná náhrada git checkout, vyžaduje to plné URL a rychlost (nebo spíš pomalost) je otřesná. Proč myslíš, že se v SVN běžně používá pro každou branch vlastní adresář?
Sám víš, že v SVN to není plnohodnotný "adresář", protože se používá sdílení. To co si člověk vytáhne jako větev je z větší části sdílené, ale pro účely snadné práce se to tváří jako adresář.
O pomalosti switch nic nevím. Bylo to pod mojí rozlišovací schopností. Jo zobrazí se asi na pár sekund progress bar. svn switch nedělá nic jiného, než rozdílový update (aplikuje patch), takže to o zas tak pomalé není. Jo, když tam má člověk lokální změny, tak to je pomalejší, protože se to zároveň merguje. Ale to už je bad practice
V Gitu to jde úplně bez problému, dokonce několika způsoby, podle toho, jak to potřebuješ:
- pokud chceš nové commity ukládat do toho nového repozitáře, ale historii brát z jiného, tak pomocí git clone --reference cesta URL
- pokud chceš oddělený repozitář a několik adresářů, kde budeš vyvíjet, tak pomocí git clone --separate-git-dir cesta_k_repozitáři URL a následujícím krokem
- pokud ti stačí odkazovat se na jiný vyklonovaný adresář, tak jde vytvořit prázdný adresář, přidat tam .git jako symlink na existující repozitář (resp. .git v něm) a spustit git reset --hard
Bod 3 ve windows bych vyřadil. další dvě mohu vyzkoušet. Bod 1 mi přijde jako nějaký kanón na vrabce. K čemu další repozitář?
git clone --single-branch --branch větev URL
Vyzkouším zítra. Nicméně podle toho jak funguje clone se bojím, že stejně skončim s celým webkitem a chromiem v separátním adresáři. Nebo ne?
git commit -a --amend ;)
nepochopil jsem odpověď, záměrem bylo zjistit, jaké všechny činnosti navíc musejí dělat programátoři v git a jak často.
-
Některé commity do kernelu samozřejmě vznikají i retrospektivně, ručním rozdělením funkčního kódu souboru do jednotlivých commitů (právě commity chunků, to myslím SVN neumí). To je pak docela pracné. Jednodušší je mít více malých commitů a ty squashnout.
-
Bod 3 ve windows bych vyřadil.
Pokud nemáš ve windows plnohodnotný git, tak bych se na něj vybodl a používal něco, co tam funguje tak, jak má. Git byl primárně navržený pro unixové filestémy a do windows je víceméně dohackovaný.
-
Bod 3 ve windows bych vyřadil.
Pokud nemáš ve windows plnohodnotný git, tak bych se na něj vybodl a používal něco, co tam funguje tak, jak má. Git byl primárně navržený pro unixové filestémy a do windows je víceméně dohackovaný.
Tenhle argument se mi líbí bez legrace. Ti co o tom rozhodují musí slyšet na jednoduchá hesla. No a zrovná má specifika je to, že umím v systému, kterému moc lidi nerozumí a takový argument by mi pomohl vyjednat si aspoň výjimku. Dík
-
Bod 3 ve windows bych vyřadil.
Protože je to adresář, tak ve Windows lze použít NTFS junction point.
git clone --single-branch --branch větev URL
Vyzkouším zítra. Nicméně podle toho jak funguje clone se bojím, že stejně skončim s celým webkitem a chromiem v separátním adresáři. Nebo ne?
Nemělo by. Tohle stáhne kompletní historii té jedné větve a nic jiného. Pokud chceš omezenou historii, můžeš tam místo --single-branch dát --depth kolik_commitů_zpět.
git commit -a --amend ;)
nepochopil jsem odpověď, záměrem bylo zjistit, jaké všechny činnosti navíc musejí dělat programátoři v git a jak často.
Tohle byla reakce na to, že ty dvě věci jsou vlastně jedna změna.
Nemusejí dělat nic či to můžou dělat úplně stejně jako v SVN. Ale protože commity jsou velmi levné, tak je vhodné je dělat často a s malými, snadno pochopitelnými změnami. Třeba stažení a použití souboru z URL uvedeného v nastavení včetně GUI:
- Přidám rozhraní pro použití toho souboru - commit
- Přidám stažení souboru a použití toho rozhraní - commit
- Přidám callback vyvolávaný stahováním (kolik staženo z kolika) - commit
- Implementuji GUI pro ten callback - commit
- Přidám možnost zrušení stahování do toho GUI - commit
- Přidám načtení URL z nastavení - commit
- push
Pokud něco z toho se ukáže jako problematické, můžu se kdykoliv vrátit, stejně tak lze snadno vyhledávat, která část do toho zavlekla chybu, kterou objevím až na konci. Nebo to můžu squashnout (= spojit více commitů) či místo commit použít amend commit (= přidat další změnu do posledního commitu), pokud mi nějaké commity přijdou zbytečně malé. A přitom je to jeden ticket, tedy v SVN by to nejspíš byl jen jeden commit (protože mezilehlé commity to taky můžou kolegům rozbít).
-
Ti co o tom rozhodují musí slyšet na jednoduchá hesla. No a zrovná má specifika je to, že umím v systému, kterému moc lidi nerozumí a takový argument by mi pomohl vyjednat si aspoň výjimku. Dík
Ti, co o tom rozhodují, by tomu především měli rozumět. Výjimky v pevně daném procesu jsou peklo a jejich akceptace musí být sakramentsky dobře zdůvodněná. Pokud tým z nějakých zásadních a také dobře promyšlených důvodů přejde na nové SCM, nedovedu si představit, že někdo z týmu zůstane na jiném.
A upřímně, pokud celou dobu hledáš důvody, proč něco nejde, místo aby ses snažil se to naučit, najít cestu, jak by to šlo, tak být tím, kdo to rozhoduje, akceptoval bych dočasnou výjimku a začal hned intenzivně hledat náhradu za toho, kdo na té výjimce trvá.
-
A upřímně, pokud celou dobu hledáš důvody, proč něco nejde, místo aby ses snažil se to naučit, najít cestu, jak by to šlo, tak být tím, kdo to rozhoduje, akceptoval bych dočasnou výjimku a začal hned intenzivně hledat náhradu za toho, kdo na té výjimce trvá.
Celé je to o tom PROČ by se měl měnit zaběhnutý systém? Proč by měla společnost s centrálními repozitáři přecházet na git? OpenSource pravděpodobně nevyvíjí a pokud už, tak bez externích kontributorů
-
A upřímně, pokud celou dobu hledáš důvody, proč něco nejde, místo aby ses snažil se to naučit, najít cestu, jak by to šlo, tak být tím, kdo to rozhoduje, akceptoval bych dočasnou výjimku a začal hned intenzivně hledat náhradu za toho, kdo na té výjimce trvá.
Celé je to o tom PROČ by se měl měnit zaběhnutý systém? Proč by měla společnost s centrálními repozitáři přecházet na git? OpenSource pravděpodobně nevyvíjí a pokud už, tak bez externích kontributorů
Třeba protože mají více než jednoho vývojáře
-
Pokud hledáte opravdu něco, co má SVN a GIT z principu nemůže, tak Vám napovím.
Jsou to uživatelská práva.
V SVN můžete definovat uživatelská práva na úrovni jednotlivých adresářů, větví, tagů. atd.
Pokud do SVN musejí přistupovat různí přispěvatelé s různými právy k různým částem projektu, je SVN v tomto lepší.
Což je výhodné např. v korporátním prostředí, kde paranoidní manažer bude chtít části projektu mezi lidmi skrývat.
V GITu máte pouze Read nebo Read-Write pro celé repository. Možná ty neptrřičné zápisy do repoí jdou zjemnit nějakým hook skriptem, ale přečíst se dá prostě celé repository.
Jde to samozřejmě obejít rozdrobením na menší repository, kde ke každému bude mít práva jen skupinka vyvolených, ale je to nepohodlné (když chcete aktualizovat projekt, musíte pracovat s vícero repository ...).
A nemůžete dané schéma práv změnit, protože rozdělení na projekty už zafixováno.
Pokud pracujete v korporátní paranoidní sféře, která ráda pečlivě od sebe odděluje přispěvatele jemně definovaných částí projektu, bude SVN lepší.
-
Přesně tak, hlavně zásadní "výhodu" spatřuju v tom, že v centrálně řízené organizaci není DVCS nutný, naopak jednotlivý programátoři musí být zastupitelní
Žádné přesně tak, způsob řízení ani zastupitelnost programátorů vůbec nesouvisí s tím, zda vyvíjíte na jedné společné hromadě zdrojáků, nebo zda vyvíjíte tak, že vytváříte a aplikujete jednotlivé změny.
Zatím jsem jen slyšel, že je to moderní standard.
Záleží na tom, čemu říkáte "slyšel". Pokud tomu, že to "zaznělo" ve vaší přítomnosti, pak jste toho slyšel mnohem víc. Pokud tomu, že jste to vzal na vědomí, protože je to v souladu s tím, co slyšet chcete, pak jste toho asi opravdu o moc víc neslyšel - ale není to chyba ostatních diskutujících.
Obdivuju váš čas si s tím hrát. Já zpravidla programuju lineárně. Bych si klidně udělal tisíce větví, beztak by tam jen hnily.
Pracuju na nějaké větší změně, mezi tím přijde někdo, že pro jeho změnu potřebuje nějakou úpravu ode mne. Pak zase já pro tu větší změnu potřebuju úpravu od někoho jiného a musím počkat, než ji dodělá, tak mezi tím dělám na něčem jiném. A do toho je potřeba průběžně opravovat chyby, které se objeví. Pokud můžete dělat vždy jen na jedné věci a nemusíte opravovat žádné chyby, asi můžete programovat lineárně. Ale moc vás takových nebude.
Celé je to o tom PROČ by se měl měnit zaběhnutý systém? Proč by měla společnost s centrálními repozitáři přecházet na git?
Protože pak vývojáři pracují efektivněji. Netráví čas zbytečně opakovaným prováděním těch samých změn na zdrojových kódech (různé větvení a spojování), místo toho se mohou věnovat vývoji. Ale jak už jsem psal, vývojáři jsou často velmi konzervativní a neměnit zaběhnutý systém je často velice silný argument pro starý systém. Ostatně vidíme to na vás.
Jinak pokud vám připadá Git složitý na používání, zkuste Mercurial - podle mne je o něco jednodušší, protože nemá tolik možností. Třeba napodobit v něm věrně práci s SVN myslím nejde (nebo jen velmi krkolomně), takže by vás to aspoň nelákalo a naučil byste se to rovnou používat správně.
-
Doporučuji si přečíst prvních několik kapitol z knihy Pro Git (http://knihy.nic.cz/files/nic/edice/scott_chacon_pro_git.pdf (http://knihy.nic.cz/files/nic/edice/scott_chacon_pro_git.pdf)) a vše si prakticky vyzkoušet.
-
Tiež som bol dlho spokojným používateľom SVN. Potom som ale robil na jednom veľkom projekte (veľa súborov) a tam každá operácia nad SVN trvala rádovo minúty (po lokálnej sieti!). Svätá trojica svn status, svn commit a svn update zabrala kľudne štvrť hodiny. Potom som ten istý strom na skúšku inicializoval do GIT-u - a tam boli operácie obvykle hotové do sekundy. To ma presvedčilo, aby som GIT začal brať vážne.
V prechode na GIT mi veľmi pomohla kniha ProGit v češtine, odkazovaná vyššie. Podľa nej som to nakoniec dal a som veľmi rád, že som to urobil.
-
Dobrý troll vlákno :D Ale přidám se:
Dělám hlavně v SVN. Jeden mini projekt (1000 souborů) a tam je SVN fakt pomalá, checkout trvá několik minut (možná je to tím, že je repository na sevreru na Amazon virtuálu?). Hledání v historii je tam prakticky nepoužitelné.
Pak trochu větší projekt (na jiném prostředí, asi 10 tisíc souborů), tam původně byla SVN taky dost pomalá, pak to nějak rozběhali, takže teď je, řekněme, přijatelně pomalá. Ale pořád třeba oanotovat soubor není nic co by bylo bleskem. Opravdu by mě zajímalo jak to Ondra dělá, že na SVN údajně nečeká.
Dělám dost často cherrypicking oprav, přes Tortoise SVN to byl pain in the ass, teď jsem se naučil pořádně používat SVN plugin v IntelliJ IDEA a je to už jen pain.
GIT používám na jednom menším projektu, člověk si musel zvyknout na trochu odlišnou filozofii, ale ve chvílí kdy ji pochopí, tak je to naopak lepší.
Třeba jedna věc, která mě v SVN dost žere: Dělám na nějaké feature, která změnila soubor X a ještě to není ve stavu, kdy bych to chtěl commitnout do repository. Pak to musím přerušit (čekání na součinnost / priorita) a chci dělat na věci, kde potřebuju taky změnit soubor X, třeba na nějakém jiném místě. No a máme problém, pánové. V GITu bych prostě commitnul částečnou implementaci, nepushoval. Pak bych se pustil do té nové věci a až bych ji dodělal, tak bych ji normálně commitnul a pushnul a mohl se vrátit k původní. V SVN můžu maximálně tak vytvořit vlastní branch (v repository používaném větším množstvím lidí nemyslitelné), nebo si to můžu vycheckoutovat do jiného adresáře, provést změnu tam, commitnout a zase smazat, ale to je dost práce a proč se drbat za levým uchem pravou rukou, když bych se tam mohl podrbat levou, že...
-
Řeknu to takhle - naučit se Vim nebo Emacs taky trvá, ale ve výsledku se to vyplatí. To samé platí pro Git.
-
Celé je to o tom PROČ by se měl měnit zaběhnutý systém? Proč by měla společnost s centrálními repozitáři přecházet na git?
Nevím, proč zrovna tvoje společnost uvažuje o přechodu. Ale vím, proč jsme před roky přešli ze SVN na git my.
Aktualizace stabilní větve commity z vývojového masteru pro nasazení několikrát do týdne zabrala vždy několik hodin, byl to pěkný opruz a nikomu se to nechtělo dělat. Nyní je to triviální úkon na pár sekund. Jinak plný git clone našeho projektu trvá po lokální síti skoro půl hodinu, takže je to dost velký balík (700MB, 20 tis. souborů).
-
Pokud hledáte opravdu něco, co má SVN a GIT z principu nemůže, tak Vám napovím.
Jsou to uživatelská práva.
V SVN můžete definovat uživatelská práva na úrovni jednotlivých adresářů, větví, tagů. atd.
Pokud do SVN musejí přistupovat různí přispěvatelé s různými právy k různým částem projektu, je SVN v tomto lepší.
Což je výhodné např. v korporátním prostředí, kde paranoidní manažer bude chtít části projektu mezi lidmi skrývat.
V GITu máte pouze Read nebo Read-Write pro celé repository. Možná ty neptrřičné zápisy do repoí jdou zjemnit nějakým hook skriptem, ale přečíst se dá prostě celé repository.
Jde to samozřejmě obejít rozdrobením na menší repository, kde ke každému bude mít práva jen skupinka vyvolených, ale je to nepohodlné (když chcete aktualizovat projekt, musíte pracovat s vícero repository ...).
A nemůžete dané schéma práv změnit, protože rozdělení na projekty už zafixováno.
Pokud pracujete v korporátní paranoidní sféře, která ráda pečlivě od sebe odděluje přispěvatele jemně definovaných částí projektu, bude SVN lepší.
Priznam se, ze nevim jak je to v gitu samotnem, ale kazda rozumna firma si poridi nejakou workflow nadstavbu, trebas ten Stash ktery je v kombinaci s Jirou neco naprosto neuveritelneho. Aktualne jsme ve firme v podstate 3 a nedokazu si predstavit fungovat jinak nez pres Pull requesty, branch per feature(hodne zjednodusene gitflow by nvie).
Ty jako velice omezeny liny a zabrzdeny programator neschopny prijimat rozumne zmeny a pracovat na sobe nedokazes posoudit prinos pro firmu. Jsi koule na noze a sef by ti mel dat jasny nuz na krk - mas na to tyden a hotovo jinak letis.
-
Třeba jedna věc, která mě v SVN dost žere: Dělám na nějaké feature, která změnila soubor X a ještě to není ve stavu, kdy bych to chtěl commitnout do repository. Pak to musím přerušit (čekání na součinnost / priorita) a chci dělat na věci, kde potřebuju taky změnit soubor X, třeba na nějakém jiném místě. No a máme problém, pánové. V GITu bych prostě commitnul částečnou implementaci, nepushoval. Pak bych se pustil do té nové věci a až bych ji dodělal, tak bych ji normálně commitnul a pushnul a mohl se vrátit k původní. V SVN můžu maximálně tak vytvořit vlastní branch (v repository používaném větším množstvím lidí nemyslitelné), nebo si to můžu vycheckoutovat do jiného adresáře, provést změnu tam, commitnout a zase smazat, ale to je dost práce a proč se drbat za levým uchem pravou rukou, když bych se tam mohl podrbat levou, že...
Tohle je presne ono. Tyden vyvijim feature, mezitim je potreba nejaky opravy na jinych features ktery se delaly drive, nejaky bugfix apod. Vsechno krasne zdokumentovany diky vetvim, pres cherry-pick dokazu bugfixes efektivne a rychle cpat do masteru, stejne tak cherry-pick veci ktery treba prida kolega a navzajem to souvisi. Vsechno dokazu resit lokalne a ven to davat az kdyz to vypada good. V SVN jsem to dokazal tak nejak kocirovat dokud jsem byl uplne sam a delal jen vyvoj samostatne a pak udrzbu samostatne. Ve chvili kdy prisly projekty ktere po spusteni kontinualne pokracuji a je tam v kazdou chvili vic pozadavku na opravy/vyvoj tak SVN konci s dechem.
-
Ten název Stash je tedy hodně nešťastný, když jde současně o příkaz gitu
-
Tohle je presne ono. Tyden vyvijim feature, mezitim je potreba nejaky opravy na jinych features ktery se delaly drive, nejaky bugfix apod. Vsechno krasne zdokumentovany diky vetvim, pres cherry-pick dokazu bugfixes efektivne a rychle cpat do masteru, stejne tak cherry-pick veci ktery treba prida kolega a navzajem to souvisi. Vsechno dokazu resit lokalne a ven to davat az kdyz to vypada good. V SVN jsem to dokazal tak nejak kocirovat dokud jsem byl uplne sam a delal jen vyvoj samostatne a pak udrzbu samostatne. Ve chvili kdy prisly projekty ktere po spusteni kontinualne pokracuji a je tam v kazdou chvili vic pozadavku na opravy/vyvoj tak SVN konci s dechem.
A o tom, že mohu mít v SVN naráz víc WC asi nevíte co? Takhle se to přece dělá ne?
-
nevim co myslis tim WC, ale jednou jsem zkusil jet v SVN ve dvou lidech ve trech branches a v podstate jsem vic resil konflikty apod nez programoval. otres.
-
A o tom, že mohu mít v SVN naráz víc WC asi nevíte co? Takhle se to přece dělá ne?
Jenže to pak musíte mít na disku jeden projekt vícekrát, u všech skriptů nebo nástrojů musíte rozlišovat, se kterou variantou projektu mají zrovna pracovat…
-
Zavrete to nekdo. Novak je troll, jak uz mockrat ukazal v jinych diskusich. Nechce od nas poradit, chce nam vsem dokazat, ze on vsechno vi lepe a vsechno dela lepe.
-
Osobně si myslím, že SVN a GIT jsou dvě různé věci, které čiště náhodou dělají pár podobných věcí.
Z diskuse je pro mne podstatnější dojem, že nějaký manažer došel k názoru, že se bude přecházet ze SVN na GIT a vidí za tím jen změnu SW. Asi jako místo MS Office tam dát LibreOffice. Jenže přechod mezi těmi dvěma není jen o SW a syntaxi, ale je to kompletní změna organizace práce. SVN je dobré ve věcech, které GIT neumí. To je jeden úhel pohledu. Je však nutné dodat, že GIT je neumí proto, že je nepotřebuje. Platí to i naopak, jsou věci, které SVN dělat nepotřebuje, takže je neumí.
Pokud si někdo myslí, že přechod od SVN na GIT bude jen o instalaci SW a přepsání skriptů na checkin / checkout apod., tak tvrdě narazí. GIT se sice v "SVN módu" používat dá (jsou o tom mraky návodů), ale výsledek bude bolet všechny a celkový přínos bude negativní. Pokud ale projekt bude pojat jako "zásadní změna organizace práce se zdrojovými kódy" a opravdu změní procesy, pak GIT může představovat výhodu. Záleží na množství aktualizovaných souborů, počtu vývojářů, malosti změn a četnosti změn. Pokud se hrabu jen v desítce souborů, hrabu se v tom jen já a brácha, skoro vždy je to změna přes desítky řádků a čas mezi funkčními verzemi je spíše ve dnech, tak GIT nepomůže. GIT je způsob jak udržet řád v chaosu. Pokud ale na vstupu není chaos, tak je zbytečný.
-
Z diskuse je pro mne podstatnější dojem, že nějaký manažer došel k názoru, že se bude přecházet ze SVN na GIT a vidí za tím jen změnu SW. Asi jako místo MS Office tam dát LibreOffice. Jenže přechod mezi těmi dvěma není jen o SW a syntaxi, ale je to kompletní změna organizace práce. SVN je dobré ve věcech, které GIT neumí. To je jeden úhel pohledu. Je však nutné dodat, že GIT je neumí proto, že je nepotřebuje. Platí to i naopak, jsou věci, které SVN dělat nepotřebuje, takže je neumí.
Pokud si někdo myslí, že přechod od SVN na GIT bude jen o instalaci SW a přepsání skriptů na checkin / checkout apod., tak tvrdě narazí. GIT se sice v "SVN módu" používat dá (jsou o tom mraky návodů), ale výsledek bude bolet všechny a celkový přínos bude negativní. Pokud ale projekt bude pojat jako "zásadní změna organizace práce se zdrojovými kódy" a opravdu změní procesy, pak GIT může představovat výhodu. Záleží na množství aktualizovaných souborů, počtu vývojářů, malosti změn a četnosti změn. Pokud se hrabu jen v desítce souborů, hrabu se v tom jen já a brácha, skoro vždy je to změna přes desítky řádků a čas mezi funkčními verzemi je spíše ve dnech, tak GIT nepomůže. GIT je způsob jak udržet řád v chaosu. Pokud ale na vstupu není chaos, tak je zbytečný.
Nerozhoduje to manažer, ale vedoucí vývoje poté, co se v jiných částech té firmy Git používal několik (AFAIK šest) let a zřejmě se tedy osvědčil (disclaimer: už v té firmě pár let nejsem)
-
Z diskuse je pro mne podstatnější dojem, že nějaký manažer došel k názoru, že se bude přecházet ze SVN na GIT a vidí za tím jen změnu SW. Asi jako místo MS Office tam dát LibreOffice. Jenže přechod mezi těmi dvěma není jen o SW a syntaxi, ale je to kompletní změna organizace práce. SVN je dobré ve věcech, které GIT neumí. To je jeden úhel pohledu. Je však nutné dodat, že GIT je neumí proto, že je nepotřebuje. Platí to i naopak, jsou věci, které SVN dělat nepotřebuje, takže je neumí.
...
Pokud se hrabu jen v desítce souborů, hrabu se v tom jen já a brácha, skoro vždy je to změna přes desítky řádků a čas mezi funkčními verzemi je spíše ve dnech, tak GIT nepomůže. GIT je způsob jak udržet řád v chaosu. Pokud ale na vstupu není chaos, tak je zbytečný.
S timto hodnocenim ja extremne silne nesouhlasim. Muzete treba napsat konkretne, v cem je "SVN dobre ve vecech ktere GIT neumi"? Nebo co proboha myslite slovy "jsou veci, ktere SVN delat nepotrebuje, takze je neumi"?
-
S timto hodnocenim ja extremne silne nesouhlasim. Muzete treba napsat konkretne, v cem je "SVN dobre ve vecech ktere GIT neumi"? Nebo co proboha myslite slovy "jsou veci, ktere SVN delat nepotrebuje, takze je neumi"?
SVN kupříkladu neumí dělat lokální snapshoty stavu souborů. Máte do něj ukládat finální verzi změn, na undo historii používejte buď textový editor, kusy kódu místo mazání komentujte, nebo si ukládejte kopie průběžně někam na disk. Oproti tomu jedna z klíčových vlastností GITu je, že si můžete klidně 100x za den "lokálně uložit" stav rozpracované práce. Upravím několik souborů, přeložím, spustím a zjistím, že tudy cesta nevede. GIT mi umožní se vrátit rychle k předchozímu stavu a zkusit to znovu a jinak. Těch "savepointů" si nasázejte klidně desítky a GIT vám s tím rád a efektivně pomůže. SVN nemá ambice vám s tímhle pomoci. Tam se přepokládá, že buď nahráváte hotovou verzi, nebo verzi tak jak je, když jdete domů (aby na tom někdo jiný mohl pokračovat v případě, že vyhrajete ve Sportce). Pokud někdo zvyklý na GIT začne používat SVN i tímhle způsobem (uploadovat každých 10 minut a opět to zase mazat), tak narazí na tuhý odpor. Situaci popíše "neumí to". No, neumí, ale ani se nesnaží.
Co SVN naopak umí, a je to tam schválně, je detailní řízení přístupových práv. GIT má práva jen na dost vysoké úrovni, takže buď musíte projekt rozkouskovat na několik repozitářů, nebo na práva rezignovat a prostě jen kontrolovat, zda někdo nedělá commit do něčeho, kam ho pustit nechcete. Dá se to sice označit jako "GIT přístupová práva neumí", ale faktem je, že se o to prostě ani nesnaží.
-
Karle, nekolikrat jsem tady psal, ze samotny git pouziva (IMHO) maloktera firma. Vetsina ma nejaky nastroj nad ktery prava pochopitelne umi. Protoze to podstatne neni jen samotne verzovani a ukladani historie, ale cele workflow jak se kod dostava z klavesnice programatora na produkcni nasazeni.
-
Karle, nekolikrat jsem tady psal, ze samotny git pouziva (IMHO) maloktera firma. Vetsina ma nejaky nastroj nad ktery prava pochopitelne umi. Protoze to podstatne neni jen samotne verzovani a ukladani historie, ale cele workflow jak se kod dostava z klavesnice programatora na produkcni nasazeni.
Nevidím tady rozpor s mým konstatováním, že SVN se snaží o něco trochu jiného než GIT a že jejich používání vyžaduje jiný přístup. Spíše mi to přijde, že mi to potvrzujete. Jestli vám vadí, že píšu, že git neumí přístupová práva, tak se zkuste podívat na co/koho reaguji. Belzebub tak nějak podsouvá, že minimálně jeden z těch nástrojů umí úplně vše, co ten druhý. Tak jsem dal dva příklady toho, co jeden umí dobře a druhý moc ne. Navíc jsem přidal názor, že to není neschopností autora toho nástroje, ale prostě důsledkem toho, že to do svého nástroje ani dát nechtěl.
Fakt, že GIT "není schopen řídit přístupová práva" považuji za vlastnost. Ta v praxi nepůsobí velké problémy, protože to uživatele buď moc netrápí, nebo to dokáže řešit jinými prostředky (třebas tím, že si na internetu najde, nebo sám napíše, "nějaký nástroj nad který práva pochopitelně umí"). V každém případě "GIT out of the box" to neřeší, takže pokud to nutně chcete, tak musíte sehnat někoho, kdo tomu rozumí a doporučí vám nějaký další nástroj, nebo někoho kdo tomu opravdu hodně dobře rozumí a ten nástroj vám napíše (no, nástroj, ono toho kódu zas tak moc být nemusí, ale i když je to jen pár pitomých scriptů, tak někdo to napsat musel).
-
Fakt, že GIT "není schopen řídit přístupová práva" považuji za vlastnost. Ta v praxi nepůsobí velké problémy, protože to uživatele buď moc netrápí, nebo to dokáže řešit jinými prostředky (třebas tím, že si na internetu najde, nebo sám napíše, "nějaký nástroj nad který práva pochopitelně umí"). V každém případě "GIT out of the box" to neřeší, takže pokud to nutně chcete, tak musíte sehnat někoho, kdo tomu rozumí a doporučí vám nějaký další nástroj, nebo někoho kdo tomu opravdu hodně dobře rozumí a ten nástroj vám napíše (no, nástroj, ono toho kódu zas tak moc být nemusí, ale i když je to jen pár pitomých scriptů, tak někdo to napsat musel).
Spíš bych řekl, že klasické řešení Gitu (DVCS obecně) je mít vícero repozitářů. Pak je na správci/vedoucím projektu nebo produktu, které commity pomocí cherry-picku vezme do hlavního repozitáře. Omezení přístupu pro čtení se udělá tak, že se prostě ostré věci dají do speciálního repozitáře, kam nemá přístup každý. Buďto se to dá rozdělit a funguje to i bez těch částí, kam je omezený přístup, nebo to samostatně nefunguje a pak je ten částěčný přístup vývojáři v podstatě k ničemu.
-
Lidi co programují pro Windows by měli zvážit, jestli pro ně není lepší Mercurial, který má lepší tooling, viz. třeba TortoiseHg. Git je na Windows přece jenom pomalejší než na linuxu, ale o Mercurialu to neplatí. Výhodou DVCS je že když si člověk často commituje tak potom ten merge je jistější, navíc kdo má po vás kontrolovat soubor který je v diffu totálně jiný než jeho předchůdce, byť se k němu došlo přes sérii triviálních změn, například podle pravidel pro continous refactoring od Fowlera. Je lepší když si reviewer projde několik menších diffů než jeden velký guláš...
Jinak IDE pluginy (do Visual Studia) pro Mercurial a SVN jsou prostě stále o trošičku lepší a odladěnější, což je také nejsilnější argument proti GITu. Neřešte SVN vs. GIT, řeště proč GIT když je tady Mercurial!
-
A o tom, že mohu mít v SVN naráz víc WC asi nevíte co? Takhle se to přece dělá ne?
Jenže to pak musíte mít na disku jeden projekt vícekrát, u všech skriptů nebo nástrojů musíte rozlišovat, se kterou variantou projektu mají zrovna pracovat…
Tohle beru za vyhodu, protoze me to prinuti tvorit projekt relokovatelny. Lze jej pak nahrat do libovolne slozky a nebo se muze stat soucasti jineho projektu treba zkrze externals.
-
Nekdy mne prekvapuje, co vsechno se jeste resi v roce 2014.
-
A o tom, že mohu mít v SVN naráz víc WC asi nevíte co? Takhle se to přece dělá ne?
Jenže to pak musíte mít na disku jeden projekt vícekrát, u všech skriptů nebo nástrojů musíte rozlišovat, se kterou variantou projektu mají zrovna pracovat…
Tohle beru za vyhodu, protoze me to prinuti tvorit projekt relokovatelny. Lze jej pak nahrat do libovolne slozky a nebo se muze stat soucasti jineho projektu treba zkrze externals.
Já jsem dosud všechny programy dělal tak, že šly spustit pouze z /home/inkvizitor/superprojekt. Od pondělka přejdu na svn a pak už mě nic nezastaví!
OMG