Hämta begäranden

Förutsättningar

Om du inte har bidragit till ett Microsoft-projekt tidigare kan du bli ombedd att signera ett licensavtal för bidrag. Om du gör det får du en kommentar i pr-frågan.

Viktigt

Om du är anställd på Microsoft och inte är medlem i Microsoft-organisationenpå GitHub länkar du dina Microsoft- och GitHub-konton på corpnet genom att gå till Öppen källkod på Microsoft innan du startar pull-begäran. Det finns vissa processsaker som du behöver göra i förväg.

Skapa en pull-begäran

När du är redo att skicka en pull-begäran skapar du en pull-begäran som riktar sig till main-grenen. Leta efter den senaste grenen för felkorrigeringar under en prerelease/* lanseringsstabiliseringsperiod. Nya funktioner bör alltid gå till main .

Läs riktlinjerna och kontrollera att pull-begäran uppfyller riktlinjerna.

  • Se till att referera till eventuella problem/funktionsförfrågningar eller uppgifter som PR relaterar till.
  • Kontrollera att pull-begäran endast innehåller filer/ändringar som rör pull-begäran.
  • Kontrollera att dokumentationen är uppdaterad och inkluderad. Kontrollera att alla offentliga fält har kommentarer.
  • Om du lägger till en ny funktion kontrollerar du att tester ingår för att verifiera funktionen (se UnitTests).
  • Om du åtgärdar en bugg skriver du ett test för att verifiera felkorrigeringen.

De som underhåller projektet granskar ändringarna. Vi vill granska alla ändringar inom tre arbetsdagar. Gå igenom eventuella granskningskommentarer, skicka till ämnesgrenen och skicka en kommentar så att vi vet att det finns nya saker att granska.

Anteckning

Alla PR som skickas till projektet kommer också att granskas enligt KODningsguiden för MRTK,så granska dessa innan du skickar in din pr för att säkerställa en smidig process.

Riktlinjer för pull-begäran

Dessa riktlinjer baseras på Googles tekniska metoder.

Håll pull-begäranden små

Mindre PR granskas snabbare och mer noggrant, är mindre sannolika att introducera buggar, enklare att återställa och enklare att sammanfoga.

Pull-begäranden bör vara så små att en tekniker kan granska den inom 30 minuter. Försök att göra en minimal ändring som bara åtgärdar en sak. Om du måste skapa en stor PR kan du dela upp den i flera PR:er som går till din lokala gren eller en funktionsgren av MRTK. Undvik att lägga till nya tillgångar (t.ex. fbx- eller obj-filer) och fokusera i stället på att använda befintliga tillgångar på nytt.

Tester ska läggas till i samma PR som din korrigering/funktion, förutom för problem

Tester är det bästa sättet att se till att ändringar inte regregreerar befintlig kod, men det är också lätt att glömma tester när du skickar pull-begäranden. Att kräva att de använder din PR är ett bra sätt att se till att testerna skrivs.

Alla funktioner och felkorrigeringar bör ha associerade tester. Om du inte har den expertis eller tid det tar att skriva ett test skapar du ett problem för att skriva testerna och markerar dem med etiketten Consider for Current Iteration (Överväg aktuell iteration).

Dokumentation ska läggas till i samma pull-begäran som en korrigering/funktion

De flesta utvecklare tittar först på dokumentation, inte kod, när de förstår hur man använder en funktion. Genom att se till att dokumentationen är uppdaterad blir det mycket enklare för personer att använda och förlita sig på MRTK. Dokumentationen bör alltid paketeras med relaterad pull-information för att säkerställa att objekten är uppdaterade och konsekventa.

Se till att varje offentligt fält, metod, egenskap har tredubbel sammanfattning av snedstreckskommentarer så att vår docfx-webbplats kan generera beskrivningar för fält/metoder. Uppdatera markdown-filerna i dokumentationsmappen om det behövs.

Beskrivningar av pull-begäran bör tydligt och fullständigt beskriva ändringar

Tydliga och fullständiga beskrivningar av pull-begäranden säkerställer att granskarna förstår vad de granskar.

Om du lägger till funktioner som innehåller UX lägger du till en bild/gif av den funktion som du ändrar. Här är ett bra exempel. Ett annat förslag är att ha en gif med Före och Efter, till exempel i den här pull-begäran. Ett verktyg som vi rekommenderar för att generera GIF-filer från skärmdumpar är ScreenToGif.