Waarom Git beter is dan X

Waarschijnlijk een van de meest onderscheidende features van Git is zijn branch model. Het is volledig anders dan alle modellen die ik het hier mee vergelijk; de meesten nemen het standpunt in dat de beste branch min of meer een kloon van de hele repository in een nieuwe map is.

Git werkt niet op die manier. Git laat je vele lokale branches hebben, welke compleet onafhankelijk van elkaar kunnen zijn. Het aanmaken, mergen en verwijderen van deze takken van ontwikkeling gebeurt in slechts seconden.

Dit betekent dat je dingen kunt doen zoals:

• Een branch maken om een idee uit te proberen, een paar keer committen, terugschakelen naar waar je vanaf branchte, een patch toepassen, schakelen naar je experimentele branch, en vervolgens de nieuwe wijzigingen van de originele tak terug mergen.
• Een branch bijhouden met precies datgene wat in de productieomgeving draait, een tweede waaruit je testomgeving werkt, en verscheidene kleinere voor dagelijks werk.
• Branches aanmaken voor elke nieuwe feature waaraan je werkt, zodat je ertussen moeiteloos heen en weer kunt schakelen. Vervolgens verwijder je elke branch zodra de feature in de hoofdlijn gemerged wordt.
• Een branch aanmaken om in te experimenteren, en zodra je erachter komt dat het nooit wat wordt, de branch gewoon verwijderen, zonder dat iemand hem ooit heeft gezien. Ook als je in de tussentijd andere branches hebt gepushed.

Belangrijk is dat wanneer je naar een remote repository pushed, je niet al je branches hoeft te pushen. Je kunt alleen die branches delen die je wilt. Dit laat men nieuwe ideeën uitproberen zonder zich te hoeven bekommeren hoe dit later terug te mergen, of te delen met anderen.

Je kunt manieren vinden om (delen van) dit te bereiken met andere systemen, maar het kost veel meer moeite, en is foutgevoeliger. Git maakt het proces ongelofelijk gemakkelijk, en veranderd de manier waarop veel ontwikkelaars werken wanneer ze het leren.

In principe geld dit voor elk gedistribueerde SCM, maar in mijn ervaring gaat Git hierin het verste. Buiten 'fetch', 'pull' en 'push' zijn er weinig acties die met iets anders communiceren dan je harde schijf.

Dit zorgt er niet alleen voor dat veel operaties veel sneller gaan dan je gewend bent, maar het geeft je ook de mogelijkheid om offline verder te werken. Dit klinkt niet als een big deal, maar ik sta er soms van te kijken hoe vaak ik wel niet offline werk. De mogelijkheid om te branchen, mergen, commiten en geschiedenis van je project door te kunnen lezen tijdens een vliegreis of treinrit is erg productief.

Zelfs in Mercurial wordt er met veelgebruikte commando's als 'incoming' en 'outgoing' met de server gecommuniceerd, terwijl je met Git eerst alle data van de server kan 'fetchen' voordat je offline gaat. Hierna kan je vergelijken, mergen en logs bekijken van data die op de server staat maar nog niet in je lokale branches te vinden is.

Dit betekent dat het erg makkelijk is om kopieën te hebben van niet alleen je eigen branches, maar ook die van iedereen die met je samenwerkt in je Git repistory zonder dat je eigen bestanden hierdoor in de war komen.

Git is snel. Iedereen—zelfs het grootste gedeelte van de hard core users van andere systemen—geeft Git deze titel. Met Git voer je alle operaties lokaal uit, wat een voorsprong geeft in vergelijking met SVN en Perforce, die allebei netwerk toegang nodig hebben voor sommige operaties. Zelfs in vergelijking met andere DCM's die operaties ook lokaal uitvoeren is Git nog steeds erg snel.

Een gedeelte hiervan komt waarschijnlijk omdat het is gebouwd om aan de Linux kernel te werken, wat betekent dat het vanaf dag 1 effectief om moest kunnen gaan met grote repositories. Hiernaast is Git geschreven in C, wat ervoor zorgt dat het minder overhead heeft dan runtimes die gebruik maken van een higher-level taal. Een andere reden dat Git zo snel is, is omdat de hoofdontwikkelaars dit als design-doelstelling hadden voor de applicatie.

Wat volgt zijn een aantal benchmarks die ik op drie kopieën van de Django source code repository heb uitgevoerd in drie verschillende SCM's: Git, Mercurial en Bazaar. Ik heb ook een gedeelte getest in SVN, maar geloof me, het is langzamer—kort gezegd, neem de Bazaar uitslag en tel hier de netwerk latency bij op...

