GitHub-bijdragewerkstroom voor belangrijke of langdurige wijzigingen

Belangrijk

Op alle opslagplaatsen die publiceren naar docs.microsoft.com is de Microsoft Open Source-gedragscode van toepassing. Zie Veelgestelde vragen over de gedragscode voor meer informatie. Of neem contact op met opencode@microsoft.com als u vragen of opmerkingen hebt.

Kleine correcties of verduidelijkingen voor de documentatie en codevoorbeelden in de openbare opslagplaatsen vallen onder de gebruiksvoorwaarden van docs.microsoft.com. Bij nieuwe inhoud of belangrijke wijzigingen wordt een opmerking gegenereerd in de pull-aanvraag, waarin u wordt gevraagd een online Contribution License Agreement (CLA) in te dienen als u geen werknemer van Microsoft bent. U moet het onlineformulier invullen voordat uw pull-aanvraag kan worden samengevoegd.

Overzicht

Deze werkstroom is geschikt voor inzenders die belangrijke wijzigingen moeten aanbrengen of die regelmatig bijdragen leveren aan een opslagplaats. Frequente inzenders hebben doorgaans doorlopende (langlopende) wijzigingen die meerdere build-/validatie-/faseringscycli doorlopen of over meerdere dagen worden uitgespreid voor accordering en samenvoeging van de pull-aanvraag.

Voor Microsoft-medewerkers die werken aan projecten waarvoor zowel openbare opslagplaatsen als privéopslagplaatsen worden gebruikt, is het tevens belangrijk dat dergelijke bijdragen worden geleverd aan de privéopslagplaats. Geïntegreerde build-/validatie-/faseringsdiensten voor OPS zijn beschikbaar in de privéopslagplaats.

Voorbeelden van dergelijke bijdragen zijn:

  • Een grote bijdrage leveren. U kunt bijvoorbeeld bijdragen (aanvullingen, wijzigingen of verwijderingen) leveren die meerdere artikelen beslaan en als één werkeenheid moeten worden doorgevoerd en getest in één pull-aanvraag.
  • Een nieuw artikel maken en publiceren, waarvoor meestal een robuustere lokale editor nodig is. Als u een Microsoft-werknemer bent, moet u bijvoorbeeld misschien de VS Code-extensies gebruiken die in Hulpprogramma’s voor Git/Markdown installeren worden besproken.
  • Nieuwe afbeeldingen toevoegen of afbeeldingen bijwerken, waarvoor meestal gelijktijdige creatie van een nieuwe media-submap, afbeeldingsbestanden, updates van afbeeldingskoppelingen in artikelen, en voorbeelden van Markdown-bestanden in een lokale editor nodig zijn om de weergave van afbeeldingen te testen.
  • Een artikel gedurende enkele dagen bijwerken voordat u het publiceert. In deze gevallen moet u meestal regelmatig andere wijzigingen integreren die in de 'hoofdvertakking' worden aangebracht. Deze integratie gaat gemakkelijker via Git Bash en lokaal bewerken. U loopt ook het risico uw bewerkingen te verliezen als u dit via de GitHub-gebruikersinterface doet en moet wachten tot u de wijzigingen doorvoert.
  • Hetzelfde artikel voortdurend bijwerken nadat een pull-aanvraag is geopend (tenzij u dit probleemloos via de GitHub-gebruikersinterface kunt doen). Als u de GitHub-gebruikersinterface gebruikt, worden er misschien meerdere uitstaande pull-aanvragen voor hetzelfde bestand gemaakt, die met elkaar kunnen conflicteren.

Terminologie

Bekijk voordat u aan de slag gaat eerst enkele Git-/GitHub-termen en -monikers die in deze werkstroom worden gebruikt. U hoeft deze nu nog niet te begrijpen. U maakt eerst kennis met de termen en kunt dan deze sectie raadplegen als u een definitie wilt controleren.

