Flusso di lavoro per la revisione del codice basata su GitHub

Question

Sto pensando di utilizzare GitHub come strumento principale per eseguire la revisione del codice. Con funzionalità come la visualizzazione in linea e la vista di confronto, sembra che abbia molte funzionalità che gli strumenti come Gerrit hanno in offerta.

Qualcun altro ha utilizzato GitHub per questo? Se sì, qual è il tuo flusso di lavoro? E quali sono state le tue esperienze, sia positive che negative?

Mentre riesco a capire come funzionerà meglio per noi, modificherò la mia domanda per condividere il mio flusso di lavoro.

modificato con il flusso di lavoro proposto

passaggio 0. Set up a post-receive hook utilizzando l'impressionante reviewth.is.

Poi:

1. Commit come al solito con commit -a -s, ma nel messaggio di commit accoda #reviewthis @username.

2. Se la compilazione fallisce, la revisione viene saltata fino al ripristino della build.

3. I commenti del revisore sul commit riga per riga oa livello di file.

4. GitHub notifica automaticamente i commenti ai revisori.

5. Il revisore notifica il cliente tramite email quando i commenti vengono completati con un riepilogo di recensione.

6. Reviewee risponde ai commenti del revisore all'interno di GitHub, consentendo al progetto l'accesso alla cronologia delle revisioni del codice.

miei più grandi problemi sono con il Passo 2 e 4/5 passaggi. Gerrit funziona bene per non chiedere recensioni a meno che la compilazione non abbia esito positivo; Mi piacerebbe un modo per farlo all'interno di GitHub. I passaggi 4/5 hanno anche il potenziale per diventare fastidiosi (più e-mail) e ridurre la natura automatica del processo di revisione (che richiede un riepilogo inviato tramite e-mail).

Usiamo Hudson come server di build, se questo aiuta.

Qualsiasi idea su questi problemi sarebbe anche utile.

Answer 1

L'ho usato per questo. Il flusso di lavoro che ho usato è di fare il tuo lavoro su un ramo argomento e inviare una richiesta di pull su quel ramo. La (le) persona (i) di revisione esamina il codice e il commit, usando i commenti by-line (e by-commit). Il coder prende quel feedback e fa un rebase distruttivo su quel ramo dell'argomento, lo re-spinge (riscrivendo la cronologia sul suo repository github), quindi il ciclo di revisione si ripete finché non è accettabile unire.

Modifica: Un Githubber ha pubblicato sul suo blog che descrive il metodo che usano per sviluppare Github stesso ed è molto simile a quello che ho proposto. link

Aggiornamento: ho utilizzato questo flusso di lavoro sia nei miei progetti open source che nel mio lavoro professionale è ancora ottimo.

Answer 2

Al mio lavoro seguiamo praticamente la procedura descritta in "Using pull requests" per la revisione del codice e ne siamo abbastanza contenti.