2012-06-01 11 views
35

Tengo un árbol como este:cambio de base rama

(commit 1) - master 
       \-- (commit 2) - (commit 3) - demo 
               \-- (commit 4) - (commit 5) - PRO 

y tengo que mover la rama PRO para dominar

(commit 1) - master 
       |-- (commit 2) - (commit 3) - demo 
       \-- (commit 4) - (commit 5) - PRO 

He intentado un git rebase master de rama PRO, pero nada sucede.

Para aclarar: Estaba trabajando en master y luego tuve que hacer una demostración del producto (git checkout -b demo y algunas confirmaciones). Luego, por error, creo otra rama de la demo (git checkout -b PRO y algunas confirmaciones) y ahora necesito mover la rama PRO a la maestra y dejar la demostración intacta. Al final, tanto la demostración como PRO se bloqueará desde el maestro.

+0

posible duplicado de [Cambiar punto de ramificación] (http://stackoverflow.com/questions/8803069/change-branch-off-point) –

Respuesta

60
git checkout PRO # Just to be clear which branch to be on. 
git rebase --onto master demo PRO 

Básicamente, se toman todas las confirmaciones de demo después hasta PRO, y ellos rebase en el master confirmación.

+0

¿Es ese también el camino a seguir si la situación es la contraria? == Pagué -b desde maestro la segunda rama, pero quería hacerlo desde la primera. Así que hice 'git rebase --onto first-branch second-branch second-branch' pero no obtengo la sintaxis – Fla

+0

@Fla en ese caso, sería' git rebase --onto first-branch master second-branch ' – nVitius

5

Pedido a PRO rama, Copia el más antiguo (commit4) y la última (commit5) comprometerse hashes de esta rama y pegar en otro lugar.

$ git checkout PRO 
$ git log   # see the commit history 
# copy the oldest & latest commit-hash 

A continuación, elimine la rama PRO (guarde una copia de seguridad sólo para la seguridad). Crear y pagar en una nueva sucursal PRO desde master.

$ git branch PRO.bac  # create a new branch PRO.bac = PRO as backup 

$ git checkout master 
$ git branch -D PRO   # delete the local PRO branch 
$ git checkout -b PRO  # create and checkout to a new 'PRO' branch from 'master' 

Take (cereza recoger) el rango de confirmaciones de Anterior PRO rama en rama nueva PRO.

$ git cherry-pick commit4^..commit5 # cherry-pick range of commits 
# note the '^' after commit4 

Ahora, si todo está bien, y luego hacer fuerza (f) de empuje a remote PRO rama y eliminar PRO.bac sucursal local.

$ git log     # check the commit history 

$ git push -f origin HEAD # replace the remote PRO by local PRO branch history 
# git branch -D PRO.bac # delete local PRO.bac branch 
0

que tenían un enfoque ligeramente diferente utilizando reset y alijos que evita borrar y volver a crear ramas, así como la eliminación de la necesidad de cambiar ramas:

$ git checkout PRO 
$ git reset commit4 # This will set PROs HEAD to be at commit 4, and leave the modified commit 5 files in ur working index 
$ git stash save -m "Commit message" 
$ git reset commit 3 
$ git stash save -m "Commit message" 
$ git reset master --hard 
$ git stash pop 
$ git stash pop 
$ git push --force # force if its already been push remotely 

Por reseting la rama en una confirmación por Comprométase básicamente con rebobinar el historial de las ramificaciones de un compromiso a la vez.

0

Voy a tratar de ser tan genérico como puedo be.First estar seguro de que usted está en su rama actual.

git checkout current-branch 

A continuación, utilice el siguiente comando. new-base-branch es la rama que desea que sea su nueva base. current-base-branch es la sucursal es su base actual.

git rebase --onto new-base-branch current-base-branch 

Si no tiene conflictos, entonces genial. Estás listo. Si lo hace (en la mayoría de los casos), entonces por favor siga leyendo ..

pueden surgir conflictos, y que tendrá que resolver de forma manual.Git ahora intenta una "combinación de 3 vías" entre current-branch, current-base-branch y new-base-branch. A grandes rasgos, así es como git funcionará internamente: -

1.) Primero, Git volverá a establecer el current-base-branch en la parte superior del new-base-branch. Puede haber conflictos; que tendrás que resolver manualmente Una vez hecho esto, generalmente hace git add . y git rebase --continue. Creará una nueva confirmación temporal temp-commit-hash para esto.

2.) Después de esto, Git ahora rebase su current-branch en la parte superior de temp-commit-hash. Puede haber más conflictos y nuevamente tendrá que resolverlos manualmente. Una vez hecho esto, continúa de nuevo con git add . y git rebase --continue, después de lo cual ha vuelto a establecer correctamente su current-branch en la parte superior del new-base-branch.

NOTA: - Si comienza a hacer un desastre, puede hacer git rebase --abort en cualquier momento durante el proceso de rebase y volver al punto de partida.

Cuestiones relacionadas