Come utilizzare i modelli PR di GitHub

Se svolgi un lavoro, indipendentemente dal fatto che sia open source o closed source, (anche se so che la maggior parte di coloro che usano leggere questo sito sono coinvolti nell’open source), probabilmente usi un controllo del codice sorgente, ed è probabilmente GitHub.

Per molti di voi, segui un progetto, contribuisci a un progetto o gestisci richieste pull a un progetto. E che dire di quei progetti su cui lavori con un team?

Forse il tuo flusso di lavoro è qualcosa del genere:

• crei un ramo per lavorare su una funzione,
• spingi la filiale a dettagliare il lavoro che hai svolto per la revisione di un peer,
• la recensione è unita,
• vai avanti.

Ma cosa metti nel modello per la richiesta pull? Ogni volta è lo stesso o è diverso? Che dire se il contenuto della PR è correlato a qualcosa in Trello, Asana, Basecamp o qualche altro sistema di gestione dei progetti?

È qui che entrano in gioco i modelli GitHub PR.

Modelli GitHub PR

Puoi leggere tutto su di loro sulla pagina, ma ecco il succo (nessun gioco di parole):

È difficile risolvere un problema quando mancano dettagli importanti. Ora i manutentori del progetto possono aggiungere modelli per problemi e richieste pull ai progetti, aiutando i contributori a condividere i dettagli giusti all’inizio di un thread

E l’idea è semplice: creiamo modelli per problemi e richieste pull per altri che forniscono un livello di informazioni che devono compilare prima di inviare un problema o una richiesta pull.

Questo ci aiuta, poiché i manutentori sanno tutte le informazioni di cui abbiamo bisogno prima di esaminarle. Inoltre, potrebbe consentirci di collegarci a un’emissione precedente, un biglietto precedente, precedente a qualsiasi cosa relativa al progetto.

Ad esempio, supponiamo che tu stia lavorando a un progetto e desideri includere le seguenti informazioni:

• una breve descrizione di ciò che fa il PR in modo che il manutentore non debba indovinare,
• lo stato del PR su se dovrebbe essere pronto per essere unito o se è ancora in fase di sviluppo ma pronto per una revisione,
• un link al ticket nel tuo project manager per il quale il PR è rilevante.

Non sto dicendo che questa sia l’informazione richiesta, ma è qualcosa che abbiamo usato e che ho trovato utile (ed è bello vedere più miglioramenti apportati nel tempo ).

Ma come lo usiamo?

Il sito è abbastanza chiaro, ma è davvero semplice. Hai bisogno dei seguenti file nella directory del tuo progetto o nel tuo progetto. directory github :

• ISSUE_TEMPLATE
• PULL_REQUEST_TEMPLATE

Ognuno di questi dovrebbe essere file di markdown che evidenziano esattamente ciò che stai cercando per i tuoi contributori da includere ogni volta che, sai, contribuiscono in qualche modo al tuo progetto.

E poi, ogni volta che un utente cerca di segnalare un problema o creare una richiesta pull, ha richiesto con le informazioni dal modello.

Bello, vero?

Non è molto, ma…

Potresti non pensare che sia molto, ma è abbastanza facile aiutare a migliorare la qualità delle informazioni che entrano in un progetto, chiedere ai tuoi contributori di pensare a cosa stanno mettendo nel progetto e quindi rispondere di conseguenza.

Inoltre, aiuta te e il resto del tuo team a capire cosa sta per essere rivisto e a prepararsi per eventuali cambiamenti che potrebbero verificarsi quando si lavora su questi progetti.