Voorvorken

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

Git-opslagplaatsen zijn handig wanneer mensen experimentele, riskante of vertrouwelijke wijzigingen willen aanbrengen in een codebasis, maar deze wijzigingen moeten worden geïsoleerd van de codebasis in de oorspronkelijke opslagplaats. Een nieuwe fork is in feite een kloon van de oorspronkelijke opslagplaats die naar een nieuwe externe opslagplaats wordt gepusht. De fork is onafhankelijk van de oorspronkelijke opslagplaats en is een volledige kopie, tenzij u één vertakking opgeeft.

Als onafhankelijke kopie worden wijzigingen die u aanbrengt in uw fork, zoals het toevoegen van doorvoeringen of vertakkingen, niet gedeeld met de oorspronkelijke opslagplaats. Als u de wijzigingen in de codebasis wilt samenvoegen in de oorspronkelijke opslagplaats, moet u een pull-aanvraag (PR) maken om een beoordeling en goedkeuring van deze wijzigingen aan te vragen.

Het forkingsproces brengt geen machtigingen, beleidsregels of build-pijplijnen van de oorspronkelijke opslagplaats over naar uw fork.

In dit artikel vindt u informatie over het werken met forks in Git-opslagplaatsen van Azure Repos en vindt u koppelingen naar GitHub-inhoud waarin wordt beschreven hoe u Forks beheert in GitHub-opslagplaatsen.

In dit artikel leert u het volgende:

  • Code delen tussen forks
  • Kiezen tussen vertakkingen en forks
  • Repo-forks inschakelen
  • Een fork maken
  • Uw fork lokaal klonen
  • Lokale wijzigingen naar uw fork pushen
  • Een pull-aanvraag maken en voltooien
  • Uw fork synchroniseren

Vereisten voor toegang tot Azure-opslagplaatsen

  • Opslagplaatsen moeten zijn ingeschakeld in uw Azure DevOps-projectinstellingen. Als de opslagplaatshub en de bijbehorende pagina's niet worden weergegeven, raadpleegt u Een Azure DevOps-service in- of uitschakelen om opslagplaatsen opnieuw in of uit te schakelen.

  • Als u code in privéprojecten wilt weergeven, moet u lid zijn van een Azure DevOps-project met basistoegangsniveau of hoger. Voor openbare projecten kan iedereen de code bekijken.

  • Als u code voor een privéproject wilt klonen of hieraan wilt bijdragen, moet u lid zijn van de beveiligingsgroep Inzenders of de bijbehorende machtigingen hebben ingesteld. Voor openbare projecten kan iedereen code klonen en bijdragen. Zie Wat is een openbaar project voor meer informatie?

    Notitie

    Voor openbare projecten hebben gebruikers aan belanghebbenden volledige toegang tot Azure-opslagplaatsen.

  • Opslagplaatsen moeten zijn ingeschakeld in uw Azure DevOps-projectinstellingen. Als de opslagplaatshub en de bijbehorende pagina's niet worden weergegeven, raadpleegt u Een Azure DevOps-service in- of uitschakelen om opslagplaatsen opnieuw in of uit te schakelen.

  • Als u code wilt weergeven, moet u lid zijn van het Azure DevOps-project met Basic-toegang of hoger. Als u geen projectlid bent, wordt u toegevoegd.

  • Als u code wilt klonen of hieraan wilt bijdragen, moet u lid zijn van de beveiligingsgroep Inzenders of de bijbehorende machtigingen hebben in het project dat u wilt wijzigen.

Code delen tussen forks

De oorspronkelijke opslagplaats wordt vaak de upstream-opslagplaats genoemd. U kunt PULL's maken om wijzigingen in beide richtingen samen te voegen: van fork naar upstream of upstream naar fork. De meest voorkomende richting is van fork naar upstream. De machtigingen, beleidsregels, builds en werkitems van de doelopslagplaats zijn van toepassing op de pull-aanvraag.

Kiezen tussen vertakkingen en forks

Voor een klein team van 2-5 ontwikkelaars is een forkingswerkstroom mogelijk niet nodig omdat iedereen in functievertakkingen en vertakkingsbeleid kan werken, de standaardvertakking kan beveiligen. Als uw team deze rangschikking echter uitbreidt en uitgroeit, kunnen ze overschakelen naar een forkingswerkstroom.

