Pull-aanvragen

Vereisten

Als u nog niet eerder hebt bijgedragen aan een Microsoft-project, wordt u mogelijk gevraagd om een licentieovereenkomst voor bijdrage te ondertekenen. Een opmerking in de pr laat u weten als u dat doet.

Belangrijk

Als u een Microsoft-medewerker bent en geen lid bent van de Microsoft-organisatie op GitHub,koppelt u uw Microsoft- en GitHub-accounts op corpnet door naar Open Source bij Microsoft te gaan voordat u uw pull-aanvraag start. Er zijn enkele process die u van tevoren moet doen.

Een pull-aanvraag maken

Wanneer u klaar bent om een pull-aanvraag in te dienen, maakt u een pull-aanvraag die is gericht op de hoofdvertakking. Zoek naar de meest recente vertakking voor oplossingen voor fouten tijdens een prerelease/* releasestabilisatieperiode. Nieuwe functies moeten altijd naar main gaan.

Lees de richtlijnen en zorg ervoor dat uw pull-aanvraag voldoet aan de richtlijnen.

  • Zorg ervoor dat u verwijst naar een probleem/functieaanvraag of taak waar de pr betrekking op heeft.
  • Controleer of de pull-aanvraag alleen bestanden/wijzigingen bevat die betrekking hebben op de pull-aanvraag.
  • Controleer of de documentatie up-to-date is en is opgenomen. Controleer of alle openbare velden opmerkingen hebben.
  • Als u een nieuwe functie toevoegt, controleert u of er tests zijn opgenomen om de functie te valideren (zie UnitTests).
  • Als u een fout wilt oplossen, schrijft u een test om te controleren of de fout is opgelost.

De projectontwikkelaars controleren uw wijzigingen. We streven ernaar om alle wijzigingen binnen drie werkdagen te controleren. Los eventuele opmerkingen over de beoordeling op, push naar uw onderwerpvertakking en plaats een opmerking om ons te laten weten dat er nieuwe dingen moeten worden beoordeeld.

Notitie

Alle pr's die naar het project worden verzonden, worden ook beoordeeld volgens de handleiding voor MRTK-coderingsstandaarden, dus controleer deze voordat u uw pr indient om een soepel proces te garanderen.

Richtlijnen voor pull-aanvragen

Deze richtlijnen zijn gebaseerd op de technische procedures van Google.

Houd pull-aanvragen klein

Kleinere PR's worden sneller en grondig gecontroleerd, introduceren minder fouten, zijn gemakkelijker terug te draaien en gemakkelijker samen te voegen.

Pull-aanvragen moeten zo klein zijn dat een technicus deze in minder dan 30 minuten kan beoordelen. Probeer een minimale wijziging aan te brengen die slechts één ding behandelt. Als u een grote pr moet maken, splitst u deze in verschillende pr's die naar uw lokale vertakking gaan, of een functievertakking van MRTK. Vermijd het toevoegen van nieuwe assets (bijvoorbeeld fbx- of obj-bestanden) en richt u in plaats daarvan op het opnieuw gebruiken van bestaande assets.

Tests moeten worden toegevoegd in dezelfde pr als uw fix/functie, met uitzondering van fouten

Tests zijn de beste manier om ervoor te zorgen dat wijzigingen geen bestaande code terugsturen, maar het is ook eenvoudig om tests te vergeten bij het verzenden van pull-aanvragen. Vereisen dat ze uw pr gebruiken, is een uitstekende manier om ervoor te zorgen dat tests worden geschreven.

Aan elke functie en bugfix moeten tests zijn gekoppeld. Als u niet de expertise of tijd hebt om een test te schrijven, maakt u een probleem om de tests te schrijven en markeer u deze met het label Overweeg voor huidige iteratie.

Documentatie moet worden toegevoegd in dezelfde pull-aanvraag als een oplossing /functie

De meeste ontwikkelaars kijken eerst naar documentatie, niet naar code, wanneer ze weten hoe ze een functie moeten gebruiken. Door ervoor te zorgen dat de documentatie up-to-date is, is het veel eenvoudiger voor mensen om MRTK te gebruiken en te vertrouwen. Documentatie moet altijd worden gebundeld met de gerelateerde pull om ervoor te zorgen dat items up-to-date en consistent blijven.

Zorg ervoor dat elk openbaar veld, elke methode, de eigenschap drie slash-opmerkingen heeft, zodat onze docfx-site beschrijvingen voor velden/methoden kan genereren. Werk zo nodig markdown-bestanden bij in de map Documentatie.

Beschrijvingen van pull-aanvragen moeten wijzigingen duidelijk en volledig beschrijven

Duidelijke en volledige beschrijvingen van pull-aanvragen zorgen ervoor dat revisoren begrijpen wat ze beoordelen.

Als u functies toevoegt die UX bevatten, voegt u een afbeelding/GIF toe van de functie die u wilt wijzigen. Hier is een goed voorbeeld. Een andere suggestie is om een GIF van vóór en na te hebben, bijvoorbeeld in deze pull-aanvraag. Een hulpprogramma dat wordt aanbevolen voor het genereren van GIF's van schermopnamen is ScreenToGif.