¿Cómo debo incorporar una revisión de nuevo en una rama de características usando gitflow?

Comencé a usar gitflow para un proyecto, y tengo una rama de características sobresaliente, así como una revisión recién creada. Según el flujo de trabajo de gitflow, la revisión se aplica a las ramas maestra y de desarrollo , pero no se dice ni se hace nada sobre las ramas de características existentes.

Sin embargo, me gustaría incorporar los cambios de revisión a mi rama de características, que por lo que puedo decir deja tres opciones:

No incorpores los cambios. Si los cambios fueron necesarios para la rama de la característica, debería haber sido parte de la rama de la característica.
La fusión se desarrolla nuevamente en la rama de características. Esto parece seguir el flujo de trabajo de gitflow lo mejor, pero causaría confirmaciones fuera de orden.
Rebase la rama de características en desarrollar . Esto preservaría el orden de confirmación, pero el rebase parece estar completamente ausente del flujo de trabajo general de gitflow.

¿Cuál es la mejor práctica aquí?

git gitflow

Por lo general, se supone que las ramas de características tienen una vida muy corta, es una especie de olor a SCM fusionar cambios en ellas; ¿Es imposible terminar (o estabilizar) la rama de características y fusionarla nuevamente?

— Aaronaught

@Aaronaught bien, la función no está hecha / puede no ir a ninguna parte. La situación básica es que una característica que tarda un par de días en desarrollarse descubrió un error que podría afectar los datos de producción. Las pruebas fueron escritas, la revisión se aplicó al maestro / producción, pero la característica no terminada todavía está rota por el error. ¿Sugiere fusionar una característica a medio completar en la línea principal de desarrollo? ¿Qué sucede si la función no funciona?

No veo nada de malo en volver a crear su rama de características en desarrollar para recoger las últimas correcciones urgentes. En realidad, puede ser útil cambiar la frecuencia de su rama de características contra el desarrollo , ya que le permite mantener su rama "actualizada", lo que hace que la fusión sea mucho más fácil cuando llegue a esa etapa.

— Wayne Conrad
fuente

Sí: mirando a su alrededor algunas pruebas circunstanciales, incluido el anuncio de gitflow 0.2 que agregó rebase de características, apunta a que el flujo de trabajo regular de git rebase también es el flujo de trabajo de gitflow.

Interesante. No puedo decir que soy un experto en Gitflow, pero entendí que los hotfix eran cometidos singulares contra master, no ramas, y simplemente los elegí para desarrollarlos. Leyendo pensé que estaba totalmente equivocado en eso.

— jb510