5.1 Gedistribueerd Git - Gedistribueerde workflows

In gecentraliseerde systemen is er over het algemeen een enkel samenwerkingsmodel — de gecentraliseerde workflow. Eén centraal punt, of repository, kan code aanvaarden en iedereen synchroniseert zijn werk daarmee. Een aantal ontwikkelaars zijn knopen — gebruikers van dat centrale punt - en synchroniseren met die ene plaats.

Dit houdt in dat als twee ontwikkelaars klonen van het gecentraliseerde punt en beiden wijzigingen doen, de eerste ontwikkelaar zijn wijzigingen zonder problemen kan pushen. De tweede ontwikkelaar zal het werk van de eerste in het zijne moeten mergen voordat hij het zijne kan pushen, om zo niet het werk van de eerste te overschrijven. Dit concept werkt in Git zoals het ook werkt in Subversion (of ieder ander CVCS), en dit model werkt prima in Git.

Als je al vertrouwd bent met een gecentraliseerde workflow in je bedrijf of team, dan kun je eenvoudigweg doorgaan met het gebruiken van die workflow met Git. Stel eenvoudigweg een enkele repository in, en geef iedereen in je team push-toegang; Git zal gebruikers niet toestaan om elkaars wijzigingen te overschrijven.

Stel dat John en Jessica beiden tegelijkertijd beginnen te werken. John is klaar met zijn wijziging en pusht deze naar de server. Vervolgens probeert Jessica haar wijzigingen te pushen, maar de server weigert deze. Haar wordt verteld dat ze non-fast-forward wijzigingen probeert te pushen, en dat ze niet kan committen totdat ze gefetcht en gemerged heeft. Deze workflow spreekt veel mensen aan omdat het een werkwijze is waarmee veel mensen bekend zijn en zich hierbij op hun gemak voelen.

Deze workflow is echter niet beperkt tot alleen kleine teams. Met het branching model van Git is het mogelijk om honderden ontwikkelaars tegelijktijdig succesvol te laten werken op een enkel project middels tientallen branches.

Omdat Git je toestaat om meerdere remote repositories te hebben, is het mogelijk om een workflow te hebben waarbij iedere ontwikkelaar schrijftoegang heeft tot zijn eigen publieke repository en leestoegang op die van de anderen. In dit scenario is er vaak een gezagdragend (canonical) repository dat het “officiële” project vertegenwoordigt. Om bij te kunnen dragen tot dat project, maak je je eigen publieke kloon van het project en pusht je wijzigingen daarin terug. Daarna stuur je een verzoek naar de eigenaar van het hoofdproject om jouw wijzigingen binnen te halen. Hij kan je repository toevoegen als een remote, je wijzigingen lokaal testen, ze in zijn branch mergen, en dan naar zijn repository pushen. Het proces werkt als volgt (zie Integratie-manager workflow.):

Dit is een veel voorkomende workflow bij websites zoals GitHub of GitLab, waarbij het eenvoudig is om een project af te splitsen (fork) en je wijzigingen te pushen in jouw afgesplitste project waar iedereen ze kan zien. Een van de grote voordelen van deze aanpak is dat je door kunt gaan met werken, en de eigenaar van de hoofdrepository jouw wijzigingen op ieder moment kan binnenhalen. Bijdragers hoeven niet te wachten tot het project hun bijdragen invoegt — iedere partij kan in zijn eigen tempo werken.

Dit is een variant op de multi-repository workflow. Het wordt over het algemeen gebruikt bij enorme grote projecten met honderden bijdragers; een bekend voorbeeld is de Linux-kernel. Een aantal integrators hebben de leiding over bepaalde delen van de repository, zij worden luitenanten genoemd. Alle luitenanten hebben één integrator die bekend staat als de welwillende dictator (benevolent dictator). De repository van de welwillende dictator dient als het referentie-repository vanwaar alle bijdragers dienen te pullen. Het proces werkt als volgt (zie Benevolent dictator workflow.):

Deze manier van werken is niet gewoon, maar kan handig zijn in hele grote projecten of in zeer hiërarchische omgevingen Het stelt de projectleider (de dictator) in staat het meeste werk te delegeren en grote subsets van code te verzamelen op meerdere punten alvorens ze te integreren.

Dit zijn een aantal veel voorkomende workflows die mogelijk zijn met een gedistribueerd systeem als Git, maar je kunt zien dat er veel variaties mogelijk zijn om ze te laten passen bij jouw specifieke workflow. Nu dat je (naar we hopen) in staat bent om te bepalen welke combinatie van workflows voor jou werkt, zullen we wat specifiekere voorbeelden behandelen hoe je de belangrijkste rollen kunt vervullen die in de verschillende workflows voorkomen. In de volgende paragraaf zal je kennis maken met een aantal reguliere patronen voor het bijdragen aan een project.