Ci stiamo spostando da Bitbucket a GitHub e una cosa con cui stiamo lottando sono le revisioni dei codici peer che hanno funzionato molto bene su Bitbucket in questo modo:

1. L'autore ha aperto una richiesta pull (GitHub: lo stesso)
2. L'autore ha aggiunto i suoi colleghi come revisori (GitHub: ?? lottando qui con più assegnatari)
3. Revisore:
   1. Approvato il PR con segno di spunta verde (GitHub: ??)
   2. Commenti aggiunti (GitHub: lo stesso)
   3. Attività leggere create (GitHub: una specie di simile se - [ ]nella descrizione PR viene utilizzata la sintassi; peccato che non funzioni per le attività)
4. C'è un elenco di PR dove posso vedere a colpo d'occhio che sono state riviste e OK per essere fuse e che richiedono ulteriore attenzione (GitHub: ??)

Vorrei sottolineare che vogliamo evitare gli strumenti di revisione del codice di terze parti, se possibile, e vorremmo rimanere su GitHub alla vaniglia con una sorta di soluzioni alternative.

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

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

Ecco come l'ho visto di solito fatto:

Autore che aggiunge i suoi colleghi come revisori:

Ciò varia da progetto a progetto, ma in generale, i revisori peer assegnati sono tutti i collaboratori del progetto .

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

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

In rare occasioni, qualcuno nel team può utilizzare un commento per chiamare in modo specifico un altro sviluppatore che pensa dovrebbe esaminare il codice prima che venga unito, ma in caso contrario, chiunque arriva prima e ha voglia di farlo può rivedere e fare commenti.

Approvazione del revisore:

L'approvazione viene in genere mostrata facendo un commento sulla richiesta pull che dice "+1" o "lgtm" (mi sembra buono).

Compiti leggeri:

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

• cambiando il codice su cui la riga sta commentando
• rispondendo con un altro commento

Vedendo a colpo d'occhio ciò che è approvato e ciò che deve ancora essere rivisto:

Ho usato l' estensione Looks Good To Me per Chrome, che ti offre tale vista dalla schermata Richieste pull. La visualizzazione dell'elenco delle richieste pull sembra essere stata interrotta dalle recenti modifiche di Github.