20 éves lett a Git!

Szerszám

#linustorvalds #linuxkernel #larrymcvoy #bitkeeper #bitmover #odavert #lenyomottmindentis #opensourceforradalom #happybirthday #party #hogyantudnalelninelkule

A jeles alkalomból interjút készítettek Linus Torvalds-szal. Elolvasható itt.

( trey | 2025. 04. 07., h – 17:57 )

I always felt that SVN was just "lipstick on a pig."

LOL

trey @ gépház

( KGer | 2025. 04. 07., h – 18:18 )

Egyik legnagyobb eredmény software téren.

Boldog Szülinapot Git!

( profeta | 2025. 04. 07., h – 22:31 )

Szó se róla, a Git egy jó eszköz, de ha valaki kisebb csapatban dolgozik, nem csilliárd soros kódbázison, és nem fekete öves ninja, az egyetlen valódi előnye az SVN-hez képest, a pull request, illetve az azt támogató eszközök. A legtöbb fejlesztőnek halvány lila gőze sincs a két rendszer közötti egyéb eltérésekről. Vagy úgy egyáltalán a Git lelki világáról. Meg volt ugye egy Bitkeeper is valamikor.
De jól mutatja az egész szoftveripar innovációra való képtelenségét, hogy a programokat még mindig text file-okként kezeljük, nyelvtől függetlenül. Szóval a Git is csak lipstick on a pig.
Talán egy próbálkozás volt, a Charles Simonyi féle Intentional Software-től, de abból sajnos nem lett semmi.

Ha valaki akár önállóan dolgozik, akkor egy mezei git init és az időnkénti commitok megkönnyítik az életét, szóval ilyen környezetben az előnye az SVN-hez képest az, hogy semmi repot nem kell létrehoznia, az ott van helyből. Azaz sokkal kisebb a kezdéshez szükséges erőforrás.

Ugyanmá'! Nem egy kategória a kettő.

Pl. kis cégnél, kis csapatban, napi használatban: "git remote add ..."
Ezt hogyan csinálod SVN-ben? A submodulokról nem is beszélve.

Ahogy lejjebb említették, az SVN egyetlen irigylésre méltó tulajdonsága a lineárisan növekvő kommit szám, ami sokkal könnyebben kezelhető, mint egy hash. De a git más előnyei mellett ez elhanyagolható.

( YleGreg | 2025. 04. 07., h – 22:53 )

A legbájosabb vonása, hogy a felhasználók többsége úgy használja, hogy nem érti, és nem is ért hozzá. Én sem. Szerintem sokat mondok, ha a git képességeinek a 10% -át ismerem. De az a legszebb, hogy már ez a 10% is hihetetlenül hasznos...

( nagyjoco | 2025. 04. 08., k – 14:31 )

Én csak 10 éve használom, akkor vezettük be. Aztán bárhova mentem, ott is git volt. 
Mára már megszoktam, privát projektekben is gitelek. 

Használ valaki mást giten kívül?

Ez ilyen. Esetleg csinalj meg hozza egy yt csatornat (marketing), akkor noveled a felhasznalobazist.

Par ev utan latod, hogy mostmar 10x annyi idot toltal be, es bugreporton kivul meg mindig nem jott semmi ... :)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Én egy évig kezeltem fossillal a pénzügyes dolgaimat. Tulajdonképpen jó volt, de nekem hiányzott a korábbi commitok rebase-hez hasonló javítása (de lehet, hogy van ilyen, és csak én nem találtam meg). Az is tetszik, hogy minden van benne, ahhoz képest (is) szinte nevetségesen kicsi.

( persicsb | 2025. 04. 08., k – 18:32 )

A git a verziókezelés Microsoft Office-a. Nem a legjobb, és a legtöbb helyre felesleges, mert a funkciók 95%-át nem is használod. De megkerülhetetlen, mert mindenki ezt használja, ezért ezt is kell megtanulnod használni.

Az nem lehet, hogy nem használt funkciók nem sokat zavarnak? A git sokkal kisebb mint az Office. És sokkal kevesebb telemetriát küld a Microsoftnak.
Ráadásul az az 5% egész jól működik. Problémák esetében pedig még mindig használhatod a 95%-ot.