Naam Beschrijving
fork Wordt doorgaans als zelfstandig naamwoord gebruikt bij verwijzing naar een kopie van een GitHub-hoofdopslagplaats. Een fork is in feite gewoon een opslagplaats. Het is echter een bijzondere opslagplaats in de zin dat GitHub een verbinding in stand houdt met de bovenliggende of hoofdopslagplaats. Soms wordt de term gebruikt als werkwoord. In het Nederlands wordt hiervoor het werkwoord splitsen gebruikt, bijvoorbeeld "U moet de opslagplaats eerst splitsen."
remote Een benoemde verbinding naar een externe opslagplaats, bijvoorbeeld de origin of upstream remote. In Git wordt hiernaar verwezen als remotes, omdat ze worden gebruikt om te verwijzen naar een opslagplaats die wordt gehost op een andere computer. In deze werkstroom is een remote altijd een GitHub-opslagplaats.
origin De naam die wordt gegeven aan de verbinding tussen de lokale opslagplaats en de opslagplaats waarvandaan deze is gekloond. In deze werkstroom staat origin voor de verbinding met uw fork. Deze wordt soms gebruikt als moniker voor de oorspronkelijke opslagplaats, bijvoorbeeld in "Vergeet niet uw wijzigingen naar de origin te uploaden."
upstream Net als de origin remote is upstream een benoemde verbinding naar een andere opslagplaats. In deze werkstroom staat upstream voor de verbinding tussen uw lokale opslagplaats en de hoofdopslagplaats, waarvan de fork is gemaakt. Deze wordt soms als moniker gebruikt voor de upstream-opslagplaats, bijvoorbeeld in "Vergeet niet de wijzigingen van de upstream te downloaden."

Werkstroom

Belangrijk

Voer de stappen uit in de sectie Instellen, indien u dit nog niet hebt gedaan. In deze sectie doorloopt u het instellen van uw GitHub-account, het installeren van Git Bash en een Markdown editor, het maken van een fork en het instellen van een lokale opslagplaats. Als u niet bekend bent met Git- en GitHub-concepten als een opslagplaats of vertakking, leest u eerst Basisinformatie over Git en GitHub.

In deze werkstroom stromen wijzigingen via een doorlopende cyclus. Vanuit de lokale opslagplaats op uw apparaat stromen de wijzigingen terug naar uw GitHub fork, naar de GitHub-hoofdopslagplaats en weer terug naar uw lokale opslagplaats terwijl u wijzigingen van andere inzenders opneemt.

1. Een werkvertakking maken

In Basisinformatie over Git en GitHub hebt u gelezen dat een Git-opslagplaats een master-vertakking bevat en eventueel vertakkingen met werkversies die nog niet in de master zijn geïntegreerd. Wanneer u een reeks logisch met elkaar verband houdende wijzigingen introduceert, wordt aanbevolen een werkvertakking te maken waarmee u uw wijzigingen in de gehele werkstroom kunt beheren. In deze uitleg wordt hiernaar verwezen als een werkvertakking, omdat het een werkruimte is waarin wijzigingen worden herhaald/verfijnd totdat deze in de master-vertakking kunnen worden geïntegreerd.

Als u gerelateerde wijzigingen isoleert in een specifieke vertakking, kunt u deze wijzigingen onafhankelijk beheren en introduceren, waarbij u zich kunt richten op een specifieke uitgavetijd in de publicatiecyclus. Afhankelijk van uw werkzaamheden, kunt u daardoor meerdere werkvertakkingen in uw opslagplaats hebben. Het is niet ongebruikelijk dat mensen tegelijkertijd in meerdere vertakkingen werken, die elk bij een ander project horen.

Tip

Het wordt niet aanbevolen de wijzigingen rechtstreeks in de mastervertakking door te voeren. Stelt u zich eens voor dat u de mastervertakking gebruikt om enkele wijzigingen door te voeren voor het uitbrengen van een getimede functie. U hebt de wijzigingen voltooid en wacht op het moment waarop u deze kunt uitbrengen. Ondertussen ontvangt u een urgente aanvraag om een fout op te lossen. U voert de wijziging door in een bestand in de mastervertakking en publiceert de wijziging. In dit voorbeeld hebt u per ongeluk niet alleen de fix gepubliceerd, maar ook de wijzigingen die u pas op een specifieke datum wilde vrijgeven.

