Muszáj használni a github-ot anélkül nem lehet élni?

"hát lehet egyszer eljön az idő, amikor már annyira hasznos dologként fogok tekinteni rá,"

Így van, ne csüggedj, még belőled is lehet hivatásos programozó.

"a github előtt is éltek programozók :P"

A forráskód verziókövetése amióta programozás létezik egy fontos probléma. A git előtt más verziókezelőt használtak pl. svn-t.

#22: ha ez sértés akart lenni, akkor nem veszem magamra, ugyanis valóban nem vagyok hivatásos programozó, csak értek ehhez-ahhoz annyira, hogy ki tudjam belőle hozni azt, amire szükségem van :D

SVN-t amúgy valóban én is használtam, csak nem ugrott be a neve. Emlékeim szerint átláthatóbb volt a működése, és az szimpatikus is volt. Már amennyit használtam belőle.

githubot nem muszáj, de verziókezelöt igen.

Képzeld el, hogy a szoftverednek van több verziója. Találtok egy bugot, amit ki is javítotok. Namármost a changelogba be kéne írni, hogy kijavult, de az userek azt is szeretnék tudni, hogy melyik verziókat érint. Namost ezt verziókövetö nélkül megoldani szinte lehetetlen viszont git bisect-el kb triviális.

Más példa: elég gyakori, hogy egy terméknek több verzióját is támogatni kell: van mondjuk egy LTS(long term support) verzió, meg rolling releaseben a master. Ha ilyen modellben pl backportolni akarsz egy bugjavítást, akkor verziókövetö nélkül kb újra kell csinálni a javítást. Gittel meg kb cherry-pick és kész.

Még egy példa ami miatt kisebb projekteknél is hasznos lehet:

Ismerjük azt a jelenséget, amikor írsz egy kódrészt, majd rájössz, hogy mégse így akarod csinálni, ezért újraírod. Viszont az eredeti kódrészben még lehetnek hasznos dolgok, esetleg az új módszer mégse müködik olyan jól, ezért biztos ami biztos, nem törlöd ki, csak kikommentezed. Ezek a kikommentezett kódrészek meg szépen összegyülnek. Na ha van verziókövetöd, akkor nyugodtan kitörölhetsz akármit, mert a historyban úgyis ott van.

24:

Pont rossz az első két példád, mert a folyamatos verziókezelés hiánya nem jelenti azt, hogy éles deployment esetében ne archiválhatnád az adott állapotot. A verziókezelő sokkal több análl, hogy a release verziókat számon tartod elsősorban a fejlesztést segíti, csak a release verziók miatt még nem lenne rá szükség.

"verziókezelés hiánya nem jelenti azt, hogy éles deployment esetében ne archiválhatnád az adott állapotot."

Oh bakker, mindent meg lehet oldani verziókezelő nélkül, max marha fájdalmas. Kocsi se kell, gyalog is oda lehet érni bárhova max sokat kell gyalogolni. Ha valamit kell updatelni egy adott release-en, fogod, checkout-olod és kész. Nem kell turkálni zip file-okban, vagy követhetetlen könyvtárstruktúrákban. De tényleg, akkor látja meg igazán az ember, hogy mennyire fontos a verziókezelés, amikor komolyabb fejlesztést végez egy csapat részeként.

#25:

Az elsö példában annyiban igazad lehet, hogy nem lehetetlen dolog megtalálni az elsö releaset, amiben bejött a bug: végülis kézzel is tudod tolni azt a bináris keresést, amit a git bisect is csinál.

A második példámban nem igazán látom, hogy a releasek archiválása hogyan oldja meg azt, hogy tudj efektíven backportolni. Mivel csak release a releaseket mented el, nincsenek meg a köztes állapotok, így elemi patcheid sincsenek. Ha csak a bugjavítást akarod backportolni de az a featureket nem(márpedig LTS verzióra nem szokás featureket backportolni), akkor meg vagy löve. Vagy rosszul látom a dolgot?

Remelem az itt a terminal miatt sirokkal nem kell talalkoznom egyik cegnel sem, ahol dolgozni fogok.

Merge conflictnal peldaul hasznos a GUI, de egy sima commitnal nem tudom miert nehez pepotyogni azt a harom parancsot.

Mondjuk ezt lehet azok a "programozok" irjak, akik drag and droppal "fejlesztenek" weboldalakat.

Gitet erdemes hasznalni sajat projektnel is, legalabb gyakorlod, meg nem veszik el a munkad (nyilvan ehhez kell egy remote repo).

Raadasul tudsz tobb featuren dolgozni kulon branchen, ha az egyikkel nem akarsz bajolodni eppen stb.