En el flujo de GitHub, ¿está bien basar la rama de características en otra rama de características?

Usamos GitHub Flow en nuestro proyecto y la mayoría de las veces, abrimos una nueva rama de características desde master , hacemos un trabajo allí, abrimos un PR, revisamos el código y volvemos a fusionarnos en master .

Sin embargo, mi trabajo actual depende de otro problema en el que se está trabajando feature-branch-A. ¿Es kosher crear mi rama a partir de esa otra rama o va en contra del espíritu de GitHub Flow?

La alternativa sería basar mi rama en maestro y fusionar los cambios de feature-branch-A(con frecuencia).

¿Qué opción se prefiere en el flujo de GitHub?

Aquí está el flujo de trabajo que sigo cuando me ramifico desde una ramificación de características:

1. Crear feature-branch-Bdesdefeature-branch-A
2. Trabajar en feature-branch-B
3. Si se agregan más confirmaciones feature-branch-Adespués de la bifurcación, rebase feature-branch-Benfeature-branch-A
4. Finalice el trabajo feature-branch-By espere hasta que feature-branch-Ase fusione master.
5. Después de feature-branch-Afusionarse master, rebase feature-branch-Benmaster
6. Fusionarse feature-branch-Benmaster

Al seguir el flujo de trabajo anterior, parecerá que se bifurcó masterdespués de que feature-branch-Ase fusionó. No tiene que esperar hasta que feature-branch-Ase fusione para comenzar a trabajar feature-branch-B. Sin embargo, obtendrá una historia limpia sin árboles complicados.

Creo que esto está completamente bien si creas la característica en otra característica.

Pero no lo hagas con bastante frecuencia. Veo un desarrollador que hizo esto y una o dos semanas lanzó 10 PR para fusionarse. Eso fue completamente agotador para otros miembros para su revisión y difícil de fusionar también. Intenta no hacer árboles en git. Eso ayuda con la bisección para encontrar errores.

Una cosa clave que git-flow estaba destinada a abordar era la capacidad de razonar sobre el papel de una rama determinada, y de qué se ramifica y en qué se fusiona.

Idealmente, todas las ramas se fusionan con la línea de código de la que se fusionaron. Esto suele ser una fusión de la línea principal (en git-flow esto es dev). Presenta ramas y se fusionan desde el desarrollador, libera ramas y se fusiona desde el desarrollador (con una combinación adicional para master). Las correcciones rápidas se ramifican y fusionan desde el maestro (con esa fusión adicional de vuelta a dev).

Cada línea de código se ramifica y se fusiona con su padre. Una línea de código puede extraer código de otras líneas de código en cualquier momento si es necesario.

Si la rama de una rama de características es un "Quiero explorar esta forma de solucionar un problema en esa rama de características", está perfectamente bien. Se ramifica desde la rama de la característica, confirma algo de código y se fusiona con la rama de la característica (o se descarta).

1. derivar de la característica
2. explorar idea
3. fusionar para presentar

Sin embargo, lo que desea evitar es algo parecido a esto:

1. bifurcación de la característica requerida
2. trabajar en código
3. fusionarse desde el desarrollador una vez que la función requerida esté completa
4. verificar la funcionalidad (y confirmaciones adicionales) en la rama de características
5. fusionarse con dev

La razón es que el comienzo y el final no coinciden, lo que hace que sea un poco más difícil entender qué es y qué fue. No es imposible, pero solo hace que le tome un poco más de tiempo a alguien entender su papel.

Sin embargo, si esta es una nueva característica que depende del código que aún no se encuentra en dev, el flujo debería ser:

1. rama de dev
2. fusionar desde la función requerida
3. trabajar en código
4. fusionarse desde el desarrollador una vez que la función requerida esté completa
5. verificar la funcionalidad (y confirmaciones adicionales) en la rama de características
6. fusionarse con dev

Tenga en cuenta que esto comienza con una rama de dev y termina con una fusión de dev.

Dicho todo esto, probablemente lo mejor es evitar fusionar una característica con otra. Ramifique la función, haga los preliminares necesarios ... y espere.

1. rama de dev
2. trabajar en código
3. fusionarse desde el desarrollador una vez que la función requerida esté completa
4. verificar la funcionalidad (y confirmaciones adicionales) en la rama de características
5. fusionarse con dev

Esto proporciona el conjunto más estable de ramas y código.

Algo a tener en cuenta para el trabajo futuro sería tener una función para publicar las interfaces necesarias para la interoperabilidad con otras funciones, incluso si el código de implementación no está completo. Esto se fusionaría con dev, y luego la función requerida podría funcionar a partir de esas interfaces al igual que la función futura. Esto probablemente permitiría que la característica futura progrese más (codificando contra las interfaces, probando contra stubbs que implementan las interfaces) de lo que lo haría si tuviera que esperar a que la característica requerida se fusione con dev.

Una rama de características normalmente se considera menos estable que el tronco (desarrollo / maestro), por lo que posiblemente se someta a más cambios subyacentes de lo normal si basa su trabajo en uno.

Además, aunque normalmente está mal visto si la rama ha sido empujada, no es raro volver a colocar las ramas de características en su rama principal, para obtener un historial más agradable, pero eso sería muy complicado si hubiera ramas adicionales colgando de ella, por lo que Básicamente, está creando una nueva restricción para el propietario de la sucursal principal, así como posibles dolores de cabeza para usted.

Dicho esto, no hay una regla estricta en su contra. Estos son solo patrones y mejores prácticas después de todo.

Editar: se perdió parte de su pregunta. Fusionar la rama de características con la suya, que se basa en el maestro, en realidad no evita ninguno de los problemas mencionados anteriormente, y en realidad podría crear un historial aún más complicado.

Por lo tanto, si estuviera en su lugar y pudiera diferir el trabajo hasta que se realizara una función, o hacer otra cosa primero, lo haría.