Gitflow: la característica termina sin hacer una combinación --no-ff

Creado en 14 feb. 2011  ·  12Comentarios  ·  Fuente: nvie/gitflow

Aprecio el flujo de trabajo expuesto en el artículo "Un modelo de ramificación de Git exitoso". Me gusta especialmente el uso de objetos de confirmación para fusiones de funciones.

Acabo de notar que git-flow puede usar una combinación --no-ff, y en otras ocasiones puede que no. ¿Por qué es esto? ¿Es por diseño?

¿Tengo que bifurcar git-flow para que funcione con las combinaciones de funciones --no-ff, o hay alguna forma de configurar esto?

Gracias,
Scott

Comentario más útil

Hola vincent

Definitivamente puedo entender el pensamiento detrás de ese diseño, pero creo que la elección de si se debe crear la confirmación de fusión debe depender de si el usuario elige iniciar una rama de función. A veces puedo hacer cambios rápidos en la rama de desarrollo, pero elegiré crear una rama de función _específicamente_ porque quiero ver la combinación de confirmación. Puede que haga solo un compromiso con una rama de función, pero puede que no sea lo que yo, como usuario, considero lo suficientemente insignificante como para justificar ignorar un compromiso de fusión explícito.

En última instancia, creo que la elección debe ser del usuario, y creo que el usuario está expresando una elección diferente al usar una rama de funciones en lugar de hacer un compromiso rápido con la rama de desarrollo.

¡Cualquier sugerencia sobre dónde podría ir en la base del código para hacer este cambio en forma privada sería muy apreciada!

¡Muchas gracias por una gran herramienta!
-Scott

Todos 12 comentarios

Hola Scott,

Por diseño, git-flow usa la opción --no-ff cuando se fusiona para registrar que las confirmaciones pertenecen juntas históricamente. Sin embargo, cuando la rama de características contiene solo una confirmación, la confirmación de fusión adicional no agrega nada y solo complica innecesariamente la rama del árbol. Entonces, para las ramas de confirmación única, las fusiones de avance rápido se realizan como si la confirmación se hiciera en develop directamente.

Salud,
Vincent

Hola vincent

Definitivamente puedo entender el pensamiento detrás de ese diseño, pero creo que la elección de si se debe crear la confirmación de fusión debe depender de si el usuario elige iniciar una rama de función. A veces puedo hacer cambios rápidos en la rama de desarrollo, pero elegiré crear una rama de función _específicamente_ porque quiero ver la combinación de confirmación. Puede que haga solo un compromiso con una rama de función, pero puede que no sea lo que yo, como usuario, considero lo suficientemente insignificante como para justificar ignorar un compromiso de fusión explícito.

En última instancia, creo que la elección debe ser del usuario, y creo que el usuario está expresando una elección diferente al usar una rama de funciones en lugar de hacer un compromiso rápido con la rama de desarrollo.

¡Cualquier sugerencia sobre dónde podría ir en la base del código para hacer este cambio en forma privada sería muy apreciada!

¡Muchas gracias por una gran herramienta!
-Scott

Aquí es donde ocurre la magia: https://github.com/nvie/gitflow/blob/develop/git-flow-feature#L310

No voy a agregar una opción para hacer que las ramas de características de confirmación única se fusionen explícitamente con --no-ff, ya que todavía no creo que agregue nada (aparte de la complejidad agregada de otra marca de línea de comando), pero siéntase libre de convertirlo en un cambio privado si insiste en ello.

Salud,
Vincent

¡Gracias Vincent! ¡Aprecio el puntero!

Mejor,
Scott

Si puedo agregar mis 5 centavos,

Me gustaría mucho tener una opción para tener una combinación de confirmación incluso al terminar una de las funciones de confirmación.

En la forma en que uso git flow, mis funciones incluyen en su nombre el número de ticket en el que estoy trabajando. Cuando termine una función, me gustaría mucho ver la confirmación de fusión especificando el nombre de la función (que incluye el número de ticket).

Esto es útil para rastrear cada confirmación del ticket real sin tener que escribir el número de ticket en cada mensaje de confirmación.

@DonGiulio No sé si ya lo ha comprobado, pero estoy bastante seguro de que la edición AVH hace lo que quiere.

Gracias, no sabía eso, lo comprobaré.

También estoy optando por simplemente agregar una opción para tener un comportamiento de confirmación única no-ff. Sería bueno si pudieras reconsiderar esto.

(No estoy seguro de qué más hay en la edición AVH).

@nvie ¿ Puedo
Honestamente pensé cuando montón de gente cree que se le añade algo y algunos piensan que no agregamos una opción alguna parte o al menos documento para que la gente no tiene que encontrar por ensayo y error. ¡Esta no puede ser una decisión tan importante!

Si el usuario se tomó la molestia de crear una función y eligió realizar una única confirmación en ella, esto significa que necesitaba que fuera de esa manera (por ejemplo, por el bien de mantener el historial visual) y no presionar directamente al desarrollo. . Yo discutiría al revés e ignorar el camino que tomó el usuario no tiene sentido.

¿Estaría interesado en dar más detalles? Deberíamos estar de acuerdo en que es posible que no todo el mundo quiera diversificar un trabajo tan sólido debido a cambios tan pequeños.

@Mehradzie No ha habido un compromiso en este repositorio en 5 años. La edición AVH ha sido la bifurcación de referencia desde hace algún tiempo y es bastante estable. No aguantaría la respiración por una respuesta aquí, mucho menos un cambio de código.

@jawshooah, para ser honesto, ni siquiera verifiqué el nombre del repositorio cuando terminé aquí porque estaba persiguiendo el mismo problema en SourceTree.
¿Es gitflow lo que SourceTree usa para hacer sus flujos? Estoy un poco confundido en este momento: D
Y si es así, ¿puedo cortar y cambiar como sugirió usar el trabajo de otros repositorios en su lugar?

@Mehradzie AFAIK SourceTree incorpora una versión ligeramente modificada de la versión original de nvie. Hay solicitudes pendientes para que se actualicen a la versión AVH (consulte aquí y aquí ).

¿Fue útil esta página
0 / 5 - 0 calificaciones