¿Cuál es la mejor manera de administrar versiones paralelas en Git?

Question

Tengo un conjunto de herramientas de software bien establecido, pero que a menudo necesita pequeños retoques (principalmente para hacer frente a problemas de compatibilidad de productos de terceros). Ahora deseo producir una versión "nueva" (API mejorada), que se basará en el original; esto divergerá de la rama existente en el tiempo, pero durante algunos años, tendré que mantener el "en vivo" original para clientes existentes que lo necesitan para compatibilidad. Por supuesto, yo también necesito asegurarme de que los "ajustes" se apliquen también a la versión "nueva", ya que tales problemas (en la mayoría de los casos) también se aplican a la "nueva" versión.

Por lo tanto - mi ideal (simple) de flujo de trabajo sería:

1. Cuando se trabaja en la "nueva" versión - cambios sólo se aplican a esa versión .
2. Cuando trabaje en la versión "anterior", todos los cambios resultantes (¡lo más automáticamente posible!) Se aplicarán a ambas versiones una vez que estoy satisfecho con ellos (cuando confirmo, envío o lo que sea).

Me doy cuenta de que habrá una necesidad de intervención manual ocasional, donde las fusiones son conflictivas, pero esperaría que eso fuera raro, basado en la experiencia de cambios manuales en el pasado.

Por el momento, estoy buscando abandonar VSS (sí, ¡sigue riéndome de tanto que lo sigo haciendo!), Y esperaba que Git lo hiciera fácil, pero hasta ahora, no aparece a cualquier solución "simple", con las sugerencias que he visto que se construyen alrededor de "rebase", lo que me parece "incorrecto", ya que rebase parece hacer muchas otras cosas como reescribir el historial, cuando todo lo que necesito sea una simple y genuino "avance" basado en los cambios de la otra rama.

• ¿Echo a perder algo aquí?
• ¿Existe una manera más fácil y bien definida de hacer esto?
• ¿Sería mejor con un sistema de control de fuente diferente en lugar de Git?

Todos los pensamientos muy apreciados!

Answer 1

Podría fusionar los cambios de su antigua rama a la nueva versión.

Déjame detallar en rebase: A menos que seas el único desarrollador que trabaja en la base de código, no recomendaría que uses rebase para este problema en particular. Recuerde que rebase se recomienda para su uso con ramas privadas solo desde su historial de reescritura y, por lo tanto, invalida cualquier confirmación que tenga un compromiso rebasado como antecesor.

Si cambia los cambios de la versión anterior a su nueva versión, continuará reescribiendo el historial de la nueva versión-bifurcación cada vez que necesite realizar cambios de la versión anterior a la nueva versión. Esto significa que cualquier trabajo que se haya realizado con una base en la nueva versión, por ejemplo, una rama de características para una característica exclusiva de la nueva versión, se perderá debido a que la confirmación original ya no existe.

Answer 2

Eche un vistazo a Git flow - un enfoque de ramificación para este tipo de características con herramientas para soportarlo.Básicamente, para cada nuevo 'tweak', lo haces en una nueva rama enraizada en/ante el ancestro común de las ramas que estás manteniendo, y luego fusionas eso con cada una de ellas.