Gitflow: rama de características con confirmación única fusionada mediante avance rápido

También encontré esto hoy mismo. Ya había un problema planteado y cerrado para esto aquí: https://github.com/nvie/gitflow/issues/100 pero estoy de acuerdo en que no coincide con el modelo de desarrollo. Con suerte, si suficientes personas hacen un escándalo, podemos cambiar algo aquí. (No soy lo suficientemente inteligente como para hacer este cambio en privado).

Empecé a ver ambos temas. Todavía no estoy seguro de cuál prefiero, pero una opción es casi siempre mejor que ninguna opción, ¿no es así?

Se introduce una bandera para esta función en mi fork git-flow (Edición AVH)
Mi bifurcación ha divergido mucho para convertir esto en una solicitud de extracción fácil para gitflow de nvie,

Consulte el registro de

Acordado. Al menos me gustaría ver la lógica detrás de esto.

De acuerdo: el comportamiento no es obvio, especialmente para los nuevos usuarios de git flow.

Una razón para tener esta bandera es un flujo de trabajo que implica un proceso de revisión. Me gustaría poder anotar la solicitud de fusión con un número de ticket, incluso cuando el ticket involucre solo una confirmación. Sí, las confirmaciones de combinación adicionales pueden agregar ruido en general, pero en un flujo de trabajo como este es importante rastrear hasta un ticket, sin tener que editar necesariamente el mensaje de confirmación en sí (ya que es posible que el número de ticket no haya estado allí desde el principio)

He sido muy malo comentando, pero aparte de mi observación original, creo que muchos otros han contribuido con sus casos de uso y han justificado aún más la utilidad.

Tal como están las cosas, lo que me confunde es dónde contribuir con parches y mejoras, con el proyecto original de git-flow aparentemente sin mantenimiento y ninguna de las bifurcaciones ha sido bendecida como sucesora.

Para que conste, creo que la bifurcación 'AVH' incluía algo como este cambio que estaba detrás de una bandera (creo que está deshabilitado de forma predeterminada), pero también tenía un número tardío de varios otros cambios la última vez que verifiqué.

• tarde -> grande

+1 por al menos agregar una opción para permitir que el usuario fuerce --no-ff incluso si la rama contiene solo una confirmación: +1:

Hoy me costaba entender por qué no tenía mi compromiso de fusión y por qué de repente se realizó un avance rápido, tuve que preguntarme qué hice mal, etc., hasta que descubrí que era gitflow el que estaba haciendo esto sin decirme nada. .

Si empiezo una solución rápida que solo requiere una confirmación y explícitamente no quiero una confirmación de fusión y un avance rápido, simplemente me comprometo directamente en mi rama develop . Siempre hice esto. Si creo una rama de características, incluso para una confirmación, eso es para que esa rama se mantenga, no desaparezca mágicamente (debido al avance rápido) cuando me fusiono. Si no quisiera esta rama, me habría comprometido directamente con el desarrollo y no habría creado la rama de características desde el principio.

Al menos, agregue una bandera o una entrada de configuración para permitir que el usuario elija qué comportamiento desea, en lugar de deshabilitar inesperadamente el avance rápido en algunas condiciones (comprensibles pero arbitrarias): guiño:

Mi fork git-flow (Edición AVH) tiene la opción de establecer indicadores como predeterminados, de esa manera siempre puedes hacer un --no-ff sin escribirlo. Consulte la Wiki para obtener más información.

Mi bifurcación ha divergido mucho para convertir esto en una solicitud de extracción fácil para gitflow de nvie,

Consulte el registro de

@petervanderdoes Gracias.

En realidad, para ser justos, no estoy usando la línea de comando gitflow sino la GUI de SourceTree, que parece usar la línea de comando gitflow @nvie internamente. ¿No estoy seguro de si puedo hacer que SourceTree use una versión / ejecutable git-flow alternativa y cómo?

Al cerrar el número 100, @nvie simplemente está equivocado: comenta que "la confirmación de fusión adicional no agrega nada y solo complica la rama del árbol innecesariamente" mientras que, de hecho, el comentario de la fusión es el único registro que queda para las generaciones futuras que denota la hecho de que (a) se creó una rama de característica, y (b) cuál era el nombre de la rama de característica. Sin una fusión explícita, sin avance rápido, el historial del proyecto pierde por completo la información de que la confirmación era una rama, ¡y era una característica, en absoluto!

Sería bueno tener esto abordado

Me sentiría tentado a eliminar la opción explícita --ff del caso de confirmación única. Luego, la configuración de fusión de git incorporada merge.ff = false se puede usar para establecer --no-ff para todas las fusiones (incluidas las de finalización de flujo), con la configuración de git predeterminada replicando el comportamiento actual.

+1

Por lo menos, sería bueno si esta "característica" estuviera documentada.

Cualquier progreso en esto, sé que estoy repitiendo uno anterior, pero no vemos forma de usar el árbol de origen para cerrar una función que no adelanta la fusión. Hay un ajuste en las preferencias, pero no parece respetarlo.

+1

+1

Consulte "¿Este repositorio está inactivo? # 6340".

¡Resulta que puedes usar git sin esto! 😝

No documentado, y no le da una opción de uso.
Este tipo de decisiones deben tomarse por parte del usuario. ¿Por qué no poner una pequeña casilla de verificación en el cuadro de diálogo "Finalizar lanzamiento" y si realmente eres un gran admirador de esta función, dejar que esté marcada de forma predeterminada, pero como no lo soy, puedo desmarcarla, verdad?

Cada nueva versión, esto es lo primero que reviso: D y nunca está allí: /

Acabo de descubrir que también hay una casilla de verificación para esto en las preferencias. Por lo tanto, no es necesario verificarlo para cada combinación de ramas.