Als uw opslagplaats een groot aantal ongedwongen of onregelmatige doorvoerers heeft, zoals een opensource-project, raden we de forkingswerkstroom aan. Normaal gesproken moeten alleen kernbijdragers voor uw project directe doorvoerrechten hebben voor uw oorspronkelijke opslagplaats. Andere medewerkers moeten een forkingswerkstroom gebruiken om hun voorgestelde wijzigingen te isoleren totdat de belangrijkste inzenders de kans hebben om hun werk te beoordelen.

Repo-forks inschakelen

Als u forks wilt inschakelen voor een Git-opslagplaats voor Azure-opslagplaatsen, raadpleegt u Forks inschakelen.

Zie Het forkingsbeleid voor uw organisatie beheren om forks in te schakelen voor een GitHub-opslagplaats.

De werkstroom voor het forken

De werkstroom voor het forken bestaat uit vijf stappen die worden beschreven in de volgende secties.

  1. Een fork maken
  2. Uw fork lokaal klonen
  3. Lokale wijzigingen naar uw fork pushen
  4. Een pull-aanvraag maken en voltooien
  5. Uw fork synchroniseren

Een fork maken

In de volgende stappen wordt beschreven hoe u een Git-opslagplaats voor Azure-opslagplaatsen kunt splitsen.

Notitie

Als u een opslagplaats in een Azure DevOps-project wilt splitsen, moet u de machtiging Opslagplaats maken voor dat project hebben. Eigenaren van opslagplaatsen moeten overwegen een toegewezen project voor forks te maken en de machtiging Opslagplaats maken toe te wijzen aan alle inzenders. Zie Machtigingen voor Git-opslagplaatsen instellen voor meer informatie over het instellen van machtigingen.

  1. Navigeer vanuit uw webbrowser naar de Git-opslagplaats van Azure-opslagplaatsen die u wilt splitsen. Selecteer Opslagplaatsbestanden > en kies vervolgens Fork in het menu met het beletselteken om het dialoogvenster Fork te openen.

    Schermopname van het menu-item Fork in het menu Meer acties op de pagina Opslagplaatsen in Azure-opslagplaatsen.

  2. Geef in het fork-dialoogvenster de naam van de geforkte opslagplaats, kies het project waarin u de fork wilt maken, selecteer de vertakkingen die u wilt opnemen in de fork en kies vervolgens Fork. U kunt opgeven of de fork alle vertakkingen of alleen de standaardbranch bevat. Als de opslagplaats verschillende onderwerpvertakkingen bevat, kunt u overwegen alleen de standaardvertakking in uw fork op te nemen.

    Schermopname van het dialoogvenster Fork op de pagina Opslagplaatsen in Azure-opslagplaatsen.

Zie Fork a repo fork a repo voor meer informatie over het splitsen van een GitHub-opslagplaats.

Uw fork lokaal klonen

Nadat u een opslagplaats hebt gesplitst, kloont u uw fork om een lokale kopie te maken in een map op uw computer. U kunt klonen vanaf de opdrachtregel of met behulp van een IDE zoals Visual Studio. Zie Een bestaande Git-opslagplaats klonen voor meer informatie over het klonen van een opslagplaats.

Wanneer u een externe opslagplaats kloont, wijst Git de alias origin toe als afkorting voor de URL van de externe opslagplaats die u hebt gekloond. Voor het gemak voegt u een andere alias toe met de naam upstream van de opslagplaats waaruit u bent gesplitst. Dit wordt de upstream-opslagplaats genoemd. In de volgende stappen wordt beschreven hoe u een upstream alias toevoegt.

Tip

Voor het gemak kunt u de origin en upstream aliassen gebruiken in plaats van de bijbehorende URL's in uw Git-opdrachten.

Voer de volgende stappen uit om een upstream alias toe te voegen in Visual Studio:

  1. Kies Extra > opties in de menubalk om het venster Opties te openen. Selecteer Git-opslagplaats voor broncodebeheer > Instellingen > Externe apparaten en kies Vervolgens Toevoegen om het dialoogvenster Externe toevoegen te openen.

    Schermopname van de knop Toevoegen in het deelvenster Externen van de Git-opslagplaats Instellingen submenu van het menu Broncodebeheer in Visual Studio 2019.

  2. Voeg in het dialoogvenster Externe toevoegen een nieuwe externe naam upstream toe en voer de Git-kloon-URL in van de opslagplaats die u hebt gesplitst. Kies Vervolgens Opslaan.

    Schermopname van het dialoogvenster Extern toevoegen in Visual Studio 2019.

