2009-10-10 6 views
15

Uso muchas ramas de temas locales en git, y algunas veces termino con dependencias entre ramas de tema que causan problemas de rebase. Por ejemplo, con una estructura como:Rebase de ramas de temas dependientes

master ---> featureA ---> featureB 
        \--> featureC 

If master cambios y consigo (y resolver) los conflictos cuando se rebase featureA, a continuación, después rebase featureB en featureA desencadena los mismos conflictos (y, a veces emocionantes nuevos también) porque intenta volver a aplicar los parches desde la rama featureA. Suponiendo que los parches reales entre featureA y featureB se aplicarían limpiamente si se seleccionan, ¿hay alguna manera de hacer una rebase en esta situación con el mismo efecto que seleccionar todas las confirmaciones entre featureA y featureB?

+0

Vea también [cómo volvería a basar una subhistoria completa - varias ramas, con algunos enlaces entre ellas resultantes de la fusión] (http://stackoverflow.com/a/9706495/94687). La parte desagradable de esa solución es la necesidad de restablecer los refs de rama de tema a los nuevos commit rebasados ​​después. –

Respuesta

17

Después de rebase featureA, puede hacerlo

git rebase --onto featureA oldFeatureA featureB 

asumiendo oldFeatureA representa la confirmación tiene en la punta de featureA antes de que porcentualizada (puede mantenerlos allí otra rama o simplemente recordar el hash comprometerse).

Básicamente, esto debe ser el mismo que elijan el cada confirmación entre A y B en la versión porcentualizada de A.

Documentation on git-rebase (incluye algunas explicaciones pictóricas votos de lo que ocurre durante algunas operaciones más complejas rebase)

+0

Excelente, gracias. Me di cuenta de que --onto parecía que debería hacer el trabajo, pero usar el viejo consejo como base no se me ocurrió. – Kai

+4

En lugar de 'oldFeatureA', debería ser posible usar' featureA @ {1} ', suponiendo que la rebase fue el último cambio en esa branche. De lo contrario, use algo como '@ {2}', '@ {3}', o '@ {una hora atrás}' – Ropez

4

Para el futuro, si trabaja con muchas ramas de temas interdependientes, tal vez debería considerar usar TopGit (README), una herramienta para administrar la cola de parches utilizando ramas de tema Git, un parche por rama; o, alternativamente, una herramienta para gestionar múltiples ramas temáticas.

Véase p. topgit Means Never Having to Wait for Reviews publicaciones en el blog.

+0

¡Gracias por señalar a TopGit! TopGit parece apuntar a lo correcto: mantener ramas interdependientes. ** Pero, ¿tiene TopGit la función de volver a establecer mis ramas de temas interdependientes en un nuevo estado ascendente? ** Si fuera posible, podría utilizar TopGit para desarrollar y preparar mis parches como ramas para una revisión y posible extracción por la corriente ascendente. –

+0

Véase también [Algunos debates sobre un "TopGit basado en la base de la rebase"] (http://git.661346.n2.nabble.com/Branch-dependencies-td6641429.html): "Creo que se necesita un nuevo 'sistema' basado en 'rebase', no basado en fusión como TopGit " –