git sincronización de ramas rebasadas

Question

Recientemente tuve un question answered sobre una configuración de desarrollo git multi-computadora, y la solución que obtuve allí resolvió mi situación con la rama master, pero no ramas laterales basadas en el maestro.

Aquí está mi configuración actual:

A--B--C--D master 
      \ 
      E--F--G--H BUG_37 

BUG_37 es una rama que se está desarrollando una solución a un error de orugas opcional para una solicitud de función en el sistema, y ​​eventualmente se fusionarán en la línea principal, pero es separarse por el momento. Con el repositorio en este estado, una sola máquina, he hecho algunos cambios en el master rama:

A--B--C--D--I--J--K master 
      \ 
      E--F--G--H BUG_37 

entonces porcentualizada la rama BUG_37 en master, para asegurarse de que está funcionando como una mejora de los cambios más actuales:

A--B--C--D--I--J--K master 
        \ 
        E1--F1--G1--H1 BUG_37 

Digamos que rebase tenía algunos conflictos que debían corregirse manualmente antes de que la rebase fuera definitiva. Si envío esos cambios a un repositorio remoto y ahora deseo hacer cambios en otro sistema de desarrollo que todavía tiene la configuración original, ¿cuál es la mejor manera de hacerlo? git pull --rebase volverá a ejecutar la rebase, y tendré que pasar manualmente por los conflictos que tuve la primera vez, ¿verdad? Y si cometo un pequeño error al volver a enfrentar los conflictos, de modo que E1-H1 sea ligeramente diferente en este nuevo sistema, tendré aún más fuera de sincronización el repositorio.

Cómo tomo un repositorio local en el estado original y el repositorio remoto en el tercer estado, y hago que el repositorio local se actualice para coincidir exactamente con el repositorio remoto (los cambios trashed EH y mover el HEAD de BUG_37 a la nueva ubicación)?

Answer 1

no habría rebase en absoluto en una rama que ya está compartida. Si bien da como resultado la historia más limpia, habrá cambiado los valores hash de todos los commits en BUG_37. Por lo tanto, en las máquinas de destino, deberá eliminar BUG_37 por completo y volver a extraerlo. Esto está bien hacer una o dos veces pero no tan bien como un flujo de trabajo normal.

Será mucho más fácil combinar master en BUG_37; luego, la combinación de fusión (donde se arreglaron los conflictos) puede enviarse a otras máquinas y no será necesario eliminar las ramas.

Answer 2

Elimine la rama, luego extraiga ambas ramas del repositorio remoto.

git branch -D BUG_37 
git pull origin master 
git pull origin BUG_37:BUG_37 

Si no quiere eliminar su sucursal local BUG_37 antes de estar seguros de que esto funciona, tire de la rama remota en otra rama local:

git pull origin BUG_37:NEW_BUG_37 

Answer 3

Estoy siguiendo el mismo flujo de trabajo, básicamente pasando de una computadora portátil a una de escritorio. Mantengo mi repositorio principal en el escritorio y la computadora portátil clona el repositorio del deskotp. Eventualmente se desincronizan, porque quiero volver a ordenar mis ramas de tema después de actualizar master.

La respuesta simple es simplemente no usar git, en su lugar use rsync para mantener sus repos sincronizados. Si sabes que eres el único que está trabajando en ello, entonces tiene sentido.

Bueno, tampoco soy un gran admirador de esa solución. Entonces, esto podría ser un poco "más limpio".En la computadora portátil, al tirar ramas porcentualizada de cesión temporal del escritorio:

git co topic 
git fetch origin/topic 
git reset --hard origin/topic 

Esto tirará alguno no se compromete en el repositorio de escritorio, así que asegúrese de que realmente quiere hacer esto.

Además, es probable que sólo puede git pullmaster rama del portátil, ya que siempre debe ser un avance rápido, porque es probable que no tenga que reajustar la misma. Creo que tiene sentido reubicar las ramas temáticas, porque de lo contrario, tratar de fusionarlo de nuevo en el maestro al final es un problema.

Answer 4

Acabo de experimentar con él y usando git pull --rebase funciona cuando se tira de una rama rebasada. Sin el indicador --rebase, las confirmaciones se duplicarán, pero con --rebase las confirmaciones no se duplicarán.