Corrección de errores en una rama de características

Question

Estamos utilizando un A successful Git branching model de Vincent Driessen para nuestro modelo de ramificación. Todo está bien, pero realmente no he visto surgir un tema en particular.

Por lo que he entendido, cuando se requiere una nueva característica, se bifurca del development y crea una nueva rama feature. Trabajarías en esto y, cuando hayas terminado, fusionarías esta rama en la rama development.

¿Qué pasa si un desarrollador hace una función y luego fusiona esa función a development solo para descubrir que hay algunos errores en el código de característica. ¿Dónde debería arreglarse esto? ¿Debe iniciarse una nueva rama fix/bugfix desde el desarrollo y el código se debe corregir allí? No puedo ver otra manera.

¿Cómo se debe hacer esto?

Gracias

Answer 1

Recuerde que un modelo es solo un modelo: se trata de darle una estructura que lo haga más eficiente, sin seguir ciegamente un conjunto de reglas. Eso significa que debe sentirse libre de modificar las cosas y descubrir qué funciona en su situación, porque puede no funcionar en todas las situaciones.

yo creo que hay una opción en esta situación:

1. deshacer la fusión y continuar el trabajo en la rama de la característica hasta que está listo
2. iniciar una nueva rama de reparar el fallo.

Que uno elige depende de factores como:

• Pueden sus clientes ver el error? Haga una corrección de errores o una rama de revisión.
• ¿Es realmente malo el error y detiene otro progreso en la rama de desarrollo? Deshace el cambio.
• ¿Es solo un problema menor con un impacto externo mínimo? Simplemente continúe trabajando en la rama de características y vuelva a fusionar cuando esté listo.

La diferencia entre una rama de característica y una rama de corrección de errores no es importante desde el punto de vista de Git. Solo importa si usa esas etiquetas para la documentación interna u otros fines de auditoría (por ejemplo, para realizar un seguimiento de lo que es visible para los usuarios externos).

Resista la tentación de trabajar directamente fuera de la rama de desarrollo, incluso si cree que la corrección de errores será muy rápida, nada es tan simple como parece, y más adelante le dará un dolor de cabeza si algo sale mal.

representación visual aproximada de sus opciones:

Answer 2

Si esa rama de la característica es una pública (es decir, empujado a un acuerdo de recompra a distancia que se clona/utilizado por otros), lo mejor es hacer una nueva rama y aislar la depuración en dicha rama del arreglo.
(en lugar de intentar volver a establecer la base de la rama 'feature' en la rama 'develop').

La idea sigue siendo la de no registrar las confirmaciones de depuración intermedias directamente en la rama develop, pero para registrar solo la confirmación resultante que arreglará el error introducido por la fusión de la rama feature en primer lugar.

Answer 3

Solo haga una rama (o use la rama antigua y fusionada feature) y arréglela allí.

El uso de la rama anterior/crear una nueva bifurcación es lo mismo --- no puede nombrar cuál es el que después de la fusión.

Answer 4

¿Qué tal finding the commit that introduced the bug, and creating a new branch rooted there? Con este enfoque:

• No hay riesgo de crear referencias rotas debido a reajustar las operaciones
• Sólo a partir de la ascendencia de la rama de desarrollo, la rama de la característica, y cualquier otra rama que pueden ser afectados, se puede decir dónde deberías fusionar tu rama de corrección de errores una vez que haya terminado. Esto es cierto incluso si la "característica" se ha fusionado con el "desarrollo" varias veces desde la introducción del error.
• Si identifica la confirmación que introdujo el error y la raíz a partir de ahí, los desarrolladores podrán decir dónde deben combinar la rama de corrección de errores, incluso si no están familiarizados con el diseño del repositorio
• tener una rama que pueda fusionar sin temor a provocar cambios posteriores no relacionados. Por ejemplo, supongamos que alguien está trabajando en "feature-beta", que es una subdivisión de "feature" que divergió poco después de que se introdujo el error. Pueden tirar de la rama de corrección de errores fácilmente, sin preocuparse por extraer todo lo demás que ha ocurrido en la "función".
• Este enfoque reduce la necesidad de cereza-escoge, que tiene el inconveniente de que cambia el nombre de confirmaciones (socavando así una de las grandes ventajas del GIT, el cual está solicitando un nombre inequívoco a todo.)