Come fare revisioni tra pari su richieste pull GitHub?

12

Ci stiamo spostando da Bitbucket a GitHub e una cosa che stiamo affrontando sono le recensioni di peer code che hanno funzionato molto bene su Bitbucket in questo modo:

  1. L'autore ha aperto una richiesta di pull (GitHub: lo stesso)
  2. L'autore ha aggiunto i suoi colleghi come revisori (GitHub: ?? lotta qui con più assegnatari)
  3. Revisore:
    1. Ha approvato il PR con il segno di spunta verde (GitHub: ??)
    2. Aggiunti commenti (GitHub: lo stesso)
    3. Crea attività leggere (GitHub: una specie di simile se la sintassi - [ ] viene utilizzata nella descrizione di PR; vergogna che non funzioni per le attività)
  4. C'è una lista di PR dove posso vedere a colpo d'occhio che sono stati revisionati e OK da unire e che richiedono ulteriore attenzione (GitHub: ??)

Vorrei sottolineare che vogliamo evitare strumenti di revisione del codice di terze parti se possibile e vorremmo rimanere su van GitHub con una sorta di soluzione alternativa.

    
posta Borek Bernard 02.11.2015 - 11:09
fonte

1 risposta

6

Da quanto ho visto, la maggior parte di questi passaggi viene eseguita su Github per convenzione, e non da alcun processo ufficiale fornito da Github.

Il mio datore di lavoro usa Github, gestisco un buon numero di piccoli progetti open source e apporto occasionalmente ad altri progetti open source.

Ecco come ho visto di solito farlo:

Autore che aggiunge i suoi colleghi come revisori:

Questo varia da progetto a progetto, ma in generale i revisori peer assegnati sono tutti i contributori al progetto .

I progetti open source sembrano avere una gerarchia approssimativa - forse la loro convenzione sarebbe quella di fondersi solo dopo che un contributore "core" ha dato l'okay.

Nel negozio in cui sono attualmente impiegato, ci uniamo dopo che qualcuno della mezza dozzina di sviluppatori del team ha dato la sua approvazione.

In rare occasioni qualcuno del team può usare un commento per chiamare specificamente un altro sviluppatore che secondo loro dovrebbe rivedere il codice prima che venga unito, ma in caso contrario, chi arriva prima e sente di farlo può esaminare e commentare .

Approvazione revisore:

L'approvazione viene in genere indicata da che fa un commento sulla richiesta pull dicendo "+1" o "lgtm" (mi sembra buono)

Attività leggere:

Ho usato anche le caselle di controllo, ma nella maggior parte dei casi ogni commento su una richiesta pull è considerato un "task" implicito risolto da:

  • modifica del codice su cui la linea sta commentando
  • risposta con un altro commento

Vedendo a colpo d'occhio cosa è approvato e cosa è ancora necessario rivedere:

Ho utilizzato l'estensione Sembra buono a me per Chrome, che ti dà una tale visione dalla schermata Richieste pull. Tuttavia, la visualizzazione dell'elenco delle richieste di pull sembra essere stata interrotta dalle recenti modifiche di Github.

    
risposta data 02.11.2015 - 19:36
fonte

Leggi altre domande sui tag