Ga daarom als volgt te werk om in uw lokale opslagplaats een werkvertakking te maken waarin u uw wijzigingen kunt vastleggen:

  1. Start Git Bash.

  2. Ga met de opdracht cd <repo> (andere map) van Git Bash naar uw lokale opslagplaats. De nieuwe lokale opslagplaats is met de kloonopdracht gemaakt in een submap onder het pad c:\users\<user-account>\<repo>\.

    cd <repo>
    
  3. Hieronder vindt u meer informatie over enkele fundamentele concepten die van belang zijn voor het leren werken met Git:

    a. Werkmap: met de vorige opdracht cd is de Git Bash-context gewijzigd naar de map van de opslagplaats die is gemaakt met de kloonopdracht. Deze map wordt voor de volgende twee doelen gebruikt:

    • Het bieden van een werkmap waar u met de Markdown editor en andere programma’s toevoegingen, wijzigingen en verwijderingen kunt doorvoeren aan bestanden in de vertakking. De bestanden maken deel uit van de huidige vertakking.
    • Voor het opslaan van de lokale opslagplaats. In feite is dit een database waar Git gegevensstructuren voor opslagplaatsen beheert, inclusief de toestand van alle vertakkingen, de externe 'origin'- en 'upstream'-verbindingen en andere interne details. U gebruikt Git-opdrachten voor het overbrengen van uw bestanden naar/van de werkmap en de Git-opslagplaatsdatabase, in plaats van rechtstreeks in de opslagplaatsdatabase te werken.

    b. Huidige vertakking: De Git Bash-context is ook ingesteld op de vertakking in de lokale opslagplaats waar uw wijzigingen worden toegepast. Dit heet ook wel de huidige vertakking. Voor een nieuwe gekloonde opslagplaats verwijst Git Bash standaard naar de standaard-/mastervertakking, of naar de laatste vertakking waaraan u in een bestaande opslagplaats hebt gewerkt.

    Tip

    Werkmap is een besturingssysteemconcept, terwijl huidige vertakking een Git-concept is. U moet de huidige vertakking zien als een alias voor de vertakking waaraan u werkt, niet als een nieuwe of andere vertakking. Omdat u niet rechtstreeks kunt werken aan een vertakking in de lokale Git-opslagplaats (d.w.z: de database), biedt de werkmap een platform waar u bestanden in de huidige vertakking kunt bewerken, hieraan kunt toevoegen of hieruit kunt verwijderen voordat u ze weer opslaat in de lokale opslagplaats. Dit wordt duidelijker in de volgende sectie en naarmate u beter bekend raakt met het werken in Git.

    c. Git Bash-omgeving: Het wordt aangeraden om, voordat u wijzigingen aanbrengt in bestanden, altijd de context van uw huidige Git Bash-omgeving te controleren. Deze context bevat de opslagplaats en de vertakking waarop de Git-opdrachten worden uitgevoerd. Dit is met name belangrijk als u bent overgeschakeld naar een andere opslagplaats of vertakking (of mogelijk een andere computer) sinds u de opslagplaats hebt gemaakt of voor het laatst hebt gebruikt. In de volgende schermafbeelding van Git Bash ziet u dat de bovenste regel van de opdrachtprompt het volgende bevat:

    • Het gebruikersaccount dat u hebt gebruikt om u aan te melden bij de computer en de netwerknaam van de computer ( useracct@computer in het groen)
    • De locatie van de werkmap van de huidige opslagplaats (/c/Git/Azure-Docs in het geel, die verwijst naar c:\Git\Azure-Docs op een Windows-computer)
    • De huidige vertakking waaraan wordt gewerkt (master in het blauw)

      Informatie over de werkvertakking

    In de voorgaande schermafbeelding ziet u tevens hoe de opdracht git branch wordt gebruikt. Deze wordt gebruikt om alle beschikbare vertakkingen in de lokale opslagplaats weer te geven. Dit is nuttig als u de huidige vertakking wilt controleren (voorafgegaan door een sterretje) of als u een lijst van alle beschikbare vertakkingen wilt bekijken voordat u naar een nieuwe vertakking schakelt.

  4. Gebruik de opdracht checkout om de vertakking te selecteren die u wilt aanwijzen als huidige vertakking:

    git checkout master
    

    Met de opdracht checkout doet u het volgende:

    • U haalt de bestanden uit de mastervertakking uit de lokale opslagplaats
    • U kopieert de bestanden voor bewerking naar de werkmap.
    • U selecteert de mastervertakking als nieuwe huidige vertakking (dit kunt u controleren in de Git-opdrachtprompt)
  5. Maak een nieuwe werkvertakking in uw lokale opslagplaats.

    a. Als u niet met anderen samenwerkt aan een project, kunt u deze stap overslaan. Als u met anderen samenwerkt, moet u de werkvertakking waarschijnlijk plaatsen in een upstream uitgavevertakking. Voordat u een werkvertakking maakt, moet u in de lokale opslagplaats aangeven dat er in de upstream-opslagplaats nieuwe uitgavevertakkingen zijn. U doet dit met de volgende opdracht:

    git fetch upstream
    

    b. Als u een werkvertakking wilt maken, gebruikt u opnieuw de opdracht checkout. U gebruikt nu echter aanvullende argumenten. Voer de volgende opdracht uit. Vervang hierin <my-working-branch> door de naam die u wilt gebruiken voor de nieuwe vertakking. Vervang <parent-upstream-branch> door master als u onafhankelijk van anderen werkt, of de naam van een uitgavevertakking als u met anderen samenwerkt aan inhoud die wordt uitgegeven. Met de schakelaar -b wordt door Git eerst een lokale werkvertakking gemaakt op basis van de externe upstream/<parent-upstream-branch>-vertakking. Selecteer deze vervolgens als uw nieuwe huidige vertakking.

    git checkout -b <my-working-branch> upstream/<parent-upstream-branch>
    

    Notitie

    Als u een foutmelding krijgt bij de opdracht checkout in 5.b., zorg er dan voor dat u eerst de opdracht fetch upstream in 5.a. voltooit. Controleer ook dat u alle stappen in de sectie Instellen van deze gids hebt uitgevoerd, inclusief Uw lokale opslagplaats instellen. Hiermee zorgt u ervoor dat de upstream-verbinding naar de hoofdopslagplaats correct wordt ingesteld.

  6. Stel voor toekomstige synchronisatie een kopie in van de nieuwe vertakking in uw fork. Met de volgende opdracht git push stuurt/uploadt u een kopie van uw nieuwe <my-working-branch> naar uw fork/oorspronkelijke opslagplaats. Zorg ervoor dat u <my-working-branch> vervangt door de naam van de werkvertakking die u in stap 5 hebt opgegeven. Hier gebruikt u eenmalig in deze werkstroom de schakelaar -u. Hiermee slaat u aanvullende traceringsgegevens voor de remote vertakking op die door Git worden gebruikt:

    git push -u origin <my-working-branch>
    

Samenvatting

In deze sectie zijn bewerkingen behandeld die doorgaans slechts eenmalig, aan het begin van de werkstroom voor elk bijdrageproject worden uitgevoerd. Loop de stappen in deze sectie steeds opnieuw door wanneer u een nieuw project start.

Hieronder volgt een samenvatting van hetgeen tot nu toe is behandeld:

  • De Git Bash-omgeving en -context, belangrijke concepten met betrekking tot lokale opslagplaatsen, zoals de werkmap en huidige vertakking en hoe Git deze gebruikt om werk in uw lokale opslagplaats te beheren
  • U hebt gelezen hoe u een nieuwe vertakking selecteert in een werkmap en deze aanwijst als de huidige vertakking
  • U hebt een nieuwe vertakking in uw lokale opslagplaats gemaakt op basis van een vertakking van uw hoofd/upstream-opslagplaats en deze in de werkmap geselecteerd als de nieuwe huidige vertakking
  • U hebt een kopie van de nieuwe werkvertakking naar uw fork/oorspronkelijke opslagplaats geüpload, zodat deze kan worden gesynchroniseerd en kan worden gebruikt bij het maken van een downloadaanvraag

In de volgende sectie leert u over de terugkerende stappen in de werkstroom. U voert deze gewoonlijk meerdere keren uit tijdens het herhalen en verbeteren van uw bijdragen.

2. Wijzigingen aanbrengen aan uw huidige vertakking

Ook doorvoer is een belangrijk concept. Git traceert de wijzigingenset die u doorvoert in een werkeenheid die een doorvoer wordt genoemd. Een doorvoer is een reeks gerelateerde wijzigingen, aanvullingen en verwijderingen die op een bepaald tijdstip zijn toegepast op een of meer bestanden in de huidige vertakking. Met doorvoeren kan Git bewerkingen uitvoeren binnen vastgestelde grenzen en hebt u, indien gewenst, later een referentiepunt voor de wijzigingen.

  1. Omdat gedurende de levensduur van uw werkvertakking regelmatig en tegelijkertijd updates worden uitgevoerd door andere inzenders, wordt het aanbevolen eerst hun wijzigingen te integreren in uw vertakking. Hiermee voorkomt u conflicten tijdens het samenvoegen, die ontstaan wanneer wijzigingen van anderen niet kunnen worden afgestemd op uw vertakking, of ontdekt u deze tijdig, voordat ze complexer worden.

    Vervang in de volgende opdracht <parent-branch-name> door de naam in van de externe vertakking waarmee u uw werkvertakking hebt gemaakt in stap 5 van de voorgaande sectie (bijvoorbeeld master of release-0918). Let op: bij deze opdracht wordt ervan uitgegaan dat de gewenste vertakking nog steeds is geselecteerd als de huidige vertakking.

    git pull upstream <parent-branch-name>
    

    Met deze opdracht worden de recentste wijzigingen gedownload van de opgegeven upstream-vertakking en samengevoegd met de huidige vertakking. Als de wijzigingen door Git niet kunnen worden samengevoegd vanwege een samenvoegingsconflict, raadpleegt u Samenvoegingsconflicten in Git en GitHub oplossen voor meer informatie over hoe u het probleem kunt oplossen. Het wordt aanbevolen deze bewerking gedurende de dag regelmatig uit te voeren, om de kans op samenvoegingsconflicten proactief te verminderen of voorkomen.

  2. Breng uw bestandswijzigingen aan. Vanuit de werkmap van uw opslagplaats zult u doorgaans File Explorer en/of een Markdown editor gebruiken voor het maken, wijzigen of verwijderen van Markdown-bestanden. Zie Markdown gebruiken voor meer informatie over Markdown-syntaxis.

  3. Als u bestanden in uw werkmap maakt, wijzigt of verwijdert, gebeuren er twee dingen:

    • Het besturingssysteem houdt de wijzigingen in uw werkmap bij op de schijf, zoals dit altijd gebeurt wanneer u bestanden wijzigt.
    • GIT bewaakt de werkmap en controleert op wijzigingen. Zoals besproken wordt de werkmap, waar de huidige vertakking wordt gewijzigd, op wijzigingen gecontroleerd. Git legt hierbij uw activiteiten vast en wacht op het moment waarop u aangeeft dat het onderhanden werk moet worden doorgevoerd in de lokale opslagplaats.

    De wijzigingen in de werkmap worden dus bijgehouden in uw bestandssysteem. Ze worden echter niet doorgevoerd in de kopie van de werkvertakking in de lokale opslagplaats. Nadat de wijzigingen in uw werkmap zijn doorgevoerd, zijn de toestand van uw werkmap en die van de huidige vertakking zoals deze in de lokale opslagplaats bestaat, gelijk.

    Met de status-opdracht van Git kunt u de status van de door Git bijgehouden wijzigingen controleren in de werkmap:

    git status
    

    In het volgende voorbeeld ziet u dat de werkmap twee bijgehouden wijzigingen heeft in het rood (een aangepast en een verwijderd bestand) en een wijziging die niet is bijgehouden (een nieuw bestand). Geen van beide zijn doorgevoerd en opgeslagen op de huidige vertakking in de lokale opslagplaats.

    Werkvertakking

  4. Inmiddels zult u hebben gezien dat het proces van het doorvoeren van wijzigingen in de lokale opslagplaats meerdere stappen omvat. Nadat de wijzigingen in de werkmap (bestandssysteem) zijn opgeslagen, zijn er nog twee aanvullende stappen waarmee de volgende opdrachten worden gegeven aan Git:

    1. Ten eerste het toevoegen van bijgehouden en niet-bijgehouden wijzigingen in de werkmap aan de tijdelijke opslag (ook wel index) van Git. U kunt de tijdelijke opslag beschouwen als wachtruimte die wordt gebruikt om de wijzigingen te verzamelen die u in één keer met dezelfde doorvoeringsbewerking wilt indienen.
    2. Voer alles in de tijdelijke opslag door op de persistente kopie van de vertakking in de lokale opslagplaats.

    U voert hiervoor de volgende opdrachtparen uit. Zorg ervoor dat u een hoofdletter A gebruikt in de -A-schakelaar en vervang <comment> door een opmerking om een korte omschrijving van uw wijzigingen vast te leggen.

    git add -A
    git commit –m "<comment>"
    

    Nadat u de twee stappen van het doorvoerproces hebt voltooid, komt de status van de huidige vertakking in de lokale opslagplaats overeen met die van uw werkmap. Tijdens het aanbrengen van wijzigingen in, het toevoegen van bestanden aan en het verwijderen van bestanden uit uw werkmap, zult u de stappen voor toevoegen en doorvoeren waarschijnlijk herhaaldelijk uitvoeren.

    Zie het onderwerp Basisbeginselen voor Git - Recording Changes to the Repository (Wijzigingen vastleggen in de opslagplaats) in het Pro Git-e-book voor meer informatie over dit proces, inclusief details van het faserings-/doorvoerproces.

  5. Vervolgens gebruikt u de opdracht git push opnieuw (maar nu zonder de -u-schakelaar) voor het synchroniseren van de huidige vertakking van uw lokale opslagplaats met de vertakking met dezelfde naam die u hebt geüpload naar de GitHub-fork in de voorgaande sectie:

    git push origin <my-working-branch>
    

    Ook deze bewerking dient u regelmatig uit te voeren om ervoor te zorgen dat van uw wijzigingen een back-up wordt gemaakt in GitHub. Als u al een pull-aanvraag hebt geopend (meer informatie hierover vindt u in een volgende sectie), registreert de pull-aanvraag elke keer dat u uw vertakking uploadt dat er nieuwe doorvoeren zijn en worden geautomatiseerde build-/validatiestappen automatisch uitgevoerd, indien van toepassing.

