Binnenste bron beschrijven met vorken
Personen forken repositories wanneer ze de code in een opslagplaats willen wijzigen waar ze geen schrijf-toegang tot hebben.
Als u geen schrijftoegang hebt, maakt u geen deel uit van het team dat bijdraagt aan die opslagplaats, dus waarom zou u de codeopslagplaats wijzigen?
We zoeken vaak naar technische redenen om iets in ons werk te verbeteren.
Het is mogelijk dat u een betere manier vindt om de oplossing te implementeren of de functionaliteit te verbeteren door een bijdrage te leveren aan of te verbeteren van een bestaande functie.
U kunt fork van repositories maken in de volgende situaties:
- Ik wil een wijziging aanbrengen.
- Ik denk dat het project spannend is en het misschien wil gebruiken.
- Ik wil code in die opslagplaats gebruiken als uitgangspunt voor mijn project.
Softwareteams worden aangemoedigd om intern bij te dragen aan alle projecten, niet alleen aan hun softwareprojecten.
Forks zijn een geweldige manier om een cultuur van interne open source te bevorderen.
Forks zijn een recente toevoeging aan de Azure DevOps Git-opslagplaatsen.
Met dit recept leert u een bestaande opslagplaats te splitsen en wijzigingen upstream bij te dragen via een pull-aanvraag.
Klaarmaken
Een fork begint met alle inhoud van zijn upstream (oorspronkelijke) repository.
Wanneer u een fork maakt in Azure DevOps, kunt u alle vertakkingen opnemen of beperken tot alleen de standaardbranch.
Een fork kopieert niet de machtigingen, beleidsregels of builddefinities van de opslagplaats die geforkt wordt.
Nadat een fork is gemaakt, worden de zojuist gemaakte bestanden, mappen en vertakkingen niet gedeeld tussen de opslagplaatsen, tenzij u een pull-aanvraag start.
Pull requests worden in beide richtingen ondersteund: van fork naar upstream of van upstream naar fork.
De meest voorkomende benadering voor een pull-aanvraag is van fork naar upstream.
Hoe u dit doet
Kies de knop Fork (1) en selecteer vervolgens het project waar u de fork wilt maken (2). Geef uw fork een naam en kies de knop Fork (3).
Zodra uw fork gereed is, kloont u deze met behulp van de opdrachtregel of een IDE, zoals Visual Studio. De fork is uw oorsprong op afstand. Voor het gemak wilt u de upstream repository (waarvan u een fork hebt gemaakt) toevoegen als een remote met de naam upstream. Typ in de opdrachtregel:
git remote add upstream {upstream_url}Het is mogelijk om rechtstreeks in de hoofdbranch te werken. Deze fork is uw kopie van de repository. We raden u echter aan om nog steeds in een thematak 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 ze naar de origin (uw fork).
Open een pull-aanvraag van uw fork naar de upstream. De upstream-opslagplaats past alle beleidsregels toe die vereist zijn voor revisoren en builds. Zodra aan alle beleidsregels is voldaan, kan de pull-aanvraag (PR) worden voltooid en worden de wijzigingen een permanent onderdeel van de upstream-repository.
Wanneer uw pull request upstream wordt geaccepteerd, moet u ervoor zorgen dat uw fork de meest recente stand van de repo weerspiegelt. Wij raden aan om de main branch van de upstream opnieuw als basis te gebruiken (ervan uitgaande dat deze de hoofdontwikkelingsvertakking is). Voer op de opdrachtregel het volgende uit:
git fetch upstream main git rebase upstream/main git push origin
Zie voor meer informatie over Git: