2016-06-02 23 views
11

Ogni volta che ho inviato una recensione a Gerrit e se la recensione è in sospeso da tempo, ricevo il messaggio cannot merge in Gerrit.Impossibile unire in Gerrit

Ho capito che sarebbe venuto perché qualcun altro avrebbe cambiato lo stesso file/file e consegnato prima di me. Sto cercando di soluzione alternativa per risolvere il mio problema.

  1. Abbandonare la revisione corrente.
  2. Creare una nuova filiale locale, prendere un pull
  3. cherry-pick il mio commesso da vecchio ramo e inviare a Gerrit

Questo funziona, ma i commenti di revisione tutto quello che avevo non sarebbe più disponibile ed è difficile per il mio revisore controllarlo di nuovo.

Sto cercando un modo per rimuovere cannot merge dalla revisione corrente. Grazie!

risposta

20

NON è necessario abbandonare la modifica corrente su Gerrit per risolvere il problema "non è possibile unire". Tutto quello che dovete fare è:

  1. Aggiornamento repository locale (git fetch)
  2. Eseguire un rebase manuale (git rebase)
  3. risolvere i conflitti (git mergetool)
  4. commit (modificare) il risultato (git commit --amend)
  5. spingere un nuovo patchset a Gerrit (git push)
+0

Ha funzionato, Grazie :) –

+0

Wow, come puoi modificare, se sei in fase di fusione? – Koshinae

+1

È possibile modificare il commit tutte le volte che è necessario prima che la modifica venga inviata. Vedi maggiori informazioni su: https://gerrit-review.googlesource.com/Documentation/intro-quick.html –

2

La procedura ottimale quando si lavora su un code base condiviso utilizzando git/gerrit è mantenere le modifiche al minimo. Da una parte, in questo modo, la possibilità che qualcuno unisca le sue modifiche prima di abbassarsi. D'altra parte, è possibile effettuare il pagamento di il prima possibile in modo che le modifiche possano essere riviste più facilmente.

Non sono sicuro che questo risponda alla tua domanda ma seguo queste due regole e non ho problemi.

+0

Come posso mantenere le modifiche al minimo? –

+2

Per me le modifiche al minimo si riferiscono alla mancata combinazione del codice di refactoring con il nuovo codice e la suddivisione viene eseguita dall'ambito, ad esempio: commit refactor, commit di implementazione, commit di testing (principalmente per aumento della copertura di test), commit dell'aggiornamento delle dipendenze e così via. Un'altra cosa è che cerco di mantenere il commit il più isolato possibile (solo funzionalità e test) – Timotei

4

Prova rebase pulsante, che può risolvere la maggior parte non può-merge è fa causa. Se riesce a trovare il commit corretto da rebase su se stesso, va bene. Se non è possibile, trova l'ultimo commit del ramo di destinazione e compila il bianco di commit. A volte dovresti prima inviare il commit, sul quale il non-merging one ha dipendenza. Se non può funzionare comunque, basta abbandonarlo e rendere il commit basato sull'ultimo commit.