Samenvatting

Als al uw Git Bash-opdrachten zonder fouten zijn voltooid, ziet u voor elke opdracht een reactie als in onderstaande schermafbeelding. U ziet dat met de opdracht commit de drie bestandswijzigingen zijn doorgevoerd in de lokale opslagplaats en met de opdracht push de huidige vertakking naar de fork is geüpload.

Bevestiging voor toevoegen, doorvoeren, uploaden

In deze sectie zijn stappen in de werkstroom behandeld die doorgaans terugkerend zijn en die u gedurende de levensduur van de werkvertakking meerdere malen zult uitvoeren. Tenslotte leest u hieronder meer over het laatste deel van de werkstroom, die u uitvoert wanneer uw bijdrage klaar is om als voorstel te worden ingediend bij de mastervertakking.

3. Open een pull-aanvraag

Als u er klaar voor bent uw inhoud te verzenden voor validatie en publicatie:

  1. Ga naar de GitHub-pagina van uw fork, bijvoorbeeld https://github.com/<GitHub-username>/Azure-Docs.

  2. Maak nu de pull-aanvraag. Met een pull-aanvraag dient u een voorstel in om de doorvoer in uw werkvertakking te uploaden naar de bovenliggende vertakking in de hoofdopslagplaats waarvandaan u de werkvertakking hebt gemaakt (in stap 5 van de sectie Een werkvertakking maken).

    Selecteer de werkvertakking die u naar uw fork hebt geüpload (in stap 5 van de sectie Wijzigingen aanbrengen aan uw huidige vertakking), met de knop Vertakking: links. Selecteer vervolgens de knop Nieuwe pull-aanvraag rechts om een nieuwe pull-aanvraag te starten:

    Knop Nieuwe pull-aanvraag

  3. Wanneer de pagina Een pull-aanvraag openen wordt weergegeven, controleert u of uw hoofdfork en uw werkvertakking rechts (van), en de docs.microsoft.com basisopslag en bovenliggende vertakking links (naar) worden weergegeven:

    Pull-aanvraag

    De titel van de pull-aanvraag wordt standaard ontleend aan de opmerking die u in uw doorvoer hebt gebruikt. Toch dient u ervoor te zorgen dat deze een duidelijke omschrijving vormt. U kunt hier ook een snelle controle uitvoeren om te zien of het aantal bestanden dat u hebt gewijzigd overeenkomt met het aantal dat onder aan de pagina wordt weergegeven. Als u naar beneden schuift, kunt u tevens de exacte verschillen tussen de vertakkingen controleren. Zo kunt u verifiëren dat de pull-aanvraag de wijzigingen/doorvoer bevat die u verwacht. Als de pull-aanvraag overeenkomt met uw wijzigingen, klikt u op de knop Pull-aanvraag maken onder aan de pagina.

