¿Cuál es la mejor práctica para actualizar twigs de características a una nueva base?

Uso gitflow y tengo una pregunta sobre las mejores prácticas cuando se ramifican haciendo twigs de características. Si tengo una twig principal desarrollada y dos twigs características, una ramificada en el time t2 y la otra ramificada en t3, ¿qué se debe hacer si ambas twigs de características no están lists para fusionarse y necesitan algo nuevo de la twig de desarrollo o de la otra característica? ¿twig? ¿Hay alguna manera de actualizar la "base" de la característica 1 desde el desarrollo en t2 hasta una nueva "base" de desarrollo en t3 cuando se ha hecho algo nuevo con el desarrollo? Y de manera similar para la twig de características 2, cuando no está list para la fusión, ¿puede actualizarse con nuevos cambios desde la twig de desarrollo antes de fusionarla?

feature 1 (branch) / / ----- develop ----/-----\--------------------------- \ \ feature 2 (branch) t1 t2 t3 t4 

¿Pueden las twigs de alguna manera "avanzar" para que los nuevos cambios en la twig de desarrollo se incluyan con las twigs de características o es necesario que nos fusionemos primero?

Quiero complementar las dos respuestas existentes: en lugar de fusionar el develop en las twigs de feature , también podría volver a establecer una base de cada twig de feature en la twig de develop actualizada:

 git checkout feature git rebase develop 

Ventajas:

  1. El historial se vuelve algo más claro, ya que evita confusiones de fusiones como Merge branch develop to feature , lo que puede ser confuso cuando más tarde se fusiona la feature en develop .
  2. Además, puede cambiar fácilmente las confirmaciones en su twig de feature (por ejemplo, si desea corregir un error tipográfico en un post de confirmación) sin cambiar las confirmaciones que ya están en la twig de develop . Si se fusiona se develop en feature , esto ya no es posible, porque las twigs divergirán y ya no podrá fusionar la feature en el develop .

Así que este enfoque es un poco más de trabajo (rebase en lugar de fusión), pero también trae algunas ventajas (menores).

Si bien podrías moverlos hacia adelante con una rebase, me fusionaría para desarrollar las twigs de características. Cuando trabajo en una twig de características, me fusiono regularmente para desarrollarlo de todos modos, para evitar conflictos de fusión enormes cuando finalmente fusiono la twig de características de nuevo en desarrollo.

Puede fusionar el punto de la twig de develop que desee en la feature .

Si solo quieres compromisos específicos, puedes usar git cherry-pick para aplicar los cambios de esos commits a tu sucursal.