A seconda della tua cronologia con il controllo del codice sorgente funzionante, il modo in cui lavori con una base di codice, effettuando commit e cos\u00ec via, varia.<\/p>\n
Inoltre, a seconda se stai usando Git<\/a>, Subversion<\/a>, Mercurial<\/a> e cos\u00ec via, detta anche come gestisci il tuo codice.<\/p>\n Ma se sei qualcuno che sta lavorando con Git (che so che molte persone in WordPress stanno iniziando a usare sempre di pi\u00f9 quasi quotidianamente), ci sono alcune piccole cose che consiglio di fare per aiutare a gestire le modifiche specialmente con un team pi\u00f9 gestibile.<\/p>\n Il master deve essere utilizzato specificamente per il codice pronto per la produzione e per la distribuzione. Non \u00e8 il tuo ramo di lavoro, non \u00e8 il tuo ramo di lavoro.<\/p>\n In generale, \u00e8 qui che vengono unite tutte le richieste pull.<\/p>\n Ogni volta che hai una raccolta di attivit\u00e0, problemi o pietre miliari, crea una filiale e assicurati che ci\u00f2 su cui stai lavorando sia tutto correlato. Ad esempio, non vuoi eseguire il lavoro sul database e JavaScript nelle tue richieste pull.<\/p>\n Anche se lavori esclusivamente sul lavoro front-end, potrebbe essere necessario dividerlo in rami pi\u00f9 piccoli. Semplifica le revisioni del codice e migliora le richieste pull<\/a>.<\/p>\n Questo \u00e8 molto simile al titolo precedente, ma l’idea di creare piccole PR \u00e8 molto pi\u00f9 produttiva rispetto alla creazione di richieste pull pi\u00f9 lunghe.<\/p>\n Ma cosa costituisce un buon PR?<\/p>\n Per quanto mi riguarda, una buona richiesta pull far\u00e0 una piccola serie di cose:<\/p>\n Detto questo, ci sono probabilmente pi\u00f9 cose che puoi fare, ma queste sono le cose che ho trovato pi\u00f9 utili (e mi dispiacerebbe dire che non ho imparato alcune di queste cose dal mio team<\/a> ).<\/p>\n Sempre.<\/p>\n Ma queste sono alcune cose che ho trovato sempre pi\u00f9 utili soprattutto quando si tiene traccia dei cambiamenti, si lavora con gli altri e si gestiscono richieste pull (sia da coloro con cui lavoro che da coloro che contribuiscono a progetti open source).<\/p>\n Infine, nessuna di queste cose \u00e8 prescrittiva. C’\u00e8 una curva di apprendimento (parlando per esperienza), ma consiglio di provarne alcuni se non altro per vedere se non migliora il tuo flusso di lavoro.<\/p>\n Anche se \u00e8 solo un po’.<\/p>\nSuggerimenti per un flusso di lavoro GitHub avanzato<\/h2>\n
1 Non impegnarti con il maestro<\/strong><\/h3>\n
2 Prova a creare sempre rami<\/strong><\/h3>\n
3 Prepara il tuo lavoro<\/strong><\/h3>\n
4 Genera piccole PR<\/strong><\/h3>\n
\n
5 Fornisci buoni dettagli nel tuo PR<\/strong><\/h3>\n
\n
Ci sono pi\u00f9 cose?<\/h2>\n