Er is de laatste jaren nogal wat hype rond Git ontstaan. Git is een gedistribueerd versiecontrolesysteem (DVCS), en wordt vooral gebruikt om de broncode van software-projecten te beheren. Zo vind je b.v. op github de code voor een hele resem bekende en minder bekende open source projecten (git is ook zelf open source).
Even in het kort: het grote verschil tussen een centraal versiecontrolesysteem (CVCS), zoals Subversion (SVN), en een DVCS, is dat je met een DVCS lokale (offline) commits kan doen en je die later kan samenvoegen met de rest, terwijl je bij een CVCS altijd met de centrale server moet communiceren. Dit laat veel kleinere commits toe en vergemakkelijkt het zogenaamde “branchen”, wat dan weer de hele workflow vergemakkelijkt. Eén probleem is wel dat het beheer van zo’n systeem moeilijker wordt, omdat je voor een deel de controle geeft aan de gebruikers.
Voor de rest laat ik de algemene uitleg over VCS aan het internet over, in deze post wil ik het even hebben over Git. Een drietal jaar geleden maakte ik een studie naar VCS, omdat het tijd werd voor een migratie van onze oude CVS-systemen. Doel van de studie was toen om na te gaan welk systeem de opvolger moest worden. Het resultaat was SVN, wat vooral kwam doordat een CVCS systeem beter zou integreren met de huidige organisatie. Een verdienstelijke tweede plaats was toen voor Mercurial (Hg), een DVCS.
Waarom dus niet Git? Heb ik dat dan toen niet bekeken? Zeker wel, maar ik vond dat Git zich toen beter thuis voelde in een *-nix wereld, terwijl wij iets nodig hadden voor Windows. Verder bleek toen ook dat Git werd gebruikt voor het ontwikkelen van de Linux Kernel, en Hg voor de Java OpenJDK, en vermits wij voornamelijk in Java ontwikkelen, voelde Hg dus natuurlijker aan.
De belangrijkste reden waarom ik toen Hg boven Git heb geplaatst, was echter de relatieve eenvoud van Mercurial. Git was eerder een platform, waar je heel krachtige dingen mee kon doen, en Mercurial was eerder een echte eindgebruikerstoepassing, die eenvoudiger was in gebruik en dus een kortere leercurve zou kennen.
Tegenwoordig zijn de gebruikershandleidingen van Git een stuk beter geworden, maar zijn ook de mogelijkheden van Mercurial flink uitgediept. De producten zijn dus wat naar elkaar toegegroeid. Toch is er nog altijd een zekere “feel” die anders is, zoals ook besproken wordt op deze site: Git is MacGyver, Mercurial is James Bond. Op StackOverflow staan er wat nuttiger vergelijkingen tussen de beide. We onthouden hiervan opnieuw dat Mercurial cleaner en eleganter aanvoelt, maar dat Git meer mogelijkheden tot customizatie biedt.
Sinds mijn vergelijkende studie een aantal jaren geleden, zijn de producten echter niet alleen geëvolueerd, maar is ook hun relatieve populariteit veranderd. In de software-ontwikkelingswereld in het algemeen merken we dat de voorkeur meer en meer naar gedistribueerde systemen zoals Git evolueert. Zelfs de grotere Application Lifecycle Management vendors ondersteunen het nu in hun producten. In onderstaande figuur zien we dat, omstreeks 2010, SVN nog steeds het populairste systeem was. Nu liggen de kaarten echter anders, en naar het einde toe zien we dat CVS zelfs onderaan de lijst bengelt. Dit wordt echter tegengesproken door de tweede figuur, waar we merken dat CVS stand houdt qua gebruik in bestaande projecten, ook al is het als zoekterm onderaan het peleton geëindigd. In de eerste figuur is Git echter duidelijk het populairste, en zelfs in de tweede figuur staat het systeem met kop en schouders boven de andere gedistribueerde systemen: Mercurial en Bazaar (bzr).
VCS systemen volgens google search
Gebruik van VCS volgens Ohloh
Deze trend is al een tijdje aan de gang en lijkt voorlopig niet te keren: wanneer men tegenwoordig een versiecontrolesysteem nodig heeft, grijpt men, zeker in het geval van open source, in de eerste plaats naar Git. Het systeem is de laatste jaren dan ook erg matuur geworden, en heeft het grote voordeel van de gratis online dienst github voor open source projecten. Op deze manier kan Git in de hoofden van nieuwere generaties developers steeds vaker het eerste zijn waar ze aan denken bij de woorden “source code control”.
Leave a Reply