Gerrit, git e revisione di tutto il ramo

La revisione del codice ha l'impatto migliore quando si tratta di un hook pre-commit (pre-push in caso di git). Se si verifica un errore in 5 dei tuoi dieci commit, come lo risolveresti (preservando la cronologia)? Certo, puoi creare un altro ramo argomento, correggere quel commit, selezionare i restanti 5 commit e inviare nuovamente i diffs per la revisione, ma questo è molto complesso (anche se puoi scrivere uno script per questo).

Le modifiche apportate a un singolo repository dovrebbero idealmente preservare il suo stato (es. non rompere la build, i test, ecc.) Quindi se le modifiche sono fatte in questo modo, possono essere esaminate separatamente, altrimenti, schiacciandole sarebbe meglio, rispetto lasciando la repo incoerente.

Puoi creare un bug nel bug tracker e inserire un riferimento in ogni commit, in modo che i revisori e i futuri lettori possano sapere, cosa stavi cercando di ottenere per intero.

E riguardo l'integrazione continua? hai fatto 10 commit su un ramo di funzionalità e sarà "pubblicato" in una sola volta - ciò avrebbe un impatto enorme su altri che dovrebbero rivedere quei commit / cambiamenti.

Tuttavia vale la pena spingere 10 commit, se i commit contengono modifiche al codice separate. Ma nel caso in cui i commit contengano continue modifiche su una singola feature (quindi la maggior parte dei commit si limita alle correzioni o allo status intermedio di un'implementazione in corso di una definizione di funzione), allora è meglio schiacciarli in un singolo commit.

In generale, pensa con la mente dei revisori: qual è la dimensione di una modifica del codice che può essere rivista facilmente.

Nota: Gerrit non è solo per la revisione del codice: le modifiche dovrebbero innescare diversi test di accettazione. (unit test, smoke test) Quindi se ne hai, allora è più difficile pubblicare codici difettosi. Quindi da questa prospettiva un commit dovrebbe contenere tali cambiamenti che vale la pena di testare.

Quindi Gerrit ti costringe a non commettere modifiche troppo piccole e troppo grandi. (utilizzerai --amend non solo per correggere una modifica già inviata a Gerrit, invece di correggere un commit che vuoi push per la revisione)