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?
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.
fuente
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 paramaster). 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).
Sin embargo, lo que desea evitar es algo parecido a esto:
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:
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.
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.
fuente
required-featurese fusionen.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.
fuente