¿Cómo mantener un historial limpio después de la revisión del código de solicitud de extracción de GitHub?

Question

Nuestro código está en Github y utilizamos Pull Requests para revisar el código. Como resultado de la revisión, una confirmación podría revertirse o modificarse. Esto podría desordenar el historial de compromisos. Se desaconseja el comando rebase porque los commits ya están "disponibles públicamente".

Si realiza revisiones de código de manera similar: ¿Cómo lidia con esto? ¿Cómo mantienes tu historia limpia?

Answer 1

Rebasar las ramas no maestras (maint *, siguiente) está bien, incluso si están publicadas. Solo usa ramas de temas para publicar cosas nuevas para ser revisadas. A continuación, elimínelos en cualquier caso después de fusionarlos en maestros o después de que la solicitud de extracción haya sido rechazada. Ver man gitworkflows

Answer 2

Sugeriría simplemente superar el desorden del historial de compromisos.

Tenga en cuenta que cuando mira la historia, generalmente está mirando la ascendencia de alguna confirmación actual. Si su proceso de revisión de código crea ramas de extremo muerto para el código que se rechazó o volvió a enviar como una confirmación diferente, entonces esas no tendrán tal ascendencia, y generalmente no se verán.

Aquí está un ejemplo de largo aliento, pero completa de esto, utilizando git log como el visor de la historia:

$ git init example 
Initialized empty Git repository in /private/tmp/example/.git/ 
$ cd example/ 
$ date >date 
$ git add date 
$ git commit -am base 
[master (root-commit) 5108762] base 
1 files changed, 1 insertions(+), 0 deletions(-) 
create mode 100644 date 
$ date >date 
$ git commit -am bad 
[master 440c3b6] bad 
1 files changed, 1 insertions(+), 1 deletions(-) 
$ git log 
commit 440c3b61b279e8b7cd5f5f656984b63ba18e518b 
Author: Tom Anderson <twic@urchin.earth.li> 
Date: Sat Mar 10 09:15:48 2012 +0000 

    bad 

commit 5108762ba7011464fe3c57cf762d0d18f337f68c 
Author: Tom Anderson <twic@urchin.earth.li> 
Date: Sat Mar 10 09:15:28 2012 +0000 

    base 
$ git branch postreview 5108762ba7011464fe3c57cf762d0d18f337f68c 
$ git checkout postreview 
Switched to branch 'postreview' 
$ date >date 
$ git commit -am good 
[postreview 42e5257] good 
1 files changed, 1 insertions(+), 1 deletions(-) 
$ git log 
commit 42e5257addf73b516676d24e7092b0e4768d3564 
Author: Tom Anderson <twic@urchin.earth.li> 
Date: Sat Mar 10 09:17:30 2012 +0000 

    good 

commit 5108762ba7011464fe3c57cf762d0d18f337f68c 
Author: Tom Anderson <twic@urchin.earth.li> 
Date: Sat Mar 10 09:15:28 2012 +0000 

    base 

A pesar de que la entrega mala está en el repositorio, que no aparece en la salida de git log . En este caso, he creado una nueva rama para hacer mi trabajo posterior a la revisión, pero en la práctica, es probable que desee mover el maestro para el nuevo trabajo, dejando el trabajo anterior en una rama muerta.