Verwerking van pull-aanvragen

In de vorige sectie werd uitgelegd hoe u voorgestelde wijzigingen kunt indienen door deze in een nieuwe pull-aanvraag te bundelen die wordt toegevoegd aan de wachtrij voor pull-aanvragen in de doelopslagplaats. Met een pull-aanvraag wordt het samenwerkingsmodel van GitHub ingeschakeld door de wijzigingen uit uw werkvertakking te 'trekken' (pull) en samen te voegen met een andere vertakking. Die andere vertakking is meestal de standaard 'hoofdvertakking' in de hoofdopslagplaats.

Validatie

Voordat uw pull-aanvraag kan worden samengevoegd met de doelvertakking, moeten er misschien één of meer pull-aanvraagvalidaties worden uitgevoerd. Validaties kunnen verschillend zijn, afhankelijk van de omvang van voorgestelde wijzigingen en de regels van de doelopslagplaats. Nadat uw pull-aanvraag is ingediend, kunnen er één of meer van de volgende dingen gebeuren:

  • Samenvoegbaarheid: Er wordt eerst een GitHub-basistest voor samenvoegbaarheid uitgevoerd om te controleren of de voorgestelde wijzigingen in uw vertakking conflicteren met de doelvertakking. Als de pull-aanvraag aangeeft dat dit inderdaad het geval is, moet u de inhoud die het samenvoegingsconflict veroorzaakt, afstemmen voordat de verwerking kan worden hervat.
  • CLA: Als u bijdraagt aan een openbare opslagplaats en geen Microsoft-werknemer bent, wordt u afhankelijk van de omvang van de voorgestelde wijzigingen misschien gevraagd een korte CLA (Contribution License Agreement) in te vullen wanneer u voor het eerst een pull-aanvraag bij deze opslagplaats indient. Nadat de CLA-stap is goedgekeurd, wordt uw pull-aanvraag verwerkt.
  • Labeling: Er worden automatisch labels op uw pull-aanvraag toegepast om de status van uw pull-aanvraag aan te geven terwijl deze de validatiewerkstroom doorloopt. Nieuwe pull-aanvragen kunnen bijvoorbeeld automatisch het label 'niet-samenvoegen' krijgen, wat aangeeft dat de pull-aanvraag de stappen voor validatie, controle en goedkeuring nog niet heeft doorlopen.
  • Validatie en build: Uw wijzigingen worden door geautomatiseerde controles onderzocht om te controleren of ze de validatietests doorstaan. De validatietests kunnen waarschuwingen of fouten opleveren, waardoor u één of meer bestanden in uw pull-aanvraag moet wijzigen voordat deze kan worden samengevoegd. De resultaten van de validatietests worden als een opmerking in uw pull-aanvraag toegevoegd, zodat u deze kunt controleren, en kunnen ook per e-mail naar u worden gestuurd.
  • Fasering: De artikelpagina’s die worden beïnvloed door uw wijzigingen, kunnen automatisch in een faseringsomgeving worden geïmplementeerd voor controle na een succesvolle validatie en build. Voorbeeld-URL’s worden in een pull-aanvraagopmerking weergegeven.
  • Automatische samenvoeging: De pull-aanvraag kan automatisch worden samengevoegd als deze de validatietests doorstaat en aan bepaalde criteria voldoet. In dat geval hoeft u verder niets meer te doen.

Controle en goedkeuring

