GIT: ¿Cómo sobrescribir la twig QA con Master, preservando el historial de la twig QA?

Mi objective es que, en algún momento, MASTER (digamos 6.4.3) sea promovido (todo el material vaya a una twig QA) a QA, y durante este process, agregue cuatro dígitos a la versión del proyecto y lo construya. Entonces, QA avanza, produciendo 6.4.3.1.

De esta manera, puedo realizar revisiones en la twig QA e integrarlas de nuevo al control de calidad (y maestro, cuando sea necesario). Esto generará una nueva revisión en la twig QA, y compilation digamos 6.4.3.2.

Pero, el time pasa, y las adiciones fueron hechas para dominar, y ahora el maestro es 6.4.9.

Entonces, necesito promocionarlo de nuevo a QA, y esto debe generar el package 6.4.9.1. PERO todos los cambios de control de calidad deben ser sobrescritos por material maestro, y no fusionados. Todos los cambios fueron relevantes solo para 6.4.3.x

Todos los bashs que hice resultaron en operaciones combinadas en pom.xml. Intenté fusionar y rebase, y también estrategias como la nuestra y la suya sin suerte.

Lo que realmente necesito es una forma no fea de ir a la twig maestra, copyr -R todo en la carpeta a / tmp, y volver a la twig QA, cp -R de la carpeta / tmp, y ejecutar un git add. Entonces, los files más nuevos naturalmente sobrescribirán los viejos.

Al hacer esto, terminaré con todos los cambios de la sobrescritura maestra de los antiguos cambios de control de calidad, que ya no necesito, pero aún quiero tenerlos en el historial.

Tks Marco

AÑADIDO 2014-08-27:

pom.xml en el maestro:

<version>1.2.4</version> <dependency>[6.0.0,)</dependency> 

pom.xml en qa:

 <version>1.2.3.1</version> <dependency>6.0.3</dependency> 

Después del process, necesito, en QA:

 <version>1.2.4.1</version> <dependency>6.0.5</dependency> 

El script para generar 1.2.4.1 está funcionando, y las versiones de mvn: resolve-ranges también están funcionando. Es por eso que no puedo trabajar con files ya modificados en QA. Necesitan ser reemplazados con cambios maestros actuales, por lo que puedo hacer los cambios necesarios en él.

No lo hagas Use fusiones, consulte: http://nvie.com/posts/a-successful-git-branching-model/ . Si desea un cambio en QA, pero no lo vuelva a poner en master, podría fusionarlo y luego revertirlo. Hace la historia más clara.

Pero si realmente lo deseas, usa git merge -s ours master en la twig qa.

 git checkout master git merge -s ours origin/qa #discards all qa changes † vi pom.xml #(I manually edited to make it 1.2.4.1) git add . git commit . -m "1.2.4.1" # make sure it works, passes all tests, etc and ready to go for QA. git push origin master:qa #yes, you don't even need to flip branches locally vi pom.xml #(new release, 1.2.5) git add . git commit . -m "1.2.5" # continue master development. 

† En realidad, no debería descartar cambios qa, ya que podrían ser revisiones / correcciones de errores probadas y aceptadas por QA y, por supuesto, deberían fusionarse de nuevo a master, de lo contrario, los mismos errores aparecerán en el siguiente control de calidad, no agradable. Entonces normalmente no deberías usar -s ours .

Exactamente lo mismo pero más difícil y el gráfico de historia se ve peor, sin embargo se ve como "a tu manera":

 git checkout master git merge -s ours qa #discards all qa changes git checkout qa git merge master # it does fast-forward in fact vi pom.xml #(I manually edited to make it 1.2.4.1) git add . git commit . -m "1.2.4.1" # committing into `qa` branch # make sure it works, passes all tests, etc and ready to go for QA. git checkout master vi pom.xml #(new release, 1.2.5) git add . git commit . -m "1.2.5" # committing into `master` # continue master development. 

Primero, revisa la twig QA. Luego, ejecute git read-tree -um commit . Esto efectivamente "reiniciará" su tree de trabajo a la confirmación dada sin mover ningún puntero de bifurcación ni verificar ningún compromiso. Después de esto, puede ejecutar git commit para confirmar estos cambios en la twig QA.

Más información: git-read-tree (1) Página manual

Esta es la solución final que obtuve, que cumplió a la perfección mis necesidades, fusionando ambas soluciones presentadas. Muchas gracias.

Final git lola:

 * 782db24 (HEAD, master) 1.2.5 | * d2572c8 (qa) 1.2.4.1 | * 12d4348 Merge branch 'master' into qa | |\ | |/ |/| * | 1884a7c release 1.2.4 

Comandos:

 git checkout qa git merge -s ours master #(will store this on history, w/o conflicts) git read-tree -um master #(will replace current merged files with master) vi pom.xml #(I manually edited to make it 1.2.4.1) git add . git commit . -m "1.2.4.1" git checkout master vi pom.xml #(new release, 1.2.5) git add . git commit . -m "1.2.5" 

Gracias a los dos.