Cambiar raíz de una rama en git

Question

Estoy usando git y quiero cambiar la base de una rama que sale. Esto es causado por un sistema de implementación, que extrae esta rama explícita en mi entorno de producción. Al planear mis lanzamientos, creo una etiqueta cada vez que quiero entrar en funcionamiento. Pero mi rama también tiene cambios especiales, por lo que git reset --hard v1.0 no funcionará.

Aquí un pequeño ejemplo. Quiero que este

 C---D---E deploy 
    /
A---B---F---G master 
    \ 
     v1.0 

para convertirse en este

      C---D---E deploy 
         /
A---B---F---G---H---I---J---K master 
    \     \ 
     v1.0    v1.1 

Tal git rebase es lo que estoy buscando, pero las páginas man no me ayudas. ¡Gracias por tus respuestas!

Answer 1

git rebase debe, como usted dice, permitirá cambiar la base del despliegue:

git checkout deploy 
git rebase v1.1 # using the tag 
(or: 
git rebase J # SHA1 of J 
or 
git rebase master~1 
) 

Pero el resultado final será con

C'---D'---E' deploy 

Es decir, el SHA1 de la parte confirmaciones de deploy branch se reescriben, lo cual no es tan malo si nadie clonó dicha rama deploy y estaba trabajando en ella.
Dado que es una rama para el despliegue, es muy probable que así sea (es decir, nadie estaba trabajando en un clon de dicha rama).

Answer 2

No entiendo por qué querría perder su rama original. Lo que haría en tal caso:

# create a new branch from your 1.1 tag 
git checkout -b deploy1.1 v1.1 
# merge your existing branch into this one 
git merge deploy 

EDITAR: esquema

añadido Usted va a terminar con algo así

 C---D---E deploy 
    /  \_______ 
    /    F deploy1.1 
    /    /
A---B---F---G--H--I--J--K--L 
    \     \ 
    v1.0     V1.1 

Answer 3

git rebase debe trabajar para usted:

git checkout deploy 
git rebase master~1 

o

git rebase v1.1 

Tener un vistazo a http://progit.org/book/ch3-6.html - debería ayudar a entender mejor rebase Creo

Answer 4

sí, se puede utilizar rebase para lograr el efecto deseado. con el siguiente comando checkout de la rama deploy y reproducir todos sus commits, que no son accesibles a través v1.1, en la parte superior de v1.1:

git rebase v1.1 deploy 

(la forma prolija sería: git rebase --onto v1.1 v1.0 deploy)

pero ¿por qué cambio de base y ¿alterando la historia?sólo tiene que cambiar la línea principal de desarrollo en la implementación de la sucursal:

git checkout deploy 
git merge v1.1 

esto dejará todas sus cometer hashes intacta, su historia será el siguiente aspecto (M ser la combinación de cometer):

 C---D---E-----------M deploy 
    /    /
A---B---F---G---H---I---J---K master 
    \     \ 
     v1.0    v1.1 

dado que los conflictos pueden surgir durante la rebase, así como durante la fusión, tendrá un historial de conflictos de combinación al usar el enfoque basado en fusión. con rebase no tienes un historial de conflictos que ocurrieron durante la operación de rebase. utilizando un flujo de trabajo basado en fusión, luego puede ver sus conflictos en la diferencia (combinada) de las asignaciones de fusión.