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 \u00e8 probabilmente GitHub.<\/p>\n
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?<\/p>\n
Forse il tuo flusso di lavoro \u00e8 qualcosa del genere:<\/p>\n
Ma cosa metti nel modello per la richiesta pull? Ogni volta \u00e8 lo stesso o \u00e8 diverso? Che dire se il contenuto della PR \u00e8 correlato a qualcosa in Trello<\/a>, Asana<\/a>, Basecamp<\/a> o qualche altro sistema di gestione dei progetti?<\/p>\n \u00c8 qui che entrano in gioco i modelli GitHub PR.<\/p>\n Puoi leggere tutto su di loro sulla pagina, ma ecco il succo (nessun gioco di parole):<\/p>\n \u00c8 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<\/p>\n<\/blockquote>\n E l’idea \u00e8 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.<\/p>\n Questo ci aiuta, poich\u00e9 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.<\/p>\n Ad esempio, supponiamo che tu stia lavorando a un progetto e desideri includere le seguenti informazioni:<\/p>\n Non sto dicendo che questa sia l’informazione richiesta, ma \u00e8 qualcosa che abbiamo usato e che ho trovato utile (ed \u00e8 bello vedere pi\u00f9 miglioramenti apportati nel tempo<\/a> ).<\/p>\n Il sito \u00e8 abbastanza chiaro, ma \u00e8 davvero semplice. Hai bisogno dei seguenti file nella directory del tuo progetto o nel tuo progetto. directory github<\/strong> :<\/p>\n Ognuno di questi dovrebbe essere file di markdown che evidenziano esattamente ci\u00f2 che stai cercando per i tuoi contributori da includere ogni volta che, sai, contribuiscono in qualche modo al tuo progetto.<\/p>\n E poi, ogni volta che un utente cerca di segnalare un problema o creare una richiesta pull, ha richiesto con le informazioni dal modello.<\/p>\n Bello, vero?<\/p>\n Potresti non pensare che sia molto, ma \u00e8 abbastanza facile aiutare a migliorare la qualit\u00e0 delle informazioni che entrano in un progetto, chiedere ai tuoi contributori di pensare a cosa stanno mettendo nel progetto e quindi rispondere di conseguenza.<\/p>\n 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.<\/p>\nModelli GitHub PR<\/h2>\n
\n
\n
Ma come lo usiamo?<\/h3>\n
\n
Non \u00e8 molto, ma…<\/h2>\n