En Git, ¿cómo aplicas un commit de corrección de errores a las otras twigs más nuevas?

Si tengo un repository público de Git que contiene 3 twigs como las siguientes:

(release-to-customerA) | U (master) / | A---B---C---D---E ... S---T | (release-to-customerB) 

donde commit 'B' era la versión de lanzamiento original y commit 'U' resolvió algunos errores en 'B'. Deseo aplicar la confirmación 'U' a la twig principal y a la versión release-to-customerB , y cuando la próxima vez entregue una nueva versión a los clientes basada en la confirmación 'D', 'E', … 'T ', Quiero el compromiso' U 'incluido. ¿Cuál es la forma más limpia de hacerlo?

Sé que git rebase o git cherry-pick pueden hacer el truco en mi repository local, pero ¿voy a arruinar el historial cuando envíe el trabajo reubicado al repository público?

Gracias por las respuestas.

Aunque el trabajo de recolección de cerezas funcionará, no estoy seguro de por qué querrías. Crea confirmaciones duplicadas, que pueden causar problemas si alguna vez desea fusionarse. De hecho, este parece ser un caso en el que desea fusionarse.

  (bugfixB, releaseA) --------------------- Y (master) / / U---X (releaseB) / / / / A---B---C---D---E ... S---T 

Tenga en count que agregué un nombre de twig bugfixB – esta es una idea muy general. La confirmación U debe realizarse en una twig cuyo propósito es reparar B (podrían ser varias confirmaciones). Esa twig se debe fusionar en todas las twigs que necesitan la corrección de errores, en este caso, releaseA, releaseB y master.

  git checkout -b bugfixB <SHA1 of B> # fix things, add changes git commit # for each branch... git checkout releaseA git merge bugfixB git checkout releaseB git merge bugfixB git checkout master git merge bugfixB 

No deberías rebasear en esta situación, ya que claramente otras personas han visto cometer C a través de T.

Como dijo Greg, puedes usar git-cherry-pick para get solo U; pero, esto creará un nuevo commit con el mismo diff pero una ID diferente. Si desea get todas las confirmaciones en release-to-customerA en release-to-customerB y master, puede usar git-merge manera:

 git checkout release-to-customerB git merge release-to-customerA git checkout master git merge release-to-customerA 

No es necesario cambiar la base para esta operación en particular, la recolección de cerezas está bien:

 git checkout release-to-customerB git cherry-pick U git checkout master git cherry-pick U 

La selección de cerezas solo crea nuevas confirmaciones y no reescribe el historial, por lo que siempre es seguro, incluso si luego ingresas a otro repository.