Fork-werkstroom verkennen
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 serverzijde.
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 forkingswerkstroom is doorgaans bedoeld voor het samenvoegen in de opslagplaats van de oorspronkelijke projectonderhouder.
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, worden de officiële opslagplaats niet rechtstreeks gekloond.
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 doorvoering te publiceren, pushen ze de doorvoer naar hun openbare opslagplaats, 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 'forks' een officiële opslagplaats aan de serverzijde. Er wordt een kopie aan de serverzijde gemaakt.
- De nieuwe kopie aan de serverzijde wordt gekloond naar het 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 doorvoeringen gemaakt voor de wijzigingen.
- De vertakking wordt gepusht naar de kopie aan de serverzijde van de ontwikkelaar.
- De ontwikkelaar opent een pull-aanvraag vanuit de nieuwe vertakking naar de officiële opslagplaats.
- 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'-opslagplaatsen en 'forking' geen speciale bewerkingen zijn.
Geforkte opslagplaatsen worden gemaakt met behulp van de standaard git-kloonopdracht. Geforkte opslagplaatsen zijn over het algemeen 'klonen aan de serverzijde' die worden beheerd en gehost door een Git-serviceprovider, zoals Azure-opslagplaatsen.
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.