Gerrit, git y revisando toda la rama

8

Ahora estoy aprendiendo Gerrit (que es la primera herramienta de revisión de código que uso). Gerrit requiere que un cambio revisado consista en un solo compromiso. Mi rama de función tiene alrededor de 10 confirmaciones.

La forma preferida de gerrit es aplastar esas 10 confirmaciones en una sola. Sin embargo, de esta manera, si la confirmación se fusionará en la rama de destino, se perderá el historial interno de esa función. Por ejemplo, no podré usar git-bisect para dividir en esas confirmaciones. Estoy en lo correcto?

Estoy un poco preocupado por este estado de cosas. ¿Cuál es la razón para esta elección? ¿Hay alguna forma de hacer esto en Gerrit sin perder la historia?

    
pregunta liori 15.06.2012 - 17:58

2 respuestas

2

La revisión del código tiene el mejor impacto cuando se trata de un gancho de pre-confirmación (pre-push en caso de git). Si se produce un error en el 5 de tus diez confirmaciones, ¿cómo lo arreglarías (conservando el historial)? Claro, puede crear otra rama de tema, corregir ese compromiso, seleccionar los 5 confirmaciones restantes y reenviar las diferencias para su revisión, pero esto es muy complejo (aunque puede escribir un script para ello).

Los cambios realizados en un solo repositorio deberían idealmente preservar su estado (por ejemplo, no interrumpir la compilación, las pruebas, etc.) Por lo tanto, si los cambios se realizan de esta manera, se pueden revisar por separado. De lo contrario, sería mejor aplastarlos. dejando el repositorio inconsistente.

Puedes crear un error en el rastreador de errores y poner una referencia en cada confirmación, para que los revisores y futuros lectores sepan lo que intentabas lograr en su totalidad.

    
respondido por el vissi 16.06.2012 - 00:36
1

¿Qué pasa con la integración continua? hizo 10 confirmaciones en una rama de función y se "publicará" de una vez, lo que sería un gran impacto para otras personas que deberían revisar esas confirmaciones / cambios.

Sin embargo, vale la pena empujar 10 confirmaciones, si las confirmaciones contienen modificaciones de código separadas. Pero en caso de que las confirmaciones contengan modificaciones continuas en una sola función (de modo que la mayoría de las correcciones de confirmaciones simples o el estado intermedio de una implementación en curso de una definición de función) es mejor aplastarlas en una única confirmación.

En general, piense con la mente de los revisores: cuál es el tamaño de una modificación de código que puede revisarse fácilmente.

Nota: Gerrit no es solo para revisar el código; los cambios deben desencadenar varias pruebas de aceptación. (prueba de unidad, prueba de humo) Entonces, si los tiene, entonces es más difícil publicar códigos defectuosos. Por lo tanto, desde esta perspectiva, un compromiso debe contener dichos cambios que vale la pena probar.

Así que Gerrit te obliga a no realizar cambios demasiado pequeños y demasiado grandes. (utilizará --amend no solo para corregir un cambio que ya se haya enviado a Gerrit, en lugar de corregir la confirmación que desea solicitar para su revisión)

    
respondido por el laplasz 16.09.2013 - 16:11

Lea otras preguntas en las etiquetas

Comentarios Recientes

a menudo son propensos a conflictos de fusión accidentales, porque los usuarios que solo necesitan ejecutar la fusión traerán de vuelta los archivos actualizados a su árbol predeterminado. Al igual que Mercurial, puedes pensar que ese cambio es de grado cruzado; A diferencia de Mercurial, que tiene una opinión de solo los valores necesarios cuando está de acuerdo, las herramientas basadas en Clang como Mercurial eliminan esas expectativas a favor de reconocer de forma predeterminada las Merges competidoras y las... Lee mas