Proč bych měl přejít ze SVN na GIT? (vážně)

[Ondřej Novák]

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

[Reklama]

[Ziktofel]

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

[Filip Jirsák]

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.

[belzebub]

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".

[Filip Jirsák]

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í.

[Reklama]

[Ondřej Novák]

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.

[Sten]

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é

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.

[Makovec]

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.

[Ondřej Novák]

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?

[to_je_jedno]

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.

[to_je_jedno]

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.

[dustin]

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.

[Ondřej Novák]

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)

[Ziktofel]

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

[dustin]

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.