We kennen Linus Torvalds als de maker van Linux. Hij heeft daarnaast ook GIT gemaakt. GIT is een source code management systeem, dat zelf volledig open source is. Het combineert technische eigenschappen en sociale aspecten die het bij uitstek geschikt maken voor open source software projecten.
Dezelfde motivatie die destijds ten grondslag lag aan Linux zette Torvalds er ook nu toe aan om zelf iets te maken. Hij was namelijk ontevreden met hetgeen er al was. In zijn presentatie over GIT bij Google talk laat hij zich dan ook negatief uit over CVS (en in mindere mate over Bittracker). Beiden zijn source code beheer systemen met een voor Torvalds onwerkbare opzet (om verschillende redenen overigens). Het kon en moest beter besloot hij en het GIT-project was geboren. De afkorting GIT staat voor 'Global Information Tracker' alhoewel Wikipedia en de home site van GIT daar nog grappige alternatieven voor bieden.
Gedistribueerd
Een van de belangrijkste eisen die Torvalds aan een source code management systeem stelt is dat het gedistribueerd werkt. Dit betekent dat iedereen een eigen versie van de code heeft. De meeste source code management systemen werken daarentegen met een centrale repository (opslag van code) en dat heeft nadelen. De code is daarbij voor alle developers toegankelijk. Daarom zijn er bijvoorbeeld naamconventies nodig zodat code-takken niet dezelfde naam krijgen (ze moeten uniek blijven). Ook zijn er performance problemen. Een vergelijk van twee code-takken (een diff), gaat binnen een centrale repository niet snel genoeg, zeker niet wanneer ook andere developers tegelijkertijd dergelijk bewerkingen uitvoeren. Andere nadelen zijn dat het branchen (aftakken) en mergen (weer samenvoegen) van code-takken erg lastig is. Als laatste noemt Torvalds de noodzaak van security. Een centrale repository heeft een uitgebreide autorisatie nodig. In de praktijk levert dat altijd problemen op.
In het gedistribueerde model van GIT behoren de genoemde problemen tot het verleden. Iedereen heeft een eigen kopie van de code. Het branchen (aftakken) is eenvoudig en er is geen naam conventie nodig. Je kan immers zelf bepalen hoe je een nieuwe code-tak noemt. Ook mergen (samenvoegen) gaat eenvoudig. Performance en security zijn niet langer een issue, je bent immers de enige op het systeem. Code gaat ook niet snel verloren. Meerdere developers hebben een versie van dezelfde code op hun systeem. Tevens doet GIT een checksum (controle op basis van sha) van alle bestanden. Hierdoor komen onbedoelde veranderingen in code bestanden (bijvoorbeeld als gevolg van corruptie van bestanden) meteen aan het licht. De goede performance van GIT leidt tot een andere manier van werken. Doordat bewerkingen op code-takken veel sneller kunnen voer je deze bewerkingen ook makkelijker en dus vaker uit. Omdat daarnaast het branchen (aftakken) van een code-tak zo eenvoudig gaat, nodigt dit developers uit snel nieuwe dingen uit te proberen. Op een centrale repository is dat niet gewenst. Het uiteindelijke resultaat van deze werkwijze is betere code en dat is waar het om gaat.
Als een developer een goed stuk code heeft gemaakt, kan hij dat aan een andere developer geven. Omdat de code-takken makkelijk kunnen mergen (samengevoegd worden), kan het eenvoudig opgenomen worden in het software project. Middels de hiërarchie, die de mensen binnen een software project kennen, wordt bepaald welke code uiteindelijk opgenomen gaat worden. Het is daarmee gebaseerd op het netwerk van vertrouwen dat er tussen de verschillende developers bestaat. Binnen het Linux project is het uiteindelijk Torvalds die bepaalt welke code in de kernel opgenomen wordt.
Bazaar
Naast de technische aspecten interesseert GIT me om nog andere redenen. Het is wederom een mooi voorbeeld van de manier waarop een open source project gestart wordt. Iemand heeft een probleem en zorgt zelf voor een oplossing. Inmiddels werken er vele developers aan GIT mee, blijkbaar voorziet het bij meer mensen in een behoefte.
GIT is naar mijn idee bij uitstek geschikt voor open source software projecten. Het sluit goed aan bij de manier van software ontwikkelen binnen communities. Dit wordt ook wel de bazaar wijze van software ontwikkelen genoemd. Ook past het bij de sociale hiërarchie die binnen open source projecten gebruikelijk is. Commerciële (of defensie gerelateerde) bedrijven zullen mogelijk niet zo blij zijn dat iedere developer de complete code van een software project op zijn laptop mee neemt. Toch kan GIT bijdragen aan kwalitatief betere code, dat is iets dat ook voor deze bedrijven interessant is.
Eigenlijk verbaast het me niet dat juist Linus Torvalds, als grondlegger van het meeste bekende open source project ter wereld (Linux), een source code management systeem bouwt dat bij uitstek geschikt is voor open source projecten. Ik vraag me alleen af wat de marktadoptie is van GIT. Welke bedrijven gaan dit gebruiken?
Hey wat leuk een artikel met inhoud.
Jan ik heb geen idee of bedrijven GIT gaan gebruiken, ik heb ze ook nog nooit over csv, svn en weet ik hoe die dingen allemaal heten gehoord.
De versioning tools die ik in een gedistribueerde omgeving heb gebruikt leverde idd allerlij vervelende ellende met mergen op.
Ik gebruik GIT voor SDR software developement maar zelfs ook daar mondjes maat.
Denk dat je echt heel actief aan grote projecten (zoals GNU-Radio) moet werken om comfortabel met GIT te worden.
Dank voor je artikel.
Leuk artikel. Jammer dat het, aan de reactie van Pascal te oordelen, nogal een learning curve heeft. Aan de andere kant is dat vaak zo.
Wij gebruiken GIT al een geruime tijd, en de voordelen boven bijvoorbeeld SVN zijn behoorlijk groot. Het stagen van verschillende omgevingen (ontwikkeling, test, acceptatie, productie) is super simpel.
Ik begrijp echter niet waarom het bij uitstek voor open-source projecten goed is. Het is voor elke software ontwikkelende organisatie goed.
GIT is ook niet echt nieuw, maar ja, het is wel leuk om een keer wat aandacht te vestigen op een briljant werkend stukje software.
In tegenstelling tot de eerste Pascal heb ik al het nodige gehoord, en gewerkt met diverse versie-beheerstools; hoofdzakelijk met één van de grotere commerciële tools.
Gebaseerd op mijn ervaringen kan ik een groot aantal van de genoemde pro’s van GIT weerleggen. Ik wil daarmee niet stellen dat GIT een slecht tool is, maar de argumenten die genoemd worden komen op mij dubieus over.
– iedereen een eigen versie van de code: voor de performance vaak een groot pluspunt, voor integratie een crime. Het voordeel van een centrale repository is dat de data ook centraal gemanaged wordt. Zo zijn er mogelijkheden om met meerderen op dezelfde code-tak te werken. Voordeel kan zijn dat je direct elkaars wijzigingen ziet. Ook kan zo’n opzet voorkomen dat je parallel aan dezelfde code zit te werken, wat merge problemen achteraf voorkomt. Tot slot kun je op die manier ook nog voorkomen dat je allebei op dezelfde plaats in de bestandsstructuur een nieuw bestand aanmaakt met dezelfde naam, maar met een totaal andere inhoud. Ook dit kan mergeproblemen achteraf voorkomen.
– Je kan immers zelf bepalen hoe je een nieuwe code-tak noemt: dit lijkt me nu juist verre van handig. Ik werk met 20 ontwikkelaars aan een product, en we noemen onze code-tak allemaal “computable”. Als je dan in de versie-boom van de code zou gaan kijken, zie je alleen maar takken die “computable” heten. Hoe weet je nu welke code door welk team of ontwikkelaar gemaakt is? Een naamngevingsconventie gaat je veel helpen hier
– Ook mergen (samenvoegen) gaat eenvoudig: Mergen is niet moeilijk, weten wat je merged, en wat de mogelijke risico’s zijn is vaker het probleem. Op http://www.bits-chips.nl/nieuws/achtergrond/bekijk/artikel/configuratiemanagement-en-hergebruik-een-potentieel-gevaarlijke-combinatie.html vindt je een leuk artikel over mergen en mogelijke issues waar je tegenaan kunt lopen
– Performance is niet langer een issue: voor de individuele gebruiker geldt dit vaak, maar synchronisatie met mede-ontwikkelaars kan, zeker bij grote producten (veel bestanden, grote bestanden), door deze decentrale aanpak behoorlijk wat tijd kosten
– Security is niet langer een issue: kwestie van voorkeur. In een open source omgeving is dit wellicht niet zo’n issue, maar als je commerciële producten maakt, die moeten voldoen aan defensie, automotive-, medische- of luchtvaartregelgevingen, dan wil je juist wel een degelijke security hebben. Je wil, ergo, moet, dan precies kunnen aantonen wie wat wanneer gewijzigd heeft en waarom. Je wil al helemaal niet dan Jan en alleman de code aan kunnen passen
– Het uiteindelijke resultaat van deze werkwijze is betere code: goede code wordt niet gemaakt door een versiebeheers-systeem, maar door een ontwikkelaar. Systeem als GIT, en alle andere, helpen je slechts in het managen van deze code. Een dergelijk systeem KAN, let wel, KAN, je hierbij helpen. Echter, bij verkeerd gebruik (bijvoorbeeld een verkeerde branch- en mergestrategie) richt het meer schade aan dan je lief is!
Met GIT én met andere versiebeheer systemen is het belangrijk configuratie en broncode gescheiden te houden. Hiermee voorkom je dat wanneer broncode op straat komt, er meteen zeer kritische informatie lekt. Dit kan ook in het voordeel werken van commerciële en defensie bedrijven. Je traint je developers om essentieel onderscheid te maken tussen configuratie en code waardoor code eigenlijk nooit écht bruikbaar is als je niet bent aangesloten op een informatiebron.
Bijvoorbeeld: Wanneer de berekening van een vluchtroute voor een projectiel in verkeerde handen komt is er niets aan de hand. Wanneer informatie over het op afstand activeren van een lanceer-installatie op straat komt wél! Het dwingt developers ook om geen hardcoded wachtwoorden of verificatie-sleutels in broncode te stoppen, maar met hashing technieken te werken.
Al met al denk ik dus dat ook defensie of commmercie gebaat KAN zijn bij deze manier van ontwikkelen.
@Pascal van Kempen:
Bij goede organisatie en management van software ontwikkeling kan GIT een prima tool zijn. In alle andere gevallen is versiebeheer sowieso een crime. Versiebeheer biedt geen oplossing voor slechte communicatie of management.
– Integratie is het speerpunt van GIT, Ik denk dat je over dit tegenargument een keer een discussie moet voeren met Linus en zijn team van vele duizenden ontwikkelaars 😉 Alle onder het eerste punt genoemde tegenargumenten zijn op te lossen door een goede hierarchie van deel-teams, die uiteraard goed gemanaged moeten worden.
@miblon
De crux zit’m in je laatste zin: het moet goed gemanaged worden
Dit kun je in een tool proberen af te vangen, in een organisatie of in een mix hiervan.
De grootste uitdaging is dit alles op elkaar af te stemmen, met ondersteuning van één of meerdere tools.
Afhankelijk van o.a. je ontwikkel-, integratie-, test- en releasestrategie kun je vervolgens een ondersteunend pakket kiezen.
In het ene geval zal GIT je een goede oplossing bieden, in andere gevallen kom je uit op een ander pakket (subversion, collabnet, ClearCase, Rational (CM) Synergy, Perforce, Team Foundation Server en ga zo maar door)
Zoals in mijn reactie al gezegd: ik wil niet zeggen dat GIT een slecht tool is, maar de argumenten die genoemd worden voor GIT kunnen in een andere omgeving zwaar tegen je werken.
Ik werk zelf met GIT en ik moet zeggen dat GIT een hele goeie tool is voor serieuze ontwikkelaars. Wel moet ik zeggen dat het een steile leercurve heeft, zoals Vim voor tekst editors.
Er zijn bepaalde mensen die weer de nadelen noemen van GIT, maar binnen een bedrijf is het een kwestie van goede afspraken maken en een goede manager die de boel goed bijhoudt. Als je wilt dat source code niet zomaar op straat ligt, gebruik dan TrueCrypt, da’s dan ook echt de enige oplossing. Voor de rest is het een uitstekende tool, maar dat is Bazaar ook (wordt o.a. gebruikt door MySQL, BugZilla en andere grote projecten).
Voor de minder moeilijke tools zijn er ook zat alternatieven. Ik denk dat Pascal van Kempen GIT gewoon niet goed genoeg begrijpt. Maar wel ben ik met hem eens dat het gaat om goed managen en een goede stabiele software wordt ontwikkeld door een goede ontwikkelaar en dat is niet op te lossen door een goede SCM.