Implementeren van de fork-werkstroom
Een fork is een kopie van een opslagplaats. Het forken van een opslagplaats stelt u in staat om vrij te experimenteren met wijzigingen zonder dat dit van invloed is op het oorspronkelijke project.
Meestal worden forks gebruikt om wijzigingen aan het project van iemand anders voor te stellen. Of gebruik het project van iemand anders als uitgangspunt voor uw idee.
Een fork is een volledige kopie van een opslagplaats, inclusief alle bestanden, commits en (optioneel) vertakkingen.
Forks zijn een uitstekende manier om een interne bronwerkstroom te ondersteunen: u kunt een fork maken om wijzigingen voor te stellen wanneer u niet rechtstreeks bent gemachtigd om naar het oorspronkelijke project te schrijven.
Zodra u klaar bent om deze wijzigingen te delen, is het eenvoudig om ze terug te sturen met behulp van pull requests.
Wat zit er in een vork?
Een fork begint met alle inhoud van de upstream (oorspronkelijke) repository.
U kunt alle vertakkingen opnemen of beperken tot alleen de standaardbranch wanneer u een fork maakt.
Geen van de machtigingen, beleidsregels of build-pijplijnen worden toegepast.
De nieuwe fork fungeert alsof iemand de oorspronkelijke opslagplaats heeft gekloond en deze vervolgens naar een nieuwe, lege opslagplaats heeft gepusht.
Nadat een fork is gemaakt, worden nieuwe bestanden, mappen en vertakkingen niet gedeeld tussen de opslagplaatsen, tenzij een pull-aanvraag (PR) deze meeneemt.
Code delen tussen forks
U kunt PR's maken in beide richtingen: van fork naar upstream of van upstream naar fork.
De meest voorkomende benadering is van fork tot upstream.
De machtigingen, beleidsregels, builds en werkitems van de doelopslagplaats zijn van toepassing op het pull-verzoek.
Kiezen tussen vertakkingen en forks
Voor een klein team (2-5 ontwikkelaars) raden we u aan om in één opslagplaats te werken.
Iedereen moet in een onderwerptak werken en de hoofdtak moet worden beveiligd met branchbeleid.
Naarmate uw team aanzienlijk groter wordt, kunt u merken dat u deze opzet ontgroeit en liever overschakelt naar een forkingsworkflow.
U wordt aangeraden de werkstroom te splitsen als uw opslagplaats veel informele of onregelmatige commissies heeft (zoals een opensource-project).
Normaal gesproken hebben alleen kernbijdragers aan uw project directe doorvoerrechten in uw opslagplaats.
Het kan helpen als u samenwerkers van buiten deze kerngroep van mensen vraagt om te werken vanuit een fork van de repository.
Ook zal het hun wijzigingen van jou isoleren totdat je de kans hebt gehad om het werk te controleren.
De werkstroom voor het forken
- Maak een fork.
- Kloon deze lokaal.
- Breng uw wijzigingen lokaal aan en verzend ze naar een tak.
- Maak en voltooi een pull-aanvraag naar upstream.
- Synchroniseer uw fork naar de nieuwste versie van upstream.
De fork maken
- Navigeer naar de repository om te forken en kies fork.
- Geef een naam op en kies het project waar u de fork wilt maken. Als de opslagplaats veel onderwerpbranches bevat, raden we u aan alleen de standaardbranch te splitsen.
- Kies het beletselteken, en selecteer daarna "Fork" om de fork te maken.
Notitie
U moet de permissie hebben om een repository aan te maken in het gekozen project voordat u een fork kunt maken. U wordt aanbevolen om een speciaal project te maken voor forks waarbij alle bijdragers de machtiging hebben om een repository te maken. Zie Git-opslagplaatsmachtigingen instellen voor een voorbeeld van het verlenen van deze machtiging.
Uw fork lokaal klonen
Zodra uw fork klaar is, kloont u deze met behulp van de opdrachtregel of een IDE zoals Visual Studio. De fork zal uw originele remote zijn.
Voor het gemak wil je na het klonen de upstream-opslagplaats (waar je vandaan hebt geforkt) toevoegen als een externe verbinding met de naam upstream.
git remote add upstream {upstream_url}
Wijzigingen aanbrengen en doorvoeren
Het is mogelijk om rechtstreeks in main te werken, aangezien deze fork uw kopie van de opslagplaats is.
U wordt echter aangeraden nog steeds in een onderwerpbranch te werken.
Hiermee kunt u meerdere onafhankelijke werkstromen tegelijk onderhouden.
Het vermindert ook verwarring later wanneer u wijzigingen in uw fork wilt synchroniseren.
Breng uw wijzigingen aan en voer deze door zoals u dat normaal zou doen. Wanneer u klaar bent met de wijzigingen, pusht u deze naar origin (uw fork).
Een pull-aanvraag (pull request) maken en voltooien
Open een pull-aanvraag van uw fork naar de upstream. Alle beleidsregels die betrekking hebben op revisoren en builds worden toegepast in de upstream-repository. Zodra aan alle beleidsregels is voldaan, kan de pull request worden voltooid en worden de wijzigingen een permanent onderdeel van de upstream-repository.
Belangrijk
Iedereen met leesrechten kan een pull-aanvraag naar upstream openen. Als een pull-aanvraag-build-pijplijn is geconfigureerd, wordt de build uitgevoerd op basis van de code die in de fork is geïntroduceerd.
Uw fork synchroniseren met de nieuwste versie
Wanneer je pull request is geaccepteerd in upstream, moet je ervoor zorgen dat je fork de meest recente status van de repository weerspiegelt.
We raden u aan de hoofdvertakking van upstream opnieuw te gebruiken (ervan uitgaande dat main de hoofdontwikkelingsvertakking is).
git fetch upstream main
git rebase upstream/main
git push origin
Met de forkingswerkstroom kunt u wijzigingen van de hoofdopslagplaats isoleren totdat u klaar bent om ze te integreren. Wanneer u klaar bent, is de integratie van code net zo eenvoudig als het voltooien van een pull-aanvraag.