Flusso di lavoro di revisione Gerrit: unione conflitti e ri-approvazione

Question

Stiamo valutando l'ipotesi di utilizzare Gerrit per il progetto di grandi dimensioni. A questo punto sarebbe interessante sapere in che modo le persone si occupano dei conflitti di fusione delle modifiche approvate.

Immaginate, che molti cambiamenti di dimensioni diverse sono in attesa di revisione simultanea, e sono in fase di revisione e di verifica graduale. Poiché alcuni potrebbero modificare lo stesso codice, i conflitti sono inevitabili. Non è un problema se "integratore" accetta le patch manualmente in un semplice flusso di lavoro, piccoli conflitti possono essere risolti sulla strada, ma con Gerrit le cose sono diverse. Quando la modifica è stata rivista e approvata, in caso di conflitto di fusione, a quanto ho capito, dovrà essere ribattuta dall'autore e inviata nuovamente per la revisione, nel qual caso il processo di revisione ricomincia. Nei progetti relativamente attivi, con oltre 50 commit di contributori esterni a settimana, questo potrebbe trasformarsi in incubo, se la revisione della stessa patch potrebbe essere richiesta più volte a causa di un rifiuto di fusione dopo ogni approvazione e invio, che sembra essere non efficiente.

Domande:

1. Am correggo che Gerrit non è un passo in avanti per la roba grande e attiva, in cui si prevede che il gran numero di conflitti di unione?

2. Alcuni conflitti di unione possono essere banali, esiste un modo per risolverli senza la necessità di sollecitare l'autore a riprendere il cambiamento?

3. Se la modifica deve essere ripristinata su diramazioni stabili, suppongo che la modifica separata per ogni ramo debba essere sottoposta a revisione, anche se il selezionamento è pulito.

I commenti generali sull'esperienza del flusso di lavoro Gerrit sono anch'essi benvenuti.

Answer 1

1. Gerrit è utilizzato da alcuni progetti davvero imponenti, come Android e il relativo bsp, kernel, ecc repository. Questi progetti ottengono più di 50 commit esterni a settimana. Penso che Qualcomm avrà diverse migliaia di commit in quella quantità di tempo.

2. C'è un'impostazione in Gerrit per l'unione automatica di conflitti banali. Questo può essere impostato per-repository. Se questa opzione è impostata, la modifica viene unita in base alla strategia di invio (scelta rapida, unione se necessario) dopo che la modifica è stata verificata e verificata e un utente preme il pulsante "Invia". La migliore documentazione che ho trovato per questo è qui http://gerrit-documentation.googlecode.com/svn/Documentation/2.3/cmd-create-project.html#_options sotto l'opzione --use-content-merge.

3. Sì, in genere è così che facciamo le cose. Ci sono altre opzioni (ignorando la revisione, unendo i rami, ecc.), Ma selezionando i rami necessari e la revisione funziona bene.

Answer 2

Quando si verifica un problema di unione nella nostra azienda, lo sviluppatore rebase e invia a gerrit. Se l'unione è stata minima, è consentito (per convenzione) a LGTM il rebase e inviare.

Stiamo ancora discutendo se/quando gli sviluppatori devono eseguire il rebase durante l'aggiornamento dei set di patch. L'interfaccia utente si confonde quando si confrontano i set di patch quando il genitore cambia.

Answer 3

Vogliamo mantenere la nostra storia pulita e comprensibile, e quindi ragionevolmente lineare. Quindi abbiamo configurato Gerrit per utilizzare solo la fusione veloce.Le sole fusioni visibili sono per i rami di rilascio e supporto (stiamo usando git-flow) che rende le cose molto più facili da capire.

Tuttavia, è stato installato il plugin trivial-rebase in modo che lo stato di revisione precedente venga applicato automaticamente alla modifica rebased. Ciò si verifica indipendentemente dal fatto che il rebasing venga eseguito in Gerrit (utilizzando il pulsante Rebase) o dal rebasing dello sviluppatore in locale e dalla ripetizione della modifica.

Nella nostra esperienza, i conflitti di unione sono in realtà meno comuni in un progetto di grandi dimensioni, a causa del numero molto più elevato di file di origine coinvolti. Abbiamo circa 16.000 file nel repository e 30 sviluppatori full-part o part-time, quindi la probabilità di modificare lo stesso file è piuttosto bassa.

In ogni caso, se due sviluppatori stanno apportando modifiche alla stessa parte dello stesso file, dovrebbero davvero parlare tra loro. Se l'architettura del progetto richiede frequenti modifiche allo stesso file (ad esempio una tabella di registrazione di qualche tipo), l'architettura deve essere ridisegnata, utilizzare qualcosa come dependency injection o generare automaticamente tale file sorgente dai frammenti come parte della build.

Answer 4

Lo sto usando per alcune settimane dopo aver usato mercurial per un paio di anni con un ramo di funzionalità fuso in modalità predefinita e sto odiando gerrit. Mi trovo con più overhead che risolvono conflitti banali che vengono risolti automaticamente dall'unione su mercurial o git in modalità non gerrit. Quindi tutti usano l'argomento Android usa gerrit ergo gerrit è buono e dovrebbe funzionare per tutti.