Het eindresultaat kwam er op neer dat behalve het toevoegen van nieuwe bestanden, Git het snelste was. (Ook hele grote commits, waar Hg ongeveer hetzelfde in was, maar de commit die ik getest heb was zo groot dat je die waarschijnlijk nooit iets soortgelijks zal uitvoeren—normale commits zijn veel sneller in Git.)

De Cold en Hot branch cijfers zijn de eerste en tweede keer dat ik een repository gebranched had—het tweede cijfer is een branch met een hot disk cache.

Het moet gezegd worden dat desondanks de 'add' cijfers veel langzamer zijn, deze voor een ontzettend grote add operatie waren—meer dan 2000 bestanden. Normaal gezien zullen voor mensen die hun normale handelingen uitvoeren add operaties een fractie van een seconde duren. Alle andere operaties die ik hier getest heb (behalve misschien die voor de grote commit) geven een beter beeld van zaken die je daadwerkelijk wel elke dag zal uitvoeren.

Het is niet moeilijk om deze cijfers na te maken, je hoeft alleen maar het Django project in elk van deze systemen te klonen en voer hierin dezelfde commando's uit.

• git clone git://github.com/brosner/django.git dj-git
• hg clone hg.dpaste.com/django/trunk dj-hg
• bzr branch lp:django dj-bzr
• svn checkout code.djangoproject.com/svn/django/trunk dj-svn

Git is erg goed in het conserveren van schijfruimte. Je Git directory zal (normaal gezien) nauwelijks groter zijn dan een SVN checkout— in sommige gevallen zelfs kleiner (die .svn directories kunnen blijkbaar veel bevatten).

De volgende cijfers komen van klonen van het Django project uit elke semi-officiële Git mirror op hetzelfde moment in hun geschiedenis.

Anders dan andere systeem heeft Git iets wat het graag de "Staging omgeving" noemt, of de "index". Dit is een tussenliggend gebied waarbij je de commit kan vormgeven voordat je het commit.

Het coole hiervan is, en wat Git onderscheid zet van alle andere tools, is dat je makkelijk sommige van je bestanden kunt 'stagen' terwijl je ze afmaakt en ze dan kunt committen zonder dat je alle veranderde bestanden in je working directory hoeft te committen, of dat je ze hoeft te listen op de command line tijdens de commit.

Dit zorgt er ook voor dat je gedeeltes van een veranderd bestand kunt stagen. De dagen dat je twee logisch ongerelateerde wijzigingen uitvoerde op een bestand voordat je er achter kwam dat je vergeten was één er van was te committen zijn voorbij. Nu kan je gewoon de verandering die je nodig hebt voor de huidige commit stagen en stage je de andere wijziging voor de volgende commit hierna. Deze feature schaalt mee zodat je zoveel mogelijk wijzigingen aan een bestand kunt stagen als je nodig hebt.

Natuurlijk maakt Git het ook makkelijk om deze feature te negeren als je niet zoveel controle wilt hebben—gooi gewoon een '-a' bij je commit commando om in één keer alle veranderingen aan al je bestanden in de staging omgeving te zetten.

Een van de coolste features van Gedistribueerde SCM's, ook Git, is dat het gedistribueerd is. Dit betekent dat dat je geen "checkout" doet van het huidige topje van de source code doet, maar een "clone" van de gehele repository.

Dit betekent dat zelfs als je gebruik maakt van een gecentraliseerde workflow, elke user eigenlijk een gehele backup heeft van de hoofd server. Elke van deze zou de plaats in kunnen nemen van de hoofd server mocht daar iets bij optreden zoals een crash of corruptie. Er is dus eigenlijk geen 'single point of failure' met Git behalve als er maar één punt is.

Dit vertraagd alles niet veel ook. Gemiddeld gezien is een SVN checkout maar marginaal sneller dan elk van de DSCM's. Van alle DSCM's die ik getest heb was Git het snelste.

Een van de wonderbaarlijkste dingen van Git is dat door zijn gedistribueerde instelling en geavanceerd branch systeem, je gemakkelijk elke workflow kunt implementeren die je wilt met relatief gezien weinig moeite.

Een veel voorkomende Git workflow, vooral voor mensen die vanuit een gecentraliseerd systeem komen, is een gecentraliseerde workflow. Git laat je niet toe om te pushen als iemand anders gepushed heeft sinds je voor het laatst gefetched hebt, dus een gecentraliseerd model waarbij alle ontwikkelaars naar dezelfde server pushen werkt gewoon.