Nadat de pull-aanvraagverwerking is voltooid, moet u de resultaten (pull-aanvraagopmerkingen, voorbeeld-URL’s enz.) controleren om te bepalen of de bestanden ervan nog verder moeten worden gewijzigd voordat u de pull-aanvraag goedkeurt voor samenvoeging. Als een revisor voor pull-aanvragen uw pull-aanvraag heeft gecontroleerd, geeft deze misschien ook feedback via opmerkingen als er uitstaande problemen/vragen zijn die moeten worden opgelost voordat de pull-aanvraag wordt samengevoegd.

Door middel van automatisering van opmerkingen kunnen gebruikers op leesniveau (gebruikers die geen schrijfmachtigingen in een opslagplaats hebben) een actie op schrijfniveau uitvoeren door het desbetreffende label aan een pull-aanvraag (PR) toe te wijzen. Als u in een opslagplaats werkt waar automatisering van opmerkingen is geïmplementeerd, gebruikt u de hashtag-opmerkingen in de volgende tabel om labels toe te wijzen of te wijzigen, of een pull-aanvraag te sluiten. Microsoft-medewerkers krijgen ook via e-mail een melding over het controleren en goedkeuren van openbare opslagplaats-PR's als er wijzigingen worden voorgesteld voor artikelen waarvan u de auteur bent.

Hashtag-opmerking Gevolg Beschikbaarheid in opslagplaats
#sign-off Als de auteur van een artikel de opmerking #sign-off in de opmerkingenstream typt, wordt het label ready-to-merge toegewezen. Met dit label weten de revisoren in de opslagplaats wanneer een pull-aanvraag klaar is om te worden gecontroleerd of samengevoegd. Openbare en persoonlijk
#sign-off Als een bijdrager die niet als auteur vermeld staat, zich bij een openbare pull-aanvraag wil afmelden met de opmerking #sign-off, wordt er een bericht voor de pull-aanvraag geschreven waarin staat aangegeven dat alleen de auteur het label kan toewijzen. Openbaar
#hold-off Een auteur kan #hold-off in een PR-opmerking typen om het label ready-to-merge te verwijderen voor het geval zij of hij van gedachten verandert of een fout heeft gemaakt. In de persoonlijke opslagplaats wordt hierdoor het label do-not-merge toegewezen. Openbare en persoonlijk
#please-close Een auteur kan #please-close in de opmerkingenstream typen om de pull-aanvraag te sluiten als zij of hij besluit de wijzigingen niet te willen samenvoegen. Openbaar

Als de pull-aanvraag probleemvrij en goedgekeurd is, worden uw wijzigingen weer samengevoegd met de bovenliggende vertakking en wordt de pull-aanvraag gesloten.

Publicatie

Vergeet niet dat uw pull-aanvraag moet worden samengevoegd door een revisor voor pull-aanvragen voordat de wijzigingen kunnen worden opgenomen in de volgende geplande publicatie. Pull-aanvragen worden gewoonlijk gecontroleerd/samengevoegd in de volgorde waarin deze zijn ingediend. Als uw pull-aanvraag moet worden samengevoegd voor een bepaalde publicatie, moet u van tevoren met uw revisor voor pull-aanvragen overleggen en samenwerken om ervoor te zorgen dat de samenvoeging vóór de publicatie plaatsvindt.

Nadat uw bijdragen zijn goedgekeurd en samengevoegd, worden ze opgepikt door het Docs.Microsoft.Com-publicatieproces. Publicatiemomenten kunnen variëren, afhankelijk van het team dat de opslagplaats beheert waaraan u bijdraagt. Artikelen die onder de volgende paden worden gepubliceerd, worden gewoonlijk maandag t/m vrijdag om ongeveer 10:30 uur en 15:30 uur Pacific Time geïmplementeerd:

Het kan tot 45 minuten duren voordat artikelen online verschijnen nadat ze zijn gepubliceerd. Nadat uw artikel is gepubliceerd, kunt u uw wijzigingen controleren via de desbetreffende URL: http://docs.microsoft.com/<path-to-your-article-without-the-md-extension>.

Volgende stappen

Dat is alles. U hebt een bijdrage geleverd aan inhoud voor docs.microsoft.com.

  • Raadpleeg Aanbevolen procedures voor pull-aanvragen voor meer informatie over de procedure voor pull-aanvragen.

  • Ga verder naar de sectie 'Belangrijke aspecten van het schrijven' voor meer informatie over onderwerpen als Markdown en de syntaxis van Markdown-extensies.