5 idéer för ett förbättrat GitHub-arbetsflöde
Beroende på din historik med fungerande källkontroll varierar sättet på vilket du arbetar med en kodbas, gör commits, etc..
Vidare, beroende på om du använder Git, Subversion, Mercurial och så vidare dikterar också hur du hanterar din kod.
Men om du är någon som arbetar med Git (som jag vet att många människor i WordPress börjar använda mer och mer nästan dagligen), finns det några små saker som jag rekommenderar att du gör för att hjälpa till att hantera förändringar, särskilt med ett team mer hanterbar.
Tips för ett förbättrat GitHub-arbetsflöde
1 Förbind dig inte att bemästra
Master ska användas specifikt för produktionsklar och driftklar kod. Det är inte du som arbetar gren, det är inte din arbetsgren.
Generellt sett är det här alla pull-förfrågningar slås samman.
2 Försök att alltid skapa grenar
Närhelst du har en samling uppgifter, problem eller milstolpar, skapa en filial och se till att det du arbetar med är relaterat. Du vill till exempel inte göra databasarbete och JavaScript-arbete i dina pull-förfrågningar.
3 Batch ditt arbete
Även om du enbart arbetar med front-end-arbete, kan du behöva dela upp det i mindre grenar. Det ger enklare kodgranskning och bättre pull-förfrågningar.
4 Generera små PR
Detta är mycket likt den tidigare rubriken, men idén att skapa små PR är mycket mer produktiv än att skapa längre pull-förfrågningar.
- Det här hjälper dig när du behöver begära en kodgranskning eftersom det ger dina lagkamrater ett enklare sätt att hantera kodgranskning och ge feedback.
- Det håller ändringsloggen mager och hjälper till att ge en detaljerad rapport om vad den specifika kodsatsen gör.
Men vad är en bra PR?
5 Ge bra detaljer i din PR
Såvitt jag är orolig, kommer en bra pull-begäran att göra en liten uppsättning saker:
- Beskriv med bara en mening eller två vad personen som granskar dina ändringar bör förvänta sig ska hända.
- Länka PR till biljetten, projektledningskortet (eller vad de nu kallar det i ditt system),
- Lista kortare versioner av commit-meddelandena för att göra det enkelt som möjligt för din peer reviewer.
Som sagt, det finns sannolikt fler saker du kan göra, men det här är de saker jag har funnit mest användbara (och jag skulle inte kunna säga att jag inte lärde mig några av dessa saker från mitt team ).
Finns det fler saker?
Alltid.
Men det här är en handfull saker som jag har funnit vara mer och mer användbara, särskilt när jag spårar förändringar, arbetar med andra och hanterar pull-förfrågningar (både från de som jag arbetar med och de som bidrar till projekt med öppen källkod).
Slutligen är ingen av dessa saker föreskrivande. Det finns en inlärningskurva (talar av erfarenhet), men jag rekommenderar att du testar några av dessa om det inte är av någon annan anledning än för att se om det inte förbättrar ditt arbetsflöde.
Även om det bara är lite.