Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Rugo 30. 06. 2017, 07:59:49
-
Poradíte někdo, jak na správu projektu s Git? Resp. kde najím nějak rozumě vysvětleno, jak se to vlastně chová? Několikrát jsem ho zkoušel, ale vždycky se to chovalo nějak "divně", jinak, než bych z popisu čekal.
Situace je zavedení repozitáře mezi asi tři lidi, projekty v C, integrace s eclipse.
Moje představa by byla jeden centrální repozitář na serveru plus u každého lokálně.
Na první pohled to vypadá jednoduše, ale nikdy mi to nijak nefungovalo, zvláště i integrací do IDE.
-
Poradíte někdo, jak na správu projektu s Git? Resp. kde najím nějak rozumě vysvětleno, jak se to vlastně chová? Několikrát jsem ho zkoušel, ale vždycky se to chovalo nějak "divně", jinak, než bych z popisu čekal.
Situace je zavedení repozitáře mezi asi tři lidi, projekty v C, integrace s eclipse.
Moje představa by byla jeden centrální repozitář na serveru plus u každého lokálně.
Na první pohled to vypadá jednoduše, ale nikdy mi to nijak nefungovalo, zvláště i integrací do IDE.
Zde https://knihy.nic.cz/ je ke stažení knížka ProGit, kde je vše vysvětleno. Integrace do konkrétního IDE si musíte vyřešit sami, ale git se perfektně používá i z řádky (a na funkci to nemá vliv).
-
Neni to nic sloziteho, nejlepe kdyz vam nekdo ukaze jak se branchuje, merguje a rebasuje. To je asi vse co vam na zacatek staci. Z IDE doporucuji SourceTree, je daleko nejlepsi. https://www.sourcetreeapp.com/ Ma jen jedinou vadu - neni linux verze. Git je nejlepe provozovat s webovym backendem typu Gihub, Bitbucket, Stash atd. Ale to je uz spise pro vetsi projekty nebo korporace.
-
Poradíte někdo, jak na správu projektu s Git? Resp. kde najím nějak rozumě vysvětleno, jak se to vlastně chová? Několikrát jsem ho zkoušel, ale vždycky se to chovalo nějak "divně", jinak, než bych z popisu čekal.
Co to znamená "divně"? :)
-
Silno doporučujem na začiatku vykašľať sa na integráciu do IDE, aj na Git GUI a používať Git výlučne z príkazového riadku. IDE väčšinou implementuje len obmedzený subset príkazov, ktorý je spoločný pre rôzne verzovacie systémy. Navyše chybové hlášky IDE (a často aj Git GUI) neodovzdá ďalej správne, alebo neodovzdá vôbec. Človek sa potom diví a zlostí, prečo mu to nejde, až kým to neskúsi z CLI, kde je chybová hláška kryštálovo jasná a ak náhodou nie, tak sa dá ľahko skopírovať do googla.
A samozrejme knihu ProGIT - PDF je zadarmo a dostupné hneď, takže sa nie je na čo vyhovárať.
-
Několikrát jsem ho zkoušel, ale vždycky se to chovalo nějak "divně", jinak, než bych z popisu čekal.
Škoda, že nenapíšeš nějaký konkrétní příklad. Základní principy gitu jsou tak jednoduché, že pokud jsi byl něčím překvapen, tak jsi nejspíš ten základní princip špatně pochopil. Třeba kdybys napsal konkrétní příklad, stačily by dvě tři dobře mířené věty a měl bys aha-zážitek, po kterém bys tomu už úplně rozuměl :)
-
Zakladni principy gitu jsou sice jednoduche, ale jejich spravne uziti a rozhodnuti kdy co pouzit tak jednoduche rozhodne neni. Git nema na jednu situaci jen jedno reseni. Clovek musi nejen vedet co chce udelat, ale podle ruznych okolnosti se musi rozhodnout jak to chce udelat. Vysledek urcite operace sice bude stejny z pohledu zdrojoveho kodu, ale muze byt rozdilny treba z pohledu zachovane historie uprav. A toto pro zacatecnika rozhodne jednoduche neni.
Ja bych doporucil jednak nejake ctivo o tech zakladnich operacich nad git repozitarem a pak neco o "git flow" tedy o tom, jak "ridit" projekt v gitu. Ale idealni je se s nekym pobavit, kdo zodpovi konkretni otazky co a jak delat.
Na "git flow" je treba tento web https://datasift.github.io/gitflow/IntroducingGitFlow.html . Ja sam za sebe rikam, ze tohle neuvadim jako jediny spravny pristup k rizeni projektu, ale spis jako ukazku toho, jak git muze pracovat a nasmerovani jak to muze vypadat. Myslim ze treba sourceTree ma zrovna pro tenhle model primo podporu.
Byt vami, zalozil bych si nejaky pokusny repozitar na serveru a dva lokalni repozitare, ktere budou sledovat to repo na serveru a udelal si par pokusu nad nejakymi textovymi soubory. Commitovani a pushovani zmen, fetch, merge, rebase, pull, vetveni atd. Az se vam bude aspon rozumne zdat, ze vite co delate, nasadil bych to na projekt. Je to rozhodne lepsi, nez do toho jit pohlave. Z meho pohledu proste git neni tak primocary, aby "prumerny" programator hned vedel, jak s nim spravne zachazet. On totiz ani v urcitych situacich nema jedine "spravne reseni", coz pro novacka muze byt docela zlo :-(.
-
https://try.github.io/levels/1/challenges/1
http://learngitbranching.js.org/
-
Zakladni principy gitu jsou sice jednoduche, ale jejich spravne uziti a rozhodnuti kdy co pouzit tak jednoduche rozhodne neni. Git nema na jednu situaci jen jedno reseni. Clovek musi nejen vedet co chce udelat, ale podle ruznych okolnosti se musi rozhodnout jak to chce udelat. Vysledek urcite operace sice bude stejny z pohledu zdrojoveho kodu, ale muze byt rozdilny treba z pohledu zachovane historie uprav. A toto pro zacatecnika rozhodne jednoduche neni.
To je pravda. Já jsem si tu poznámku automaticky přeložil jako "byl jsem překvapený, že ten příkaz udělal něco jiného, než jsem očekával" a nenapadla mě možnost "chtěl jsem řídit projekt, ale nevěděl, jak dosáhnout XYZ".
-
Poradíte někdo, jak na správu projektu s Git? Resp. kde najím nějak rozumě vysvětleno, jak se to vlastně chová? Několikrát jsem ho zkoušel, ale vždycky se to chovalo nějak "divně", jinak, než bych z popisu čekal.
Situace je zavedení repozitáře mezi asi tři lidi, projekty v C, integrace s eclipse.
Moje představa by byla jeden centrální repozitář na serveru plus u každého lokálně.
Na první pohled to vypadá jednoduše, ale nikdy mi to nijak nefungovalo, zvláště i integrací do IDE.
Uz som to tu pisal aj minule, ale dam repete.
Aby ste vedeli spravne pracovat s Gitom, musite si zapamatat a pochopit dva nasledujuce body:
- Git si ziadne zmeny nepamata
- Git nie je verzionovaci nastroj
Akokolvek neintuitivne to vyznieva, oba body su fakty a pravdive.
Ked zacnete s Gitom od opacneho konca, t.j. myslite si, ze je to verzionovaci nastroj a ide od rebaseovania, mergegovania, cherry pickovania a nerozumiete tymto dvom zakladnym bodom, vzdy v tom budete mat gulas.
Ked ste tieto dva body stravili, mozete si precitat Pro git book (https://git-scm.com/book/en/v2).
-
- Git si ziadne zmeny nepamata
- Git nie je verzionovaci nastroj
To je zase nějaké dementní slovíčkaření?
-
- Git si ziadne zmeny nepamata
- Git nie je verzionovaci nastroj
To je zase nějaké dementní slovíčkaření?
Nie, iba implementacny detail.
-
- Git si ziadne zmeny nepamata
- Git nie je verzionovaci nastroj
To je zase nějaké dementní slovíčkaření?
Nie, iba implementacny detail.
git log -p
bere historii změn odkud, když si git žádné změny nepamatuje?
-
- Git si ziadne zmeny nepamata
- Git nie je verzionovaci nastroj
Dafuq? Git je distribuovana mnozina commitu v case (timestamp), prostoru (branch) a dimenzi (uloziste). Zbytek jsou jen atributy :-)
-
- Git si ziadne zmeny nepamata
- Git nie je verzionovaci nastroj
To je zase nějaké dementní slovíčkaření?
Nie, iba implementacny detail.
git log -p
bere historii změn odkud, když si git žádné změny nepamatuje?
Sup, sup, precitat knihu, ktoru som linkoval - evidentne mate medzery.
-
- Git si ziadne zmeny nepamata
- Git nie je verzionovaci nastroj
Dafuq? Git je distribuovana mnozina commitu v case (timestamp), prostoru (branch) a dimenzi (uloziste). Zbytek jsou jen atributy :-)
Zeby cas pri commitoch v gite nehral absolutne ziadnu rolu, lebo ved Merkle DAG? Ditto ako kolega gll - ta kniha je fakt dobra.
Inak ked vidim slova "cas" a "distribuovana" v jednej vete, svieti mi bullshitmeter na cerveno. Lamportove hodiny a vektorove hodiny vam asi nic nehovoria. Nie ze by ich v gite bolo treba...
-
- Git si ziadne zmeny nepamata
- Git nie je verzionovaci nastroj
To je zase nějaké dementní slovíčkaření?
Nie, iba implementacny detail.
celkom ma zaujima ako toto dopadne, davam si sem kotvu
-
- Git si ziadne zmeny nepamata
- Git nie je verzionovaci nastroj
Dafuq? Git je distribuovana mnozina commitu v case (timestamp), prostoru (branch) a dimenzi (uloziste). Zbytek jsou jen atributy :-)
ne neni, git je strom snapshotu ... nic vic
-
m:
takže dementní slovíčkaření a implementační detail. Protože strom snapshotů je popsatelný jak pomocí vrcholů (tedy stavů projektu), tak i pomocí hran (změn mezi vrcholy) a jednoho stavu. Tedy že to git ukládá pomocí vrcholů je jen implementační detail.
A btw. ještě navíc blbé slovíčkaření, protože "verzovací nástroj" je něco, co ukládá verze: tedy jednotlivé stavy projektu a jejich vztahy - tedy strom snapshotů.
trupik: commandline je skoro nutné ovládat, ale na Git Gui nedám dopustit. Možná když je někdo super pečlivý, tak se mu to nestává, ale pokud je třeba udělat z jedné sady změn dva commity, tak to dělat pomocí commandline je pěkná pakárna.
-
m: Začátečníkovi bych GitFlow silně nedoporučoval. To se zdaleka nehodí pro všechny případy a všechny "releasovací modely" a při spoustě nasazení gitu to jen hází klacky pod nohy.
-
Dafuq? Git je distribuovana mnozina commitu v case (timestamp), prostoru (branch) a dimenzi (uloziste). Zbytek jsou jen atributy :-)
ne neni, git je strom snapshotu ... nic vic
To je jen implementace vyseuvedene vety.
-
m:
takže dementní slovíčkaření a implementační detail. Protože strom snapshotů je popsatelný jak pomocí vrcholů (tedy stavů projektu), tak i pomocí hran (změn mezi vrcholy) a jednoho stavu. Tedy že to git ukládá pomocí vrcholů je jen implementační detail.
A btw. ještě navíc blbé slovíčkaření, protože "verzovací nástroj" je něco, co ukládá verze: tedy jednotlivé stavy projektu a jejich vztahy - tedy strom snapshotů.
trupik: commandline je skoro nutné ovládat, ale na Git Gui nedám dopustit. Možná když je někdo super pečlivý, tak se mu to nestává, ale pokud je třeba udělat z jedné sady změn dva commity, tak to dělat pomocí commandline je pěkná pakárna.
Ale prosim vas, keby bol "verzovací nástroj neco co uklada verze", tak je nim aj ZFS. Alebo si kopirujte cely projekt po kazdej zemene do samostatneho adresara. Kludne si kopie ukladajte aj v strome.
Taky subtilny a nepodstatny detail pri "verzovacích nástrojoch" oproti obycajnemu zalohovaniu je to, ze okrem ukladania umoznuju "mergeovanie". Ale mozno ste to nikdy nepotrebovali. Mozno ani nepotrebujete git.
Opravte ma, lebo ste na to povolanejsi, ale ak git v niektorych pripadoch nedokaze zarucit "merge associativity" (implementacny detail) a ine verzionovacie systemy to dokazu, tak logicky nie je verzionovaci system. Ma to logiku, Logiku?
-
Dafuq? Git je distribuovana mnozina commitu v case (timestamp), prostoru (branch) a dimenzi (uloziste). Zbytek jsou jen atributy :-)
ne neni, git je strom snapshotu ... nic vic
To je jen implementace vyseuvedene vety.
V akych jednotkach prosim vas plynie cas v gite? To je naimplementovane ako nejaky strom ci co?
-
Skvela debata. Jeden silenec si sem prisel dokazat, ze vi vic jak ostatni. Takze misto toho, aby slusne, jasne a strucne vysvetlil, proc git nechce brat jako verzovaci system, tak tu vede nejake vykriky do tmy za ucelem vyvolat hadku. Ano, to jiste tazateli z prvniho prispevku pomuze. Naucte se slusnemu chovani a vyjadrovani, pak chodte mezi lidi.
btw citace z webu gitu:
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
-
V akych jednotkach prosim vas plynie cas v gite?
Sekundy, normalni unix timestamp. Nikdo nekomitne za sekundu dva krat, krome Chucka Norrise.
To je naimplementovane ako nejaky strom ci co?
Je to jedna z moznych transofrmaci. Muzete na to koukat jako na strom, ale nemusite. Muzete treba linearne podle casu, kde vetev budete brat jen jako nepodstatny atribut.
-
Git je nejlepe provozovat s webovym backendem typu Gihub, Bitbucket, Stash atd.
Stash uz prejmenovali na bitbucket server.
-
trupik: commandline je skoro nutné ovládat, ale na Git Gui nedám dopustit. Možná když je někdo super pečlivý, tak se mu to nestává, ale pokud je třeba udělat z jedné sady změn dva commity, tak to dělat pomocí commandline je pěkná pakárna.
Tim myslis napsat dvakrat git cherry-pick COMMIT ?
-
Skvela debata. Jeden silenec si sem prisel dokazat, ze vi vic jak ostatni. Takze misto toho, aby slusne, jasne a strucne vysvetlil, proc git nechce brat jako verzovaci system, tak tu vede nejake vykriky do tmy za ucelem vyvolat hadku. Ano, to jiste tazateli z prvniho prispevku pomuze. Naucte se slusnemu chovani a vyjadrovani, pak chodte mezi lidi.
btw citace z webu gitu:
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Pozrite, nebol som to ja, kto nazval vyroky inych ludi "dementnym slovickarenim".
Oba body, ktore som spomenul, su dopodroba vysvetlene v knihe, ktoru som linkoval. Cielom bolo, aby vas to motivovalo knihu precitat a moje tvrdenie potvrdit alebo vyvratit. Za jeden vecer to snad precita kazdy. Google vyhladavac ma tiez kazdy a git je opensource, takze celkom nerozumiem, co konkretne "nechcem prezradit". Navyse Fabien Sanglard napisal niekolko velmi dobrych clankov o git internals, ak chete ist este hlbsie, ktore su online zadarmo.
Celkom nerozumiem, naco je dobre vybalit rovno gitflow, rebasovanie, vetvy atd. na cloveka, ktory git len zacina, ked ani nerozumie ako ten git funguje.
Veci ako merge associativy inconsistency, ze si git ziadne zmeny nepamata, ze diffy sa rataju realtime, ze cas v gite nehra absolutne ziadnu rolu a dalsie ine "neocakavane" spravanie atd. su vsetky podmiene tym ako je git naimplementovany a popisane v knihe, ktoru som linkovala a je zadarmo.
Ale OK, mozno mam lepsi google, kapitola Git internals (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain):
First, if it isn’t yet clear, Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it.
-
trupik: commandline je skoro nutné ovládat, ale na Git Gui nedám dopustit. Možná když je někdo super pečlivý, tak se mu to nestává, ale pokud je třeba udělat z jedné sady změn dva commity, tak to dělat pomocí commandline je pěkná pakárna.
Asi to bude vec zvyku - git status a git diff a mám v tom poriadok celkom rýchlo. Určite ale pomôže aj organizácia práce: keď mám rozrobenú jednu vec a potrebujem začať inú, tak tú prvú dám na stash alebo do vlastnej branch.
-
Poradíte někdo, jak na správu projektu s Git? Resp. kde najím nějak rozumě vysvětleno, jak se to vlastně chová? Několikrát jsem ho zkoušel, ale vždycky se to chovalo nějak "divně", jinak, než bych z popisu čekal.
Situace je zavedení repozitáře mezi asi tři lidi, projekty v C, integrace s eclipse.
Moje představa by byla jeden centrální repozitář na serveru plus u každého lokálně.
Na první pohled to vypadá jednoduše, ale nikdy mi to nijak nefungovalo, zvláště i integrací do IDE.
na centralni git server se mi osvedcil www.gitblit.com
-
...Z IDE doporucuji SourceTree, je daleko nejlepsi. https://www.sourcetreeapp.com/ Ma jen jedinou vadu - neni linux verze.
To som si doteraz nejako nevsimol. Bol som presvedceny ze to urcite bude aj na Linux....
Ja to pouzivam v praci na Windows. Tak teraz chapem, preco ostatni Java-developeri ktorych poznam pouzivaju Mac.
-
Rozumná IDE mají podporu pro GIT integrovanou. Bohužel např. v Intellij mi zásadně chybí výběr jednotlivého chunku diffu pro commit (což bohužel vede na více změn v jednom commitu, pokud se s tím člověk nechce dělat v terminálu interaktivním add -i), ale jinak je podpora slušná. Integrovaná historie a blame řádku, to se využívá často.
-
Poradíte někdo, jak na správu projektu s Git? Resp. kde najím nějak rozumě vysvětleno, jak se to vlastně chová? Několikrát jsem ho zkoušel, ale vždycky se to chovalo nějak "divně", jinak, než bych z popisu čekal.
Situace je zavedení repozitáře mezi asi tři lidi, projekty v C, integrace s eclipse.
Moje představa by byla jeden centrální repozitář na serveru plus u každého lokálně.
Na první pohled to vypadá jednoduše, ale nikdy mi to nijak nefungovalo, zvláště i integrací do IDE.
Pokud ti dela problem git, tak pan buh s tvym klientem.
Git je distribuovany takze kazdy ma u sebe kopii. Nechapu proc se toho snazis dosahnout kdyz presne todle je zakladni charakteristika gitu.
To te maminka nic nenaucila?