revisión de código con git-flow y github

Con git y github normales puedo hacer una revisión de código simplemente creando una solicitud de extracción de la rama de características en la que estoy trabajando para la rama maestra. ¿Cómo haría revisiones de código con git-flow? Con un flujo de trabajo como "finalización de la función de flujo de git", estoy confundido sobre dónde sucede realmente la revisión del código y cómo git-flow o git pueden facilitar esa revisión.

Nos topamos con este problema exacto recientemente. Realmente nos gusta el flujo de git, ya que usa un buen nivel de semántica (usando el mismo nivel que usas en la discusión en equipo: "Comenzaré la función A" más que "Crearé una rama, la veré"), mientras git tiene un nivel de "implementación" muy bueno (que es bueno y útil también, pero diferente).

El problema que tenemos es git feature finish, ya que fusiona la rama en el desarrollo, mientras que queremos que se envíe una solicitud de extracción y (esto es importante) fusionada por el revisor , no por el responsable, para enfatizar la propiedad del equipo.

Nuestra solución actual:

1. Alguien usa git flow para crear una rama de características
2. Cuando termina, crea una solicitud de extracción (usando github)
3. La revisión tiene lugar, con posibles compromisos adicionales
4. El revisor fusiona la solicitud de extracción mediante GitHub .
5. No hay acabado de la característica de flujo de git (ya que la rama ya está fusionada)

Esto es consistente con nuestra práctica, con la desventaja de requerir que eliminemos la rama nosotros mismos (ya que no damos fin al flujo). Nuestro próximo paso probablemente será volver a implementar algunas partes del flujo de git (ya que se trata principalmente de encadenar comandos de git) para tener esto en cuenta (tener la parte de "limpieza" del acabado, sin la fusión).

El proceso que utiliza el equipo con el que trabajo es el siguiente:

1. Crear una rama de características: git flow feature start module_1
2. El código se actualiza en la rama de características
3. A medida que se confirman los cambios, se envían a GitHub (o una vez al final si se prefiere)
4. Cuando se completa la función, se abre una solicitud de extracción en la comparación de GitHub developy la rama de la funciónmodule_1
5. El equipo revisa la solicitud de extracción y hace comentarios.
6. Cualquier cambio de la solicitud de extracción se realiza en la rama de características
7. Una vez que se incorporan todos los cambios en la rama de características, la rama de características termina: git flow feature finish module_1
8. La developrama se envía a GitHub (GitHub marcará automáticamente la solicitud de extracción como cerrada / fusionada cuando esto suceda)

Normalmente todo este proceso lo realiza el autor original, pero eso no es obligatorio. Cualquier persona en nuestro equipo puede intervenir y retomar este proceso en cualquier momento. Todo lo que tienen que hacer es pagar la rama de características y continuar con el proceso. Quien ejecute git flow feature finish module_1tendrá el lujo de que se elimine su rama de características locales, pero cualquier otra persona que haya revisado la rama tiene que hacerlo manualmente si quieren usar algo como git branch -D feature/module_1.

Para las revisiones, utilizamos un enfoque similar y creamos la solicitud de extracción en GitHub antes de finalizar la revisión.

Si está haciendo revisiones de código, entonces supondré que tiene un repositorio central que contiene el código "oficial". Los desarrolladores extraen y empujan a este repositorio central.

Cuando usa Gerrit , Gerrit se convierte en el repositorio central (tiene servidores SSH y HTTP integrados que permiten a los usuarios interactuar con él básicamente de la misma manera que ya lo son). Al usar Gerrit, el flujo de trabajo se convierte en:

1. El desarrollador realiza cambios en cualquier rama, se compromete localmente.
2. El desarrollador empuja esos cambios a Gerrit.
3. Gerrit crea artículos de revisión para que otros lo revisen.
4. Los pares revisan el código, hacen comentarios y aceptan o rechazan la confirmación.
5. Cuando el commit es aceptado, entonces Gerrit hace que los cambios estén disponibles para otros para tirar de la rama.

Cuando se utiliza un repositorio central, otros desarrolladores pueden ver los cambios enviados después del paso 2. Gerrit presenta el flujo de trabajo de revisión de código, por lo que otros desarrolladores solo ven los cambios enviados después del paso 5.

Esto funciona bien con git-flow (o cualquier otro esquema de ramificación) porque Gerrit admite la revisión de los cambios realizados en cualquier rama.

Aquí hay otra sugerencia.

1. Realice el proceso regular de flujo de git para crear una característica , pero no la termine ni combine.
2. Cree una solicitud de extracción , pero no la combine. Espere a que el aprobador deje un comentario. El comentario es la marca de aprobación.
3. Hacer el flujo git terminar . (El aprobador o el desarrollador pueden hacer esto, dependiendo de lo que el equipo haya acordado). La solicitud de extracción se marcará como fusionada en github. Aún necesita eliminar la rama en origen.