Git: arreglando un error que afecta a dos ramas

Estoy basando mi repositorio de Git en un modelo de ramificación Git exitoso y me preguntaba qué sucede si tiene esta situación:

Digamos que estoy desarrollando en dos ramas de características A y B, y B requiere el código de A. El nodo X introduce un error en la función A que afecta a la rama B, pero esto no se detecta en el nodo Y donde las funciones A y B se fusionaron y Las pruebas se realizaron antes de volver a ramificarse y trabajar en la siguiente iteración.

Como resultado, el error se encuentra en el nodo Z por las personas que trabajan en la función B. En esta etapa, se decide que se necesita una corrección de error. Esta corrección debe aplicarse a ambas funciones, ya que las personas que trabajan en la función A también necesitan que se solucione el error, ya que es parte de su función.

¿Debería crearse una rama de corrección de errores desde el último nodo de la función A (el que se bifurca desde el nodo Y) y luego fusionarse con la función A? ¿Después de lo cual ambas características se fusionan para desarrollarse nuevamente y probarse antes de ramificarse?

El problema con esto es que requiere que ambas ramas se fusionen para solucionar el problema. Dado que la característica B no toca el código en la característica A, ¿hay alguna forma de cambiar el historial en el nodo Y implementando la corrección y aún permitiendo que la rama de la característica B permanezca sin fusionar pero tenga el código fijo de la característica A?

Relacionado levemente: convención de ramificación de error Git

Use un commit distinto para corregir el error en una rama, luego seleccione ese commit en la otra rama.

Podría decirse que no hay ningún error en A o X. Repare el error en la rama B donde se encontró. La corrección se propagará a X y A en el curso normal de los eventos.

Aunque no es un flujo de trabajo popular git, un flujo de trabajo que es popular en Mercurial sería actualizar a revisión X, corregir el error allí (comoX ² ) y luego rehacer fusión Y(que habría sido un par de fusiones en Mercurial).

De hecho, este flujo de trabajo es más fácil en gitya que después de todo el mundo ha cambiado de Ya Y² a continuación, los árbitros al original Yse perderán y que finalmente será basura recogida. En hglo que habría tenido para despojar manualmente esas confirmaciones para poner en orden su repositorio.