Lokale wijzigingen naar uw fork pushen

Wanneer u forkt, maakt u een persoonlijke en onafhankelijke kopie van de externe opslagplaats. Er is dus niets om te voorkomen dat u rechtstreeks in de main vertakking van de lokale kloon werkt en dat werk vervolgens naar de main vertakking van uw fork pusht. Over het algemeen is het echter beter om functiebranches voor uw werk te gebruiken. Door functiebranches te gebruiken:

  • U kunt meerdere, onafhankelijke werkstromen tegelijk onderhouden.

  • U maakt het voor anderen gemakkelijker om inzicht te krijgen in het werk dat u deelt, omdat dat werk is ingedeeld in afzonderlijke werkstromen per vertakking.

Een typische Git-werkstroom omvat deze stappen:

  1. Maak een lokale functie of foutoplossingsvertakking.

  2. Breng wijzigingen aan in de nieuwe vertakking en voer uw werk door . Normaal gesproken maken mensen meerdere doorvoeringen bij het werken aan een functie of foutoplossing.

  3. Push de functie of foutoplossingsvertakking naar uw fork. Uw fork heeft de alias origin.

Zie Code delen met push voor meer informatie over het pushen van uw wijzigingen.

Een pull-aanvraag maken en voltooien

Als u in Azure-opslagplaatsen de wijzigingen die u naar uw fork hebt gepusht, wilt samenvoegen in de oorspronkelijke opslagplaats, kunt u het volgende doen:

  1. Maak een pull-aanvraag om uw wijzigingen te controleren en te goedkeuren. Wanneer u een pull-aanvraag opent, stelt u de PR-bronvertakking in op de functie- of bugfixvertakking in uw fork. De pull-doelvertakking is doorgaans de main vertakking van de opslagplaats die u hebt gesplitst. Deze opslagplaats wordt de upstream-opslagplaats genoemd en heeft de alias upstream.

    In de volgende schermopname ziet u de bronopslagplaats en vertakking en de doelopslagplaats en vertakking van een pull-aanvraag die is gemaakt in Azure-opslagplaatsen.

    Schermopname van de opties voor de pull-bron- en doelvertakking in Azure-opslagplaatsen.

    Zie Een pull-aanvraag maken voor meer informatie over het maken van een pull-aanvraag met behulp van uw browser, Visual Studio of de Azure DevOps CLI.

    Belangrijk

    Iedereen met de machtiging Lezen in de upstream-opslagplaats kan er een pull-aanvraag voor openen. Als de upstream-opslagplaats een pull-build-pijplijn heeft die is geconfigureerd voor uitvoering bij het maken van pull-aanvraag, wordt een build uitgevoerd op de wijzigingen die door uw pull-aanvraag zijn geïntroduceerd.

  2. Om uw pull-aanvraag te voltooien, moeten alle vereiste revisoren de pull-aanvragen goedkeuren en moet aan alle beleidsregels voor de doelbranch worden voldaan. Bij goedkeuring en voltooiing van pull-aanvraag worden de wijzigingen in de pull-bronbranch samengevoegd in de doelbranch van de pull-aanvraag.

Zie Een pull-aanvraag maken en een pull-aanvraag samenvoegen voor meer informatie over het maken en voltooien van een GitHub-pull-aanvraag.

Uw fork synchroniseren

Nadat een pull-aanvraag de wijzigingen van uw fork heeft samengevoegd in de doelvertakking van de upstream-opslagplaats, kunt u de doelvertakking van de upstream-opslagplaats ophalen om uw bijbehorende lokale vertakking bij te werken met zowel uw wijzigingen als eventuele wijzigingen die door andere inzenders zijn aangebracht. Vervolgens kunt u het volgende doen:

  • Maak een nieuwe functie of foutoplossingsvertakking vanuit de bijgewerkte lokale vertakking.

  • Werk uw fork bij door te pushen van de bijgewerkte lokale vertakking naar origin.

Normaal gesproken is mainde doelvertakking van de upstream-opslagplaats. Als u uw lokale main vertakking niet rechtstreeks bewerkt (u werkt in functievertakkingen),wordt uw lokale main vertakking upstream/main bijgewerkt zonder samenvoegingsconflicten.

Volgende stappen

Code delen met pull-aanvragen voor pushbeoordeling