Organizzazione del flusso di lavoro Git in piccoli team

Abbiamo impostato la nostra soglia per avere due revisioni tra pari su una richiesta di pull prima della fusione. Ciò significa che per ogni persona che invii, in media ne stai esaminando due. Questo non è un grosso problema.

In piccole correzioni di tipo typo / reformatting, generalmente chiediamo solo una revisione tra pari. Sì, di tanto in tanto prendiamo le cose su queste recensioni, perché la gente pensa che siano così semplici da non aver bisogno di stare attenti. In caso di modifiche architettoniche ampie e radicali, chiederemo a più persone di esaminare, ma per il lavoro quotidiano, due sono sufficienti.

Non deve rallentarti. Puoi continuare il tuo lavoro mentre aspetti le recensioni tra pari. Molto spesso tiro i rami avanti e indietro tra un collega prima di inviarlo per la revisione finale.

Per lo più, le persone devono solo abituarsi ai benefici. Una volta che le recensioni e, auspicabilmente dopo, un server CI, iniziano a rilevare errori, le persone saranno più disposte a eseguirle.

Non preoccuparti dei piccoli commit e permessi. Quello su cui vuoi lavorare ora è che le persone lavorano su biglietti piuttosto che su cose casuali.

Ottenere un sistema di ticket in esecuzione e chiedere alle persone di controllare tutto il lavoro in un ramo di funzionalità con un nome che includa il numero del biglietto e il titolo del biglietto. Dillo loro in modo da poter collegare i sistemi (che puoi)

Coinvolgi le persone quando lavorano su cose senza biglietti, piuttosto che sul ramo delle funzionalità mancanti dispari. Poiché questa è la causa principale del caos. Non la strategia di check-in.

Non consiglierei le richieste di pull o le revisioni del codice. Ma il 15 è piuttosto un team. Ti suggerisco di dividerlo in 3 squadre di 5

DO concentrati sui test automatici come tua prossima priorità. È davvero essenziale

Perché stai passando a git? Passare a git potrebbe non risolvere i problemi che si verificano, e in effetti potrebbe solo creare di più. SVN è un bel VCS moderno che dovrebbe essere molto lavorabile. Prima di passare a git, potresti voler esaminare più a fondo i problemi che stai avendo ora, e vedere se possono essere risolti in SVN; se è così, questo rende più facile per tutte le persone coinvolte. Cambiare il tuo VCS senza modificare il tuo processo non risolverà nessuno dei tuoi problemi.

Detto questo, alcune risposte a specifici punti nella tua domanda sono qui sotto. Si noti che questi sono indipendenti dal VCS che si sta utilizzando. La risposta tl; dr è che devi solo sperimentare e vedere cosa funziona meglio per la tua squadra nella tua situazione. Sii disposto a provare qualcosa per un paio di settimane / mesi e modificalo se non produce gli effetti desiderati.

Le revisioni del codice / le richieste di pull sono un ottimo modo per prevenire il codice non funzionante e gli sviluppatori pazzi, se hanno finito. Vuoi stare attento a non richiedere troppo tempo per la revisione, altrimenti le persone non le faranno (in modo tempestivo). Inoltre, si vuole essere sicuri che gli sviluppatori non stiano aspettando con insistenza che i revisori guardino e approvino il codice; hanno bisogno di qualcos'altro su cui lavorare nel frattempo. Assicurati che il tuo backlog non sia vuoto.

Quick significa non solo il numero di recensioni, ma anche la dimensione. Due revisori per richiesta di pull sono un buon punto di partenza, ma in una squadra di 15 potresti essere in grado di avere di più. Questo si lega anche alla dimensione delle recensioni; se impiegano mezza giornata, la gente non vuole farle e sarà difficile persino ottenere 2 revisori. Se sono veloci, 15 minuti o giù di lì, potresti trovare molti più revisori a guardarli.

Devi anche assicurarti che la maggior parte delle tue richieste di pull siano di dimensioni gestibili - ho scoperto che cambiamenti sostanziali in più di 4 o 5 file possono essere un po 'opprimenti da svolgere tra le attività, in quanto richiede molto più concentrazione. Ma ancora, dovrai sperimentare per vedere cosa funziona meglio per la tua squadra. Ovviamente, una revisione di tanto in tanto è di solito inevitabile, ma non è la norma.

Il rovescio della medaglia, le recensioni minuscole consumano un sacco di spese generali. Puoi inviare molte piccole modifiche come una sola richiesta di pull o rinunciare al requisito di PR per cambiamenti banali (come errori di battitura o correzioni di bug minori) e apportare semplicemente le modifiche sul ramo principale. Dovrai sperimentare e vedere cosa funziona per il tuo team.

Utilizza l'automazione per occuparti della formattazione del codice, quindi non devi nemmeno preoccuparti di quelle richieste di estrazione. Questo ha il vantaggio di mantenere tutto il codice in uno stile, pure.