5 idee per un flusso di lavoro GitHub avanzato
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ì via, varia.
Inoltre, a seconda se stai usando Git, Subversion, Mercurial e così via, detta anche come gestisci il tuo codice.
Ma se sei qualcuno che sta lavorando con Git (che so che molte persone in WordPress stanno iniziando a usare sempre di più quasi quotidianamente), ci sono alcune piccole cose che consiglio di fare per aiutare a gestire le modifiche specialmente con un team più gestibile.
Suggerimenti per un flusso di lavoro GitHub avanzato
1 Non impegnarti con il maestro
Il master deve essere utilizzato specificamente per il codice pronto per la produzione e per la distribuzione. Non è il tuo ramo di lavoro, non è il tuo ramo di lavoro.
In generale, è qui che vengono unite tutte le richieste pull.
2 Prova a creare sempre rami
Ogni volta che hai una raccolta di attività, problemi o pietre miliari, crea una filiale e assicurati che ciò su cui stai lavorando sia tutto correlato. Ad esempio, non vuoi eseguire il lavoro sul database e JavaScript nelle tue richieste pull.
3 Prepara il tuo lavoro
Anche se lavori esclusivamente sul lavoro front-end, potrebbe essere necessario dividerlo in rami più piccoli. Semplifica le revisioni del codice e migliora le richieste pull.
4 Genera piccole PR
Questo è molto simile al titolo precedente, ma l’idea di creare piccole PR è molto più produttiva rispetto alla creazione di richieste pull più lunghe.
- Questo aiuta quando devi richiedere una revisione del codice in quanto offre ai tuoi compagni di squadra un modo più semplice per gestire le revisioni del codice e offrire feedback.
- Mantiene snello il registro delle modifiche e aiuta a fornire un rapporto dettagliato di ciò che fa lo specifico batch di codice.
Ma cosa costituisce un buon PR?
5 Fornisci buoni dettagli nel tuo PR
Per quanto mi riguarda, una buona richiesta pull farà una piccola serie di cose:
- Descrivi in dettaglio, in una o due frasi, ciò che la persona che sta esaminando le tue modifiche dovrebbe aspettarsi che accada.
- Collega il PR al ticket, alla scheda di gestione del progetto (o come lo chiamano nel tuo sistema),
- Elenca le versioni più brevi dei messaggi di commit per renderlo il più semplice possibile per il tuo peer reviewer.
Detto questo, ci sono probabilmente più cose che puoi fare, ma queste sono le cose che ho trovato più utili (e mi dispiacerebbe dire che non ho imparato alcune di queste cose dal mio team ).
Ci sono più cose?
Sempre.
Ma queste sono alcune cose che ho trovato sempre più 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).
Infine, nessuna di queste cose è prescrittiva. C’è 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.
Anche se è solo un po’.