✅ WEB- och WordPress -nyheter, teman, plugins. Här delar vi tips och bästa webbplatslösningar.

Hur man använder GitHub PR-mallar

14

Om du gör något arbete – oavsett om det är öppen källkod eller sluten källkod – (även om jag vet att de flesta som använder den här webbplatsen är inblandade i öppen källkod), använder du sannolikt viss källkodskontroll, och det är förmodligen GitHub.

För många av er följer ni antingen ett projekt, bidrar till ett projekt eller hanterar pull-förfrågningar till ett projekt. Och hur är det med de projekt som du arbetar med i ett team?

Kanske är ditt arbetsflöde ungefär så här:

  • du skapar en gren för att arbeta med en funktion,
  • du trycker på grenen för att detaljera det arbete du har gjort för en kamrat att granska,
  • recensionen slås samman,
  • Fortsätt du.

Men vad lägger du i mallen för pull-förfrågan? Är det samma varje gång eller är det olika? Vad sägs om om innehållet i PR är relaterat till något i Trello, Asana, Basecamp eller något annat projektledningssystem?

Det är där GitHub PR-mallar kommer in i bilden.

GitHub PR-mallar

Du kan läsa allt om dem på sidan, men här är kärnan (ingen ordlek):

Det är svårt att lösa ett problem när viktiga detaljer saknas. Nu kan projektunderhållare lägga till mallar för problem och Pull-förfrågningar till projekt, vilket hjälper bidragsgivare att dela rätt information i början av en tråd

Och idén är enkel: Vi skapar mallar för ärenden och pull-förfrågningar för andra som ger en nivå av information som de måste fylla i innan de skickar in ett ärende eller en pull-förfrågan.

Detta hjälper oss, eftersom underhållare vet vilken information det än är som vi behöver innan vi tittar på det. Vidare kan det tillåta oss att länka till ett tidigare nummer, tidigare biljett, före allt som har med projektet att göra.

Låt oss säga att du arbetar med ett projekt och vill inkludera följande information:

  • en kort beskrivning av vad PR gör så att underhållaren inte behöver gissa,
  • statusen för PR om den ska vara redo att slås samman eller om den fortfarande är under utveckling men redo för granskning,
  • en länk till biljetten i din projektledare som PR är relevant för.

Jag säger inte att det här är den information som krävs, men det är något vi har använt, och jag har funnit användbart (och det är trevligt att se att fler förbättringar görs med tiden ).

Men hur använder vi detta?

Webbplatsen är ganska tydlig, men den är väldigt enkel. Du behöver följande filer i din projektkatalog eller i ditt projekts. github katalog:

  • ISSUE_MALL
  • PULL_REQUEST_MALL

Var och en av dessa bör vara markdown-filer som beskriver exakt vad det är som du letar efter att dina bidragsgivare ska inkludera när de, du vet, bidrar till ditt projekt på något sätt.

Och sedan, närhelst en användare vill rapportera ett problem eller skapa en pull-begäran, har de frågat om informationen från mallen.

Trevligt, inte sant?

Det är inte mycket, men…

Du kanske inte tycker att det är mycket, men det är ganska enkelt att hjälpa till att förbättra kvaliteten på informationen som kommer in i ett projekt, få dina bidragsgivare att tänka på vad de lägger in i projektet och sedan svara därefter.

Dessutom hjälper det dig och resten av ditt team att förstå vad det är som ska granskas och att förbereda sig för eventuella förändringar som kan komma i deras väg när de arbetar med dessa projekt.

Inspelningskälla: tommcfarlin.com

Denna webbplats använder cookies för att förbättra din upplevelse. Vi antar att du är ok med detta, men du kan välja bort det om du vill. Jag accepterar Fler detaljer