EDITAR:
Mi respuesta a continuación documenta una forma de fusión master
en aq
donde si ver los detalles de la fusión que enumera los cambios realizados en aq
antes de la fusión, no los cambios realizados en master
. Me he dado cuenta de que probablemente eso no sea lo que quieres, ¡incluso si crees que lo es!
Sólo:
git checkout aq
git merge master
está bien.
Sí, esta combinación simple mostrará que los cambios master
se realizaron aq
en ese punto, no al revés; pero eso está bien, ¡ya que eso es lo que sucedió! Más tarde, cuando finalmente fusiona su rama master
, es cuando una fusión finalmente mostrará todos sus cambios realizados master
(que es exactamente lo que desea, y es el compromiso donde la gente esperará encontrar esa información de todos modos).
Lo he verificado y el enfoque a continuación también muestra exactamente los mismos cambios (todos los cambios realizados aq
desde la división original entre aq
y master
) que el enfoque normal anterior, cuando finalmente fusiona todo de nuevo master
. Por lo tanto, creo que su única desventaja real (además de ser demasiado complejo y no estándar ...: - /) es que si revierte los cambios recientes git reset --hard HEAD~<n>
y esto va más allá de la fusión, entonces la versión a continuación retrocede. rama 'incorrecta', que debe arreglar a mano (por ejemplo, con git reflog
& git reset --hard [sha]
).
[Entonces, lo que antes pensaba era que:]
Hay un problema con:
git checkout aq
git merge master
porque los cambios que se muestran en la confirmación de fusión (por ejemplo, si mira ahora o más tarde en Github, Bitbucket o su visor de historial de git local favorito) son los cambios realizados en master, que bien pueden no ser lo que desea.
Por otra parte
git checkout master
git merge aq
muestra los cambios realizados en aq, que probablemente es lo que desea. (¡O, al menos, a menudo es lo que quiero!) ¡Pero la combinación que muestra los cambios correctos está en la rama incorrecta!
¡¿Como hacer frente?!
El proceso completo, que termina con una confirmación de fusión que muestra los cambios realizados en aq (según la segunda fusión anterior), pero con la fusión que afecta a la rama aq, es:
git checkout master
git merge aq
git checkout aq
git merge master
git checkout master
git reset --hard HEAD~1
git checkout aq
Esto: combina aq en master, avanza rápidamente esa misma combinación en aq, lo deshace en master y lo vuelve a poner en aq nuevamente.
Siento que me estoy perdiendo algo, esto parece ser algo que obviamente querrías y algo que es difícil de hacer.
Además, rebase NO es equivalente. Pierde las marcas de tiempo y la identidad de las confirmaciones realizadas en aq, que tampoco es lo que quiero.