Che cosa posso fare per consentire al nostro team di avere revisioni del codice delle fusioni di filiali con centinaia di schermate di valore di Github diff?

Questo è in realtà uno dei vantaggi dell'introduzione di revisioni del codice nella tua organizzazione: indurre le persone a apportare piccole modifiche incrementali. Aspetta solo che il tizio che ha commesso quell'enorme commit debba rivedere un tuo commit di dimensioni simili.

Altri modi più costruttivi per ottenere lo stesso risultato senza iniziare una "guerra del commit" potrebbero essere:

• impostazione di un limite superiore morbido per unire le dimensioni, come suggerito da altri
• non consentire modifiche che rompono il limite di diversi ordini di grandezza. Impegnati a romperli in pezzi più piccoli. O questo è possibile, o il cambiamento non è ben progettato dal suo autore.
• non controllare le librerie nel tuo repository, ma gestirle attraverso un sistema di compilazione come maven o scons . Questa è una raccomandazione così generica che mi chiedo se ci sia un vincolo particolare nel tuo team per controllare le librerie; in tal caso, ti suggerirei di conservarli in un repository separato. Se non sono il tuo codice, non devi controllarli.
• pianifica e prenota il tempo degli sviluppatori per eseguire revisioni del codice. Questo dovrebbe sicuramente contare come tempo di sviluppo. All'inizio, il processo ti rallenterà, ma in pochi mesi ti manterrà a velocità costante.

Scorrei il tentativo di trovare strumenti che automatizzano le revisioni del codice. Ciò sconfigge i due obiettivi principali della recensione: avere una revisione umana del significato di un cambiamento che sfuggirebbe a una macchina e diffondere la conoscenza della base di codice tra gli sviluppatori.

A volte non riesci a farla franca con un piccolo cambiamento. Potrebbe essere necessario rinunciare agli strumenti di revisione del codice di GitHub e usare Plain Old Git:

$ git remote add somebody https://github.com/somebody/repo.git
$ git fetch somebody
$ git diff --name-only development somebody/topic_branch
# shows list of files that were touched
$ git diff --name-status development somebody/topic_branch
# Shows list of files plus whether they were added, deleted, modifed, renamed, etc.

Quindi puoi usare:

$ git difftool development somebody/topic_branch -- ./path/to/file/or/directory

Questo ti aiuterà a ridurre la differenza

Oppure guarda le differenze tra tutti i file non aggiunti:

$ git diff --name-status development somebody/topic_branch | grep -vE '^A'

Se hai un commento da fare, puoi sempre tornare a GitHub e commentare il file o la linea una volta che hai avuto la possibilità di rivedere le cose.

Una soluzione funzionante consiste nel mettere un limite superiore morbido su quanto grandi fusioni accettate, ma le modifiche devono essere riviste come alcuni punti.

Se non hai ancora molta esperienza con le recensioni del codice sorgente, potresti anche iniziare a registrare le metriche delle recensioni (

• Unisci / commit dimensione
• Problemi risolti
• Errori introdotti
• Rivedi i rapporti
  • Recensore
  • Tempo utilizzato
  • Volume dei commenti
  • Conclusione
• ...

Questi numeri ti aiuteranno a capire quali dimensioni di unione / commit sono ottimali nella tua organizzazione.

Per il tuo esempio specifico, solo il commit separato della libreria esterna avrebbe reso l'intero problema molto, molto più piccolo. - La mia ipotesi di base sulle recensioni di fusione / commit è che il tempo necessario è proporzionale al quadrato della dimensione del "diff" (sono certo che il tempo di revisione non è solo lineare, come si assume). Se raccogli le metriche, sarai in grado di vedere quanto sia sbagliato il mio assunto.