Sdílení zdrojových kódů mezi různými počítači

[Ondřej Novák]

To asi záleží na stylu práce no, znám maníky kteří commitují každou řádku. Já nevím asi by se mělo commitovat po nějakých logických celních jenže často pracuji na několika věcech současně takže někdy ten logicky celek je na nekolik dní a zahrnuje několik velkých commitu.

Zejména na začátku vývoje používám sc nástroje na dílčí zálohování věci mimo mě PC (což offline samozřejmě nejde dělat) nebo přenášení dat mezi PC. Nechci řešit co je logicky celek, IDE mi poskytuje nekonečné undo a local history, tam chodím nejčastěji když hledám minule úpravy. Commit uprostřed práce mne zdržuje a nevidím důvod, proc by někdo měl nakonec vidět dílčí kroky vzniku finálního kodu

[Reklama]

[gnat]

Všechny verzovací nástroje mají jednu zásadní nevýhodu: pokud zapomenu v práci commit, tak jsem doma namydlenej. Používám nextcloud, historii souborů umí a nemusím se ani bát toho, že mi odejde disk. Soubor se synchronizuje chvilku po uložení, Do verzovacího systému commituju až odladěný kód.

[Kit]

Všechny verzovací nástroje mají jednu zásadní nevýhodu: pokud zapomenu v práci commit, tak jsem doma namydlenej. Používám nextcloud, historii souborů umí a nemusím se ani bát toho, že mi odejde disk. Soubor se synchronizuje chvilku po uložení, Do verzovacího systému commituju až odladěný kód.

Stalo se mi už několikrát, že jsem v práci zapomněl udělat commit. Jednoduše jsem doma pokračoval a pak jsem udělal merge. Žádný problém v tom nevidím, verzovací systémy mají tohle vychytané.

Odladěný kód se obvykle merguje až do větve master, ale do větve feature commituji po udělání každého logického celku, i kdyby to byl jen jeden řádek. Komentář ke commitu tak může být klidně i delší, než samotná úprava zdrojáku. Je docela hloupé v jednom commitu komentovat několik nezávislých změn - je to pak nepřehledné a blbě se dělají reverty.

Dropbox, Google Disk a Mega.nz používám spíš na dokumenty, které není potřebné verzovat.

[Kit]

To asi záleží na stylu práce no, znám maníky kteří commitují každou řádku. Já nevím asi by se mělo commitovat po nějakých logických celních jenže často pracuji na několika věcech současně takže někdy ten logicky celek je na nekolik dní a zahrnuje několik velkých commitu.

Pokud je ten logický celek na delší dobu než cca hodinu, je příliš velký a je nutné ho rozdělit na menší. Modifikace by se měly dělat pokud možno v jednom souboru, commity jsou pak mnohem jednodušší a přehlednější.

Velkou bolestí programátorů bývá neschopnost rozdělit problém na několik menších, které se pak dělají postupně jeden po druhém tak, aby ty změny byly na sobě nezávislé.

[dustin]

Pokud např. přejmenovávám public metodu, obykle to nebude změna jen v jednom souboru. Nevidím důvod, proč by se měla jedna fukční změna  (po které by měl zůstat projekt kompilovatelný), týkat jen jednoho souboru. Samozřejmě by commit neměl obsahovat více změn najednou, ale ne vždy to lze rozumně dodržet a není to dogma.

[Reklama]

[Ondrej]

