Open source hra Oh My Git! vás naučí používat systém správy verzí Git. Hra je napsaná s použitím engine Godot a funguje v Linuxu, macOS a Windows. Hotové balíčky můžete stáhnout z itch.io.
Zdrojové kódy jsou na GitHubu a hra je zveřejněna pod licencí Blue Oak Council. Hra má zatím 44 úrovní, ale můžete si lehce dodělat další úrovně.
K čomu je to dobré? Všetci, s ktorými som kedy spolupracoval, pracovali s Gitom presne takto:
http://xkcz.cz/1597-git/
Tak tohle naštěstí kolem sebe nevidím. Souhlasím ale s tím, že tahle "škola hrou" není cesta, kterou bych volil k naučení.
Pouzivam zaroven svn i git. Temer denne resim v gitu nejake "conflict" zatimco v svn se mi to stalo posledne vloni. Jo, jsou to jine technologie ale pro mne je svn lepsi. Dokonce pozoruji takovy zajimavy jev ze v soukromi mi vsichni davaji za pravdu ale jak prijde k nejakem verejnemu vyhlaseni tak maximalne reknou "neumim to pouzivat". Proste takovy groupthink.
K tomu komixu ano. Nekdy je lepsi to radeji odsunout bokem a vyresit to nad novym projektem znova nez se bat ze to podelam protoze je to desne neintuitivni. Nakonec jsem se naucil davat "stash" pred "pull" a "stash pop" po nem a mam to jako script.
25. 4. 2021, 12:03 editováno autorem komentáře
Tak zrovna SVN bych dnes už zpátky nebral ani omylem (i když proti CVS to byl nepochybně krok vpřed, o tom žádná). Pravda SVN je mnohem jednodušší, jediný problém s ní mám v tom, že když se podělá (jednou se mi stalo, že nějakou dobu před odchodem do křemíkového ráje jeden z disků občas přečetl něco jiného než měl zapsáno) tak pořádně. Nakonec to skončilo zaarchivovanými backupy a importnutím aktuálního stavu projektu do gitu, který je z principu mnohem robustnější, od té doby klid.
ad komix - mnó to se mi stalo taky párkrát, vždycky to bylo něco na téma "neumím to používat mnohem víc, než jsem myslel". Typická chyba - řeším víc věcí najednou, zezačátku "trivialita, to mám hned, kašlu na branchy, opravím, testnu commitnu a jde se na pívo", pak zjistím že jsem totálně zamotanej co z toho je hotové, co ne, takže git diff, git stash, vim rozdil.diff, patch <rozdil.diff ...
Pořád mám k dispozici git reflog, git rebase -i, git reset (případně i --soft nebo --hard), v případě opravdu masivních repozitářů se dá spousta věcí zachránit (hlavně časově) použitím hromadného cherry-picku namísto rebase. Věřím, že i bisect má svoje místo, ale ten jsem osobně nikdy nevyužil.
Co mi na Gitu chybí asi nejvíc, je pohodlnější práce s patchi pomocí git am, nějaký nástroj, který by pomohl ty změny usadit v kontextu aktuálního HEADu. Jinak za mě v podstatě samá pozitiva a sociální jistoty, pokud není repo přecpané velkými binárními soubory, které se často mění.
To je ono. V gitu mame spustu prikazu jak resit veci ktere se v SVN nedeji. Tam jsem si spoustu let vystacil s up/log/clear. A conflict byl jednou za rok. V git se ucime branche, merge, rebase. Ja vim ze to z povahy veci nejde. Git nema centralni server SVN bez neho nejde.
Ale tak rekneme si to otevrene to ze git nema server je jeho vyhoda ktera usti v conflicty.
To není záležitost toho, zda máte nebo nemáte server. Jde o způsob práce – a Git prostě umožňuje mnoho způsobů práce, které jsou s SVN obtížné nebo nemožné.
Git je založený na tom, že se snažíte mít po většinu času v repository funkční kód. SVN je založené na tom, že někde máte hromadu zdrojového kódu, kam všichni sypou svůj kód a neřeší, co se na té hromadě děje. Pak se jednou za čas tahle hromada vezme a snaží se to ustabilizovat. Pro tenhle způsob práce Git moc vhodný není.
Git je hodně flexibilní, jeho merge strategie jdou nastavit, ale je klidně možné, že máš nějaký use case, kde SVN fakt řeší konflikty dvou změněných verzí souboru líp. Rád bych to viděl naživo, nemáš nějaký příklad?
Jinak, co se týče toho "groupthinku", možná žiješ v nějaké zvláštní bublině - jelikož je svět SW vývoje brutálně fragmentovaný, ty davy fanoušků SVN by podle mě už dávno byly někde vidět, ti odvážlivci by strhli lavinu.
25. 4. 2021, 12:54 editováno autorem komentáře
Neustale resime tohle:
8:00 - vsichni si dame pull
8:20 - dam commit
8:25 - da commit kolega + push
8:30 - dam pull nebo push a problem mam ja
Pricemz logicky by mel mit problem ten kolega. Kdyz se divate podle casove osi. Tohle se Vam na svn nestane protoze to porad jede proti serveru a tak toho kolegu upozorni ze nemuze delat commit protoze tam je neco noveho.
Pak je log plny rebase, merge, resolve conflict a pod. Ja vim mame to pouzivat jinak. V prekladu musime se prizpusobit.
25. 4. 2021, 17:30 editováno autorem komentáře
Tenhle problém vám vyřeší správná strategie používání Gitu (chápu, namítnete, že u SVN nic takového netřeba :-) ). Každý si pushujte do vlastní větve, kterou v momentě, kdy danou funkčnost či opravu považujete za hotovou, někdo zodpovědný zamerguje do develop/master větve. Ano, v momentě mergování mohou vznikat konflikty, ale nic, co by se nedalo obvykle snadno řešit (vždy můžete před odevzdáním udělat rebase nad master). Záleží samozřejmě také na tom, jak dobře máte rozdělenou práci (aka jak moc si jeden druhému lezete do zelí).
SVN jsem používal před lety a již bych se k němu nevrátil. Samozřejmě je možné, že jsem nepochopil jeho filozofii, protože v té době jsem se řadil mezi "sotva odrostlé cucáky". Nicméně velkou výhodu Gitu vidím v tom, že kromě lokální kopie existuje i ta na serveru, takže když u sebe repozitář totálně zničím (což už se několikrát podařilo), vždy existuje záloha aniž bych se musel uchylovat ke komiksovému postupu.
Jak by mohl mít problém kolega, když v době jeho pushe máte váš commit stále jen u sebe a tedy o něm nikdo další neví?
Jinak rebase v logu nijak extra nevidíte - jedná se jen o přeskládání commitů.
Přizpůsobit se musíte každému nástroji, který používáte, i té SVN. V tomhle scénáři stačí po commitu dát push, nicméně nevidím problém ani v tom, co jste psal. Prostě pokud děláte paralelní úpravy v jednom souboru, tak musíte řešit konflikty.
Lepsi priklad je tenhle:
8:00 - vsichni pull
8:10 - kolega commit+push
8:20 - udelam commit
Pak jdu delat push, ale to nejde. Git mi spravne rika ze tam je neco noveho mam udelat pull. Udelam pull a dostanu conflict. A tady je situace kdy novacik zacne panikarit a senior zveda oboci protoze vi ze prave strati 15min mozna vic tim aby to vyresil. Resenim je samozrejme dalsi commit v kterem neni nic! Parada.
Tohle nesnasim proto udelam vedle clone, meldem prehazim moje zmeny a pak rychle cisty commit. Na tohle narazi ten komix. A neni to o neschopnosti vyvojare ale o tom jak krkolomne git funguje.
PS: Ja vim jak funguju branche, merge, rebase a vse kolem. Sam to resim skrz stash. Jen ukazuji ze zde mame system ktery mne nuti neco delat tak jak nechci. Asi bych se s tim smiril, kdyby ale nebyl ten priklad s SVN kde se to nedeje.
25. 4. 2021, 20:51 editováno autorem komentáře
To je přesně to, co jsem psal. Do repository nedáváte hotové změny (jako v gitu), ale je to hromada kódu, kam na konci pracovní doby commitnu, co mám zrovna pod rukama – bez ohledu na to, jestli to bude fungovat.
Pokud děláte v 8:00 všichni pull ze stejné větve, nepoužíváte způsob práce, pro který je git navržen. A ten způsob práce dává mnohem větší smysl, než commit na konci pracovní doby.
Pokud chcete git používat jako SVN, opravdu to nefunguje dobře. V tom s vámi naprosto souhlasím.
Jo to mate pravdu. Nedelame to spravne. A zjevne nejsme samy jinak by nevznikali takove tutorialy a ruzne graficke hry pro pochopeni.
PS: V tymu pracujeme tak ze commit je bud nova funkcionalita nebo oprava. Nikdy nedavame do repo nedodelek nebo neco co je rozpracovano. Proto muzeme delat rano pull protoze vime ze cele to funguje, kdyz ne tak si to musi dotycny hned opravit.
Zadne sysleni v branch kdy potom musi sedet cely tym aby se povedlo rebase.
> PS: V tymu pracujeme tak ze commit je bud nova funkcionalita nebo oprava. Nikdy
> nedavame do repo nedodelek nebo neco co je rozpracovano. Proto muzeme delat rano
> pull protoze vime ze cele to funguje, kdyz ne tak si to musi dotycny hned opravit.
My zase celkem rádi děláme menší commity, protože v případě, že se při implementaci vydáme špatným směrem, můžeme se snadno vrátit v čase.
> Zadne sysleni v branch kdy potom musi sedet cely tym aby se povedlo rebase.
To vidím jako krajní případ, který je způsobený i tím, že buď nejsou rozumně rozdělené úkoly mezi členy týmu, nebo není zdrojový kód rozdělen/navržen dostatečně modulárně. Na počátku projektu určitě něco takového nastat může, ale později (když si zdroják "sedne") fakt výjimečně. Zvláště pokud se do masteru nemerguje více větví najednou.
@Martin Dráb
V teamu je nás málo, ale běžně (téměř denně) organizuje práci tak, aby to sedělo i s ohledem na git verzování ... dalo by se říct, že přidávání kusů kódu pomocí gitu je vlastně takový náš styl práce, mustr, podle kterého se i organizují úkoly. A když mají dva lidi dělat "blízko", tak se prostě dohodne co, kdy, kdo a jak, celé to zastřeší úkoly v Jira ... Zatím s tím problém nebyl, dva lidi na stejně nemohou dělat přímo na tom samém kódu, git ne-git ...
25. 4. 2021, 23:25 editováno autorem komentáře
@Zdeno Sekerák
Podívejte se na to jinak. Až se rozhodnete něco dávat do společné větve, tak byste měl u sebe mít lokálně poslední verzi a na ni navěsit svůj kód. Na datumu nezáleží.
Takže stáhnete aktuální reference, pomocí pull --rebase (jak říká @Ondřej Satai Nekola) a teprve pak můžete vůbec vyzkoušet, jestli to co chcete dát do společné verze vůbec má smysl.
Ten problém, který s tím lidi mají je ten, že si musí správnost/aktuálnost kódu a co kde kdo zrovna dělá ohlídat sami - git to za nikoho neudělá, protože není vědma. Ostatní potřebují přidávat a proto je potřeba se domluvit. Pak taky začne mít další smysl dodržovat např. SOLID a striktně oddělovat featury/moduly, což umožňuje, aby programátoři mohli pohodlně pracovat odděleně. Pokud to nejde, pak je potřeba dělat co nejvíce co nejmenších změn. To ale není komplikace, to naopak zaručuje, že programátorský team musí mít dobrou kontrolu nad tím, co se dělá a přidává.
25. 4. 2021, 23:10 editováno autorem komentáře
Jo a jde nastavit default:
git config --global pull.rebase true
Jinak třeba viz https://git-scm.com/book/en/v2/Git-Branching-Rebasing
Já tedy přechod ze SVN na GIT (na několika projektech) vnímal jako dobrý posun vpřed. Teď používám všude GIT a neznám nikoho, kdo by prezentoval názor, že SVN by bylo lepší.
Co se týče množství konfliktů, tak to je primárně dáno tím, nakolik paralelně pracujete, případně architekturou projektu (jak moc často je třeba měnit nějaké sdílené soubory). Teď už se nepamatuji, jestli SVN nedělá to, že by nekolidující změny v jednou souboru tiše zmergovalo samo, ale není to úplně košer přístup.
Ja osobne mam problem s tym, ze GIT nema pod linuxom vhodne GUI. Kazdy ho strasne pouziva cez prikazy a potom datluju do klavesnice. Ja si chcem dat klik, klik klik a vidit vsetko potrebne. Zatial najdalej je podla mojich skusenosti asi GitAhead ale aj tam som uz prisiel na problem, ktory nevedel resolvnut a musel som cez commandline. Neviem preco sa tak vsetci brania vizualu. Kedysi som pouzival mercurial s tortoise a bolo to super. Hned sa dalo lahko zo rientovat v komitoch bez toho aby som cosi datloval do klavesnice. To bolo pred 6 rokmi a v linuxe nic take doteraz neexistuje.
Plus niekedy sa mi stava, ze sa dostanem do tree conflictu, ktory sa celkom blbo resolvuje alebo si dam po mergnuti pull a vidim, zmeny ktore som uz mergoval (neviem ci to robi len gitahead alebo je to feature gitu). Neviem, git existuje kolko? 15 rokov? Clovek by cakal, ze s tym nebude mat tolko problemov po takej dobe. S SVN som nikdy nemusel riesit tazke problemy. Tu sa kazdy boji aby sa mu git nerosypal, lebo by to uz nemusel dat dohromady.
K čemu Git používáte? Podle mne má mít vhodné UI pro Git ten nástroj, ve kterém edituji soubory – třeba IDE. Jinak GitKraken je i pro Linux a připadá mi docela schopný. Asi žádný GUI nástroj nebude nikdy pokrývat všechny možnosti Gitu, Git je příliš rozsáhlý. Navíc je rozumné v tom GUI nástroji mít i podporu souvisejících nástrojů jako GitHub, Bitbucket, GitLab – a množství věcí, co by ten nástroj mohl umět, pořád jen roste.
Me teda GitKraken prisel jako moloch - dlouho se spoustel a zabiral priserne moc ramky.
Taky mam problem najit vhodny GUI pro Git. Ja bych chtel poradne Git GUI pro veci co nepouzivam moc casto, a tedy si nepamatuju prikaz nebo poradi argumentu. Nakonec pouzivam GitAhead, ale citim ze to neni to prave orechove a kdyz potrebuju neco specialnejsiho, stejne googluju.
Za mne Git GUI nemusi umet Github, Gitlab - na to mam ssh a nastaveny remote. Git GUI by mel umet poradne hlavne ten git, s tim ze dopredu chapu co ktere tlacitko udela (coz je problem tak poloviny Git GUI programu co jsem zkousel).
ČLÁNKY DO MAILU