Git
Chapters ▾ 2nd Edition

5.1 Gedistribueerd Git - Gedistribueerde workflows

Nu je een remote Git repository hebt ingesteld als een plaats waar alle ontwikkelaars hun code kunnen delen, en je bekend bent met fundamentele Git commando’s in een lokale workflow, zul je hier zien hoe je enkele van de gedistribueerde workflows kunt gebruiken waar Git je toe in staat stelt.

In dit hoofdstuk zul je zien hoe je met Git kunt werken in een gedistribueerde omgeving als een bijdrager (contributor) en als een integrator. Dat wil zeggen, je zult leren hoe je succesvol code kunt bijdragen aan een project en hoe je het zo makkelijk mogelijk maakt voor jou en de beheerder van het project, en ook hoe je een project succesvol kunt onderhouden waar een aantal ontwikkelaars aan bijdragen.

Gedistribueerde workflows

In tegenstelling tot gecentraliseerde versiebeheersystemen (CVCSen), stelt de gedistribueerde aard van Git je in staat om veel flexibeler te zijn in de manier waarop ontwikkelaars samenwerken in projecten. Bij gecentraliseerde systemen is iedere ontwikkelaar een knooppunt dat min of meer gelijkwaardig werkt op een centraal punt. In Git echter is iedere ontwikkelaar zowel een knooppunt als een spil — dat wil zeggen, iedere ontwikkelaar kan zowel code bijdragen aan andere repositories, als ook een publiek repository beheren waarop andere ontwikkelaars hun werk baseren en waaraan zij kunnen bijdragen. Dit stelt je project en/of je team in staat om een enorm aantal workflows er op na te houden, dus ik zal een aantal veel voorkomende manieren behandelen die gebruik maken van deze flexibiliteit. We zullen de sterke en mogelijke zwakke punten van ieder ontwerp behandelen; je kunt er een kiezen om te gebruiken, of je kunt van iedere wijze een paar eigenschappen overnemen en mengen.

Gecentraliseerde workflow

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.

Gecentraliseerde workflow.
Figuur 54. Gecentraliseerde workflow.

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.

Integratie-manager workflow

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.):

  1. De projecteigenaar pusht naar de publieke repository.

  2. Een bijdrager kloont die repository en maakt wijzigingen.

  3. De bijdrager pusht naar zijn eigen publieke kopie.

  4. De bijdrager stuurt de eigenaar een e-mail met de vraag om de wijzigingen binnen te halen.

  5. De eigenaar voegt de repo van de bijdrager toe als een remote en merget lokaal.

  6. De eigenaar pusht de gemergde wijzigingen terug in de hoofdrepository.

Integratie-manager workflow.
Figuur 55. 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.

Dictator en luitenanten workflow

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.):

  1. Reguliere ontwikkelaars werken op hun eigen onderwerp (topic) branch en rebasen hun werk op de master. De master-branch is die van de referentie-repository waar de dictator naar toe pusht.

  2. Luitenanten mergen de topic branches van de ontwikkelaars in hun master-branch.

  3. De dictator merged de master-branches van de luitenanten in de master-branch van de dictator.

  4. De dictator pusht zijn master-branch ten slotte terug naar het referentie-repository zodat de andere ontwikkelaars op deze kunnen rebasen.

Benevolent dictator workflow.
Figuur 56. 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.

Workflows samenvatting

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.

scroll-to-top