2011-09-04 18 views
88

Bien. Si estoy en una sucursal (digamos working) y deseo fusionarme en los cambios desde otra rama (digamos master), ejecuto el comando git-merge master mientras estoy en la rama working, y los cambios se fusionan sin volver a basar el historial en absoluto. Si ejecuto git-rebase master, los cambios en master se vuelven a establecer para ponerlos en la parte superior de mi rama working. Pero, ¿qué sucede si deseo fusionarme en los cambios de master pero rebase mis cambios en working para estar en la parte superior? ¿Cómo puedo hacer eso? Se puede hacer?¿Cómo se relacionan los cambios de la rama actual con los cambios que se fusionan?

que podría correr en mi git-rebase workingmaster rama de poner mis cambios en la parte superior en la rama master, pero me gustaría ser capaz de hacer eso en mi working rama, y ​​no tengo ni idea de cómo. Lo más cerca que se me ocurre es crear una nueva rama desde master y luego modificar los cambios de working además de eso, pero luego tendría una nueva rama en lugar de alterar la rama working.

Respuesta

173

Tienes lo que rebase hace hacia atrás. git rebase master hace lo que está pidiendo: toma los cambios en la rama actual (ya que diverge de la maestra) y los reproduce en la parte superior de master, luego establece que la cabeza de la rama actual sea la cabeza de ese nuevo historial. Es no reproducir los cambios desde master en la parte superior de la rama actual.

+0

LOL. Ay. Gracias por corregirme. Justo cuando pensaba que estaba entendiendo todo ... –

+2

@Jonathan es genial. Este es un tema un poco complicado. Por cierto, 'git rebase working' movería los cambios de' master' (después del punto en que 'working' se bifurcó) para estar en la parte superior de la rama' working', pero eso no es algo muy sensato para hacer ' master' :) – hobbs

41

Otra forma de verlo es considerar git rebase master como:

rebase la rama actual en la parte superior demaster

Aquí, 'master' es el aguas arriba rama, y eso explica por qué, durante una rebase, ours and theirs are reversed.

+0

Eso también explica por qué se cambian LOCAL y REMOTO. Gracias. – AVIDeveloper

+0

@AVIDeveloper en LOCAL y REMOTO, también puede leer http://stackoverflow.com/a/3052118/6309 – VonC

+4

@@ VonC: Gracias. Sí, después de pasar una tarde murmurando para mí "REMOTO es mi rama ... LOCAL no es mío", todo se hundió.Honestamente, hubiera preferido ver los nombres de las ramas (o abreviatura SHA) en lugar de REMOTO/LOCAL/los nuestros/ellos/los míos. Mis pensamientos son los mismos con respecto a la horrible izquierda/derecha de 'git difftool'. Un poco fuera de tema, pero para 'difftool' me apego a git-meld y disfruto nombres como 'working-dir', 'stash @ {0}', y así sucesivamente. – AVIDeveloper

3

que acabo de hacer esto hace momentos de la siguiente manera:

  1. copia de seguridad de su trabajo actual en progreso git checkout -b work-in-progress
  2. fetch últimos cambios git fetch origin/master
  3. descartar los cambios locales git reset --hard origin/master
  4. repetición más reciente cambios desde el maestro git rebase origin/master
  5. reproducir su trabajo en progreso git rebase origin/work-in-progress
  6. sincronizar el trabajo en curso con el último maestro git rebase origin/master
+0

Trabajé para actualizar la rama de trabajo actual con el código más reciente. – Dragunov

+0

Esta instrucción es contra intuitiva. ¿Una nueva rama de trabajo en progreso luego un reinicio? ¿Qué tal algo así como: 1. poner su trabajo comprometido en un escondite: 'git stash' 2. ir a buscar cambios más recientes:' git fetch' 3. rebase de la rama que está por delante; en este caso, maestro: 'git rebase origin/master' 4. volver a trabajar en lo que está haciendo:' git stash pop' EDITAR, no se pueden agregar saltos de línea en los comentarios. lol – NathanQ

+0

Quizás sea contradictorio para usted, pero ¿realmente ha leído la pregunta anterior? –

Cuestiones relacionadas