Még nincs aláírásom.

Azt hogy kinek mi a legjobb, mint mindenhol máshol, a felhasználás módja mondja meg. Olyan nincs, hogy a git mindig mindenben a legjobb.

Például az SVN-ben baromi jó, hogy van egy folytonosan növekvő revíziószám, ami többet mondhat ránézésre, mint egy commit hash, ha azonosítani kell egy kommitot.

Vagy éppen az, hogy centralizált. Annak nincs értelme, hogy van egy decentralizált eszközöd, de úgy használod, mintha centralizált lenne, és kvázi ellenjavalt is a decentralizált használat. A legtöbben a gitet úgy használják, mintha SVN lenne, főleg amikor Gitlab, GitHub és hasonlókon keresztül használják. Nagyon kevés helyen láttam olyat, ahol egy working copynál egynél több lett volna a remote url. Van egy origin és kész. Ehhez viszont nem kell git, hogy csinálj egy centralizált verziókezelést.

Sőt, van, ahol totál ellenjavalt az az elosztott, a Linux kernel fejlesztésénél viszont szükséges feature, ami a gitben van. És hát mivel minden repo lokális (csak épp megvan a mással való szinkron lehetősége), így aztán a fejlesztő kezében van, hogy mit csinál a local historyjával, és a commitokkal - ez a fajta teljesen rugalmas, a fejlesztőket nem korlátok közé szorító workflow van, ahol nem is engedélyezett.

Hasonlóképpen, nem biztos, hogy sokaknak jó, hogy GPL licenctű a git, főleg úgy nem, hogy ha ők valami mást akarnak gittel mint content-adressable store-ral megvalósítani és szolgáltatásként akarják árulni ezt a tárolót. Mert ugye a git a verziókezelős porcelain réteg alatt nem más, mint egy CAS.

Én jól emlékszem, amikor bő 10 évvel ezelőtt az akkori munkahelyemen átálltunk rá, méghozzá jól megalapozott szakmai okokból kifolyólag: nevezetesen, hogy a piaci trendek erre mutatnak :D
És ez az érv valid volt, a Git ugyanazért lett népszerű, mint a Python, nem azért, mert jobb, szebb, okosabb a versenytásainál, hanem azért, mert beálltak mögé a multik, és olyan támogatást adtak mögé, ami megkerülhetetlenné tette. 
Én nagyvállalati környezetben sok-sok éve csak gitet látok, bármerre is nézek (hogy mennyire értenek hozzá, az más tészta), és szerintem a KKV szektorban is ez a helyzet, de javítsatok ki, ha tévedek.

Én nagyvállalati környezetben sok-sok éve csak gitet látok, bármerre is nézek (hogy mennyire értenek hozzá, az más tészta),

Pont ezt mondom. Sok helyen nem is úgy használják a gitet, ahogy az ki van találva, hanem úgy, mintha egy centralizált verziókezelő lenne. Arra meg pontosan jó az SVN is ám.

A git-et sokféle módon lehet használni, nem csak úgy, ahogy Linus használja.  Ettől az még teljesen "normális" használat.

Attól még, hogy egy központi repo-t használtok, még mindig rengeteg előnye van a git-nek az svn-hez képest, míg az svn előnye kb a "verziók szépen nőnek", amin azért elég könnyű túllendülni szerintem (a release-ek legyenek tag-elve szépen, a köztes commit-oknál meg nem igazán számít).

Az, hogy ~működik az svn egy adott use-case-re, még nem jelenti azt, hogy az a jobb választás.

 

De persze nem akarlak meggyőzni, azt használtok amit akartok (amíg nem dolgozok ott, ha már érintené a munkámat, akkor természetesen megpróbálnám meggyőzni az illetékeseket a váltásról :))

Azt hogy kinek mi a legjobb, mint mindenhol máshol, a felhasználás módja mondja meg

+1, és be is dobnám példának a Perforce-ot, aki dolgozott már vele megfelelő környezetben, érti miért

Elvileg mindkettő VCS, gyakorlatilag meg azért nem igazán alternatívái egymásnak.