Fork-werkstroom ontdekken
De forkingswerkstroom is fundamenteel anders dan andere populaire Git-werkstromen.
In plaats van één opslagplaats aan de serverzijde te gebruiken om te fungeren als de centrale codebase, biedt het elke ontwikkelaar de opslagplaats aan de serverzijde.
Dit betekent dat elke inzender twee Git-opslagplaatsen heeft:
- Een privé lokale.
- Een openbare serverside.
De forkingswerkstroom wordt het vaakst gezien in openbare opensource-projecten.
Het belangrijkste voordeel van de forkingswerkstroom is dat bijdragen kunnen worden geïntegreerd zonder dat iedereen naar één centrale opslagplaats hoeft te pushen.
Ontwikkelaars pushen naar hun opslagplaatsen aan de serverzijde en alleen de projectonderhouder kan pushen naar de officiële opslagplaats.
Hiermee kan de onderhouder doorvoeringen van elke ontwikkelaar accepteren zonder ze schriftelijke toegang te geven tot de officiële codebasis.
De forking-werkstroom is doorgaans bedoeld voor het samenvoegen naar de opslagplaats van de oorspronkelijke projectbeheerder.
Het resultaat is een gedistribueerde werkstroom die u een flexibele manier biedt voor grote, organische teams (inclusief niet-vertrouwde derden) om veilig samen te werken.
Dit maakt het ook een ideale werkstroom voor opensource-projecten.
Hoe het werkt
Net als in de andere Git-werkstromen begint de forkingswerkstroom met een officiële openbare opslagplaats die is opgeslagen op een server.
Maar wanneer een nieuwe ontwikkelaar aan het project wil gaan werken, klonen ze niet rechtstreeks deze officiële opslagplaats.
In plaats daarvan splitsen ze de officiële opslagplaats om er een kopie van te maken op de server.
Deze nieuwe kopie fungeert als hun persoonlijke openbare opslagplaats. Er kunnen geen andere ontwikkelaars ernaar pushen, maar ze kunnen er wijzigingen van ophalen (we zien waarom dit in een ogenblik nodig is).
Nadat ze hun kopie aan de serverzijde hebben gemaakt, voert de ontwikkelaar een Git-kloon uit om een kopie ervan op hun lokale computer op te halen.
Het fungeert als hun privéontwikkelingsomgeving, net als in de andere werkstromen.
Wanneer ze klaar zijn om een lokale commit te publiceren, pushen ze de commit naar hun openbare repository, niet naar de officiële.
Vervolgens dienen ze een pull-aanvraag in bij de hoofdopslagplaats, zodat de projectonderhouder weet dat een update gereed is om te worden geïntegreerd.
De pull-aanvraag fungeert ook als een handige discussiethread als er problemen zijn met de bijgedragen code.
Hier volgt een stapsgewijze voorbeeld van deze werkstroom:
- Een ontwikkelaar 'forkt' een officiële serverzijde-opslagplaats. Het creëert hun server-side kopie.
- De nieuwe serverkopie wordt gekloond naar hun lokale systeem.
- Er wordt een extern Git-pad voor de officiële opslagplaats toegevoegd aan de lokale kloon.
- Er wordt een nieuwe lokale functiebranch gemaakt.
- De ontwikkelaar brengt wijzigingen aan in de nieuwe vertakking.
- Er worden nieuwe commits gemaakt voor de wijzigingen.
- De vertakking wordt gepusht naar de kopie aan de serverzijde van de ontwikkelaar.
- De ontwikkelaar opent een pull request vanuit de nieuwe branch naar de officiële repository.
- De pull-aanvraag wordt goedgekeurd voor samenvoegen en wordt samengevoegd in de oorspronkelijke opslagplaats aan de serverzijde.
De functie integreren in de officiële codebase:
- De onderhouder haalt de wijzigingen van de inzender op in de lokale opslagplaats.
- Controleert of het project niet wordt verbroken.
- Voegt deze samen in hun lokale hoofdbranch.
- Pusht de hoofdbranch naar de officiële opslagplaats op de server.
De bijdrage maakt nu deel uit van het project en andere ontwikkelaars moeten uit de officiële opslagplaats halen om hun lokale opslagplaatsen te synchroniseren.
Het is essentieel om te begrijpen dat het idee van een 'officiële' opslagplaats in de forkingswerkstroom slechts een conventie is.
Het enige dat de officiële opslagplaats maakt, dus officieel is dat het de opslagplaats van de projectonderhouder is.
Forking versus klonen
Het is essentieel om te weten dat 'forked' repositories en 'forking' geen speciale bewerkingen zijn.
Geforkte opslagplaatsen worden gemaakt met behulp van de standaard git-kloonopdracht. Geforkte repositories zijn over het algemeen 'servergedreven klonen' die worden beheerd en gehost door een Git-service zoals Azure Repos.
Er is geen unieke Git-opdracht om geforkte opslagplaatsen te maken.
Een kloonbewerking is in wezen een kopie van een opslagplaats en de geschiedenis ervan.