Ertem en amit mondasz csak ehhez nem git kell hanem ertelmes emberek, pontosabban egy ertelmes ember minimum, a teamlead.
Eleve ha ket valtozashoz egy fajlba kell nyulni akkor valakit seggberugok. Na jo, ez igy nem igaz, de a rendszer szedje ossze reflectionnel meg builddel szepen indulaskor a dolgokat amiket amugy egy helyen modositgatna mindenki keresztul-kasul.
Ha neked egy fajlt kell ket eltero change-hez modositani, akkor serul a Single Responsibility Principle. Nem erdekel hogy config fajl, az is a forraskod resze.
Ezt nem a verziokezelonek kell tamogatnia, hanem annak az allatnak (alt. en szoktam lenni), aki minden egyes commitot szepen elolvas a tracban, meg kiosztja a feladatokat, es feltunik neki hogy ket modositas kerult egy commitba.
Namost erre ugye a git teljesen alkalmatlan, az ilyen bazar-stilusu fejlesztesre valo.
Erdekes modon en meg mindig qrva gyorsan kiszedtem SVN-bol az altalad emlitett infokat, igaz, hogy trac-cal meg fisheye-jal, meg webes feluleten, cserebe nem voltak szanaszet a feature branchek a fejlesztok gepein lokalisan, hanem lattad hogy az adott tickethez tartozo branch (mert minden nem "csereljuk ki a pirosat zoldre" ticket kapta a kulon kis branchet,igen, svn-ben meg cvs-ben) epp hogy fejlodik, jo, izomtibi kellett a verziokezelo masina ala, meg ha nem volt vmiert, akkor az emberek alltak at lokalis mercurialra meg egyeb csodakra, de az svn jobb helyeken eleg fontos volt ahhoz hogy sz.rrareplikalva legyen 99.99%-os uptime-mal.
Nem azt mondom hogy nem kellenek az altalad emlitett dolgok, azt mondom ,hogy ezeket forraskod- es fejlesztesszervezessel sokkal hatekonyabban lehet elerni.
Meggyozodesem hogy ez az egesz "onszervezo" csoport-felelossegesdi tobbek kozt azert indult utjara, mert marha kevesen voltak azok az emberek, akik fel tudtak ismerni az antipatterneket a commit logokba, let alone egyaltalan hogy napi 30-40 commitot atnezzenek, felig kezzel, felig continous buildszerveren levo stylecheck-lint-whatever toolokkal. De attol hogy a lovak koze dobod a gyeplod nem oldodik meg, csak feladod.
Innentol kezdve viszont azzal ervelni, hogy azert alljunk at erre a kaoszgepre, mert jobbak a menedzsment-funkcioi, es feltunesmentesen lehet vele szar kodot leadni (egy fajl tobb felelossegi korrel), ez nem erv. Azt se szeretem ha a fejlesztoknek tul sok kulonbozo env-juk van, mert nagyon hamar eljutnak a megertesi kapacitasuk vegere (oh, persze, minden fejleszto mindig mindent tud, meg nem lesz semmi baj, csak 4-5 env utan mindegyik zsenikenel beut a krach), hat meg ha van 20 szarrabranchelt working copy-juk is, hat az kulon orom.
Ugye anno egy masik git vitaban mar megegyeztunk, hogy a gittel mindent meg lehet csinalni de nem mindent erdemes. A kiscsoportos vallalati fejlesztesek toolja az SVN, iszonyatosan profin van erre belove, ezt tovabbra is tartom.