( lovas | 2017. 12. 21., cs – 12:00 )

Mi környezeti+feature branchinget használunk. Szerettem volna commit hookokat is üzembe állítani, de nem volt rá igény a PM/PO-nál. Ez szvsz nem faék, bár ahogy vesszük... a kollégák elég szimpla dolgokat csinálnak anélkül, hogy attól kéne tartani, hogy összebarmolnák/átírnák a már meglévő history-t.

Az általad felsoroltak egy része félrevezető, vagy szubjektív.
- Kétségtelen, hogy SVN local repo-ból megosztani nem egy parancs, de nem kell hozzá diploma.
- Nem kénytelen mindenki használni azt a branchet, amit én és pár kollégám használunk, ellenben egyből látják a változásokat, mert nem felejtem el push-olni commit után, és minden babrálás nélkül bárki át tudja venni tőlem a melót, és még hétvégén sem kell rámtelefonálnia.
- Branching: hacsak nem potato szervered van, nem tudom mi a problémád. Nem kell külön megosztanod a branchedet másokkal, és tartanod szinkronban.
- A ménkű beüt néha. Bár a mostani cégemnél 12 éve dolgozom, erre egyszer sem volt példa, nem oldott volna meg semmit, ha a magam kis repository-ját tutujgatom. Szerintem
- Bár nem vagyok híve a dolognak, jelenleg bazinagy repo-kat használunk elég sok projektre. Amin most dolgozok ott 150000-felé közelít a revision number, de nemrég néztem az apache foundation repository-ját, ott 1.8 millió fölött járnak, működik, gyors, és van kapcsolat a projektek között is.
Ami nekem baromira hiányzik a git repo esetében, az a hierarchikus felépítés. Van párezer branched, és találd meg amelyiket keresed, gúdlákk, pláne ha még le sem szedted a központi repoból, amit a kollégád elfelejtett megosztani. A git esetében a strukturált branchek használata nem létező dolog, azokon keresztül tökéletesen kezelhető az általad vázolt probléma is.

A git CLI output meg katasztrófa, bár a paraméterei is.

Mindegy, örülök, hogy neked bejön ez a trend, de nekem kissé gagyinak tűnik a hozzá társuló érvrendszer és felfogás.