Git rebase contra una twig de lanzamiento para cosas como revisiones y parches

En el trabajo, utilizamos una twig de develop para el trabajo diario: nuevas funciones, correcciones de errores, etc. Cuando estemos listos para lanzar, fusionamos la twig devleop en master, tag y release.

Si necesitamos hacer una revisión que debe ser liberada inmediatamente, creamos una twig de master , aplicamos cambios y nos fusionamos en consecuencia (incluida la fusión del master nuevo en develop ). No hay problemas con lo que he descrito hasta ahora.

Hace poco estuve trabajando en una pequeña corrección de errores que debía includese en el próximo lanzamiento. Así que creé mi twig habitual de develop , hice algunos commits y envié un PR. Entonces, un administrador quería la solución hoy como una revisión. OK – simple, voy a volver a basar mi trabajo contra el master y abrir el PR contra el maestro. Sin embargo, al ejecutar git rebase master no git rebase master jugar mi trabajo contra el actual HEAD commit en master. En cambio, git me dijo que todo estaba "actualizado". Luego abrí el RP contra master, y mi RP contenía todo el trabajo nuevo de la twig de develop , no solo mi corrección de errores.

Pude hacer una rebase interactiva y soltar todas las confirmaciones que no deberían haber estado allí, pero esto parece tedioso y propenso a errores. ¿Existe alguna forma más sensata de lograr este objective de reajustes en contra de una twig más antigua pero actualizada ?

En lugar de volver a basar "contra el master " (es decir, "con el master como el ascendente" según el command que utilizó), necesitó volver a establecer la base de su trabajo --onto master con el set ascendente para develop .

 git rebase --onto master develop my_fix 

Tenga en count que esto crea un estado de código nuevo y no probado; como las soluciones rápidas se rastrean rápidamente para la producción, se requiere un ojo especial para probarlo.