Een andere veel voorkomende Git workflow is degene waarbij er een integratie manager is—een enkel persoon die naar de 'blessed' repository commit waarna een aantal ontwikkelaars klonen vanuit die repository, pushen naar hun eigen onafhankelijke repository en de integratie maanger vragen om hun veranderingen te pullen. Dit ontwikkel model zie je vaak in open source of GitHub repositories.

Voor grotere projecten kan je je developers instellen op de manier waarop de Linux kernel opereert, waarbij mensen (luitenanten) de verantwoordelijkheid hebben over een specifiek deel van het systeem. Een andere persoon (de 'dictator') kan daarna veranderingen pullen van zijn of haar luitenanten en deze door pushen naar de 'blessed' repository waar iedereen vervolgens weer vandaan kan klonen.

Nogmaals, Git is heel flexibel in dit geval, dus je kan verschillende onderdelen met elkaar mengen zodat je de workflow kunt kiezen die precies goed is voor jouw.

Ik ben niet helemaal objectief hier, gezien het feit dat ik voor GitHub werk, maar ik heb dit gedeelte toch toegevoegd omdat ik van veel mensen hoor dat GitHub de specifieke reden was dat ze voor Git gekozen hadden.

GitHub is voor veel mensen een reden om Git te gebruiken omdat het een soort van sociaal netwerk voor code is in plaats van alleen een simpele hosting site. Mensen vinden andere ontwikkelaars of projecten die overeen komen met de dingen die zij doen, en kunnen makkelijk forken en bijdragen, wat een erg broeiende community rondom Git en de projecten waar mensen het voor gebruiken creëert.

Er bestaan andere services, voor Git en de andere SCM's, maar weinig hiervan zijn op de gebruiker georiënteerd of op het sociale gericht, en geen van alle komt in de buurt van de user-base. Dit sociale aspect van GitHub is erg belangrijk, en in combinatie met de features die ik hierboven genoemd heb maakt Git en GitHub een fantastische combinatie voor open source projecten waarin snel ontwikkeld wordt.

Een community als deze is simpelweg niet beschikbaar bij elke van de andere SCM's.

Dit was vroeger niet waar—vroeg in Git's leven, het was niet echt een SCM maar meer een verzameling tools waarmee je op versiebeheer gebaseerd werk kon doen op een gedistribueerde manier. Vandaag de dag komen de commando's en leercurve van Git erg overeen met andere SCM's, en soms zelf beter dan enkele.

Omdat het moeilijk is dit op een objectieve manier te bewijzen zonder een vorm van studie, laat ik je het verschil zien tussen het default 'help' menu voor Mercurial en Git commando's. Ik heb de commando's die identiek (of bijna) zijn gearceerd. (Als je in Hg 'hg help' typt, krijg je een lijst met iets van 40 commando's.)

add        add the specified files ...
annotate   show changeset informati...
clone      make a copy of an existi...
commit     commit the specified fil...
diff       diff repository (or sele...
export     dump the header and diff...
init       create a new repository ...
log        show revision history of...
merge      merge working directory ...
parents    show the parents of the ...
pull       pull changes from the sp...
push       push changes to the spec...
remove     remove the specified fil...
serve      export the repository vi...
status     show changed files in th...
update     update working directory

add        Add file contents to the index
bisect     Find the change that introduce...
branch     List, create, or delete branches
checkout   Checkout a branch or paths to ...
clone      Clone a repository into a new ...
commit     Record changes to the repository
diff       Show changes between commits, ...
fetch      Download objects and refs from...
grep       Print lines matching a pattern
init       Create an empty git repository
log        Show commit logs
merge      Join two or more development h...
mv         Move or rename a file, a direc...
pull       Fetch from and merge with anot...
push       Update remote refs along with ...
rebase     Forward-port local commits to ...
reset      Reset current HEAD to the spec...
rm         Remove files from the working ...
show       Show various types of objects
status     Show the working tree status
tag        Create, list, delete or verify...

Voor Git 1.6, waren alle Git commando's in het executable path, wat erg verwarrend was voor sommige mensen. Git herkend deze commando's nog steeds maar het enige commando in het path is nu 'git'. Als je naar Mercurial en Git kijkt, heeft Git een bijna identieke set van commando's en help systeem—er is erg weinig verschil in een beginnend UI perspectief vandaag de dag.

Tegenwoordig is het best moeilijk om te beargumenteren dat Mercurial of Bazaar makkelijker te leren is dan Git.