Kit žije asi v nějakém ideálním světě co my ostatní ne :-( Tak jak to popisuješ by to bylo super, ale realita je z různých důvodů mnohdy jiná.

[Ondrej]

Všechny verzovací nástroje mají jednu zásadní nevýhodu: pokud zapomenu v práci commit, tak jsem doma namydlenej. Používám nextcloud, historii souborů umí a nemusím se ani bát toho, že mi odejde disk. Soubor se synchronizuje chvilku po uložení, Do verzovacího systému commituju až odladěný kód.

Nad nextcloudem sem taky přemejšlel, ale seafile mě přijde dospělejší. Umí už next/own cloud rozumně verzovat?

[dustin]

Kit hlavně nedělá žádné větší projekty a kompilovatelnost v PHP neřeší.

[Kit]

Pokud např. přejmenovávám public metodu, obykle to nebude změna jen v jednom souboru. Nevidím důvod, proč by se měla jedna fukční změna  (po které by měl zůstat projekt kompilovatelný), týkat jen jednoho souboru. Samozřejmě by commit neměl obsahovat více změn najednou, ale ne vždy to lze rozumně dodržet a není to dogma.

Nevidím důvod, proč bych měl přejmenovávat nějakou veřejnou metodu. To bych musel nejprve změnit rozhraní. Kromě toho jsem psal o modifikaci funkcionality, nikoli o refactoringu.

[Ondrej]

Tak já převážně dělám většinou v Pythonu, čili v tomhle obdoba PHP, ale i tak mě tenhle přístup přijde mimo realitu. Bohužel. Ale asi záleží pro koho a co děláš.

[Kit]

Kit hlavně nedělá žádné větší projekty a kompilovatelnost v PHP neřeší.

Kompilovatelnost v PHP řeším nejen po sobě, ale i po ostatních. Fatal errory na produkci si nemůžeme dovolit asi nikdo.

[Kit]

Tak já převážně dělám většinou v Pythonu, čili v tomhle obdoba PHP, ale i tak mě tenhle přístup přijde mimo realitu. Bohužel. Ale asi záleží pro koho a co děláš.

Bohužel je ten projekt tak velký, že si nemůžeme dovolit dělat hromadné změny plné vnitřních závislostí, po kterých by se to mohlo rozsypat. Nároky na atomizaci změn jsou u nás docela přísné.

[Radim Zátopek]

Nauč se Git, to se ti bude hodit.
Začni třeba tady https://www.learnenough.com/git-tutorial

[Lopata]

Problémem GITu je jeho "nízkoúrovňovost" a nutnost znát jeho střeva k pochopení spousty pokročilejších příkazů. Je tedy třeba se více zaměřit na to, "jak" něčeho dosáhnout. Naopak v Mercurialu a SVN většinou stačí vědět, "čeho" chci dosáhnout.

Z těchto rozdílů také vyplývá pojmenování příkazů a jejich parametrů, které jsou v GITu zaměřeny na "postup" a nikoliv na "výsledek". V SVN nebo Mercurialu například chci revert lokálních změn, udělám tedy "revert". Hotovo. V GITu poněkud nelogicky nepoužiji "revert" (ten navíc dělá něco jiného), ale "reset", protože přeci nebudu dělat jen prachsprostý revert lokálních změn, ale budu muset přemýšlet nad tím, že tam mám nějaký "index" (staging area) a pointery na commity atd. A aby se to nezdálo tak jednoduché, tak ještě musím řešit, zda náhodou nepoužít nějaký z přepínačů typu "--soft" a "--hard". Prostě nebylo možné mít jediný příkaz "revert" s několika vhodně pojmenovanými parametry.

Ano, GIT je flexibilnější v případech, že se chci opravdu pošťourat ve vnitřnostech, ale kolikrát za rok něco takového potřebuji, a musí to být na úkor komfortu běžného používání? Nejen pro začátečníka to může být dost frustrující.

[Kit]

Problémem GITu je jeho "nízkoúrovňovost" a nutnost znát jeho střeva k pochopení spousty pokročilejších příkazů. Je tedy třeba se více zaměřit na to, "jak" něčeho dosáhnout. Naopak v Mercurialu a SVN většinou stačí vědět, "čeho" chci dosáhnout.

Tato nízkoúrovňovost Gitu však umožňuje tvorbu různých nadstaveb a doplňků do IDE s mnohem větší variabilitou, než mají konkurenční VCS. I v samotném Gitu je možné si snadno vyrobit vlastní sadu maker dostupných nejen z příkazové řádky. Dají se dědit, překrývat i přetěžovat. Jistěže dá trochu práce se tyto finesy naučit, ale začátečník to moc nepotřebuje a pokročilý si na to ten čas najde, protože to ušetří hromadu ruční práce.