git - origin - ¿Cómo reajustar una rama de una rama rebasada?

git pull origin master

Question

Así que mi historia se ve así:

o---o---o---o master / o---o---o A / o B

Entonces, para explicar:

• Tengo la rama A que se inició desde el master
• Tengo la rama B (con solo 1 confirmación) que se inició desde A

Lo que quiero es esto:

o---o---o---o master / o---o---o A / o B

Lo que hice fue:

1).

git checkout A git rebase master

Esto dio lugar a muchos conflictos que, después de un tiempo significativo dedicado a la reparación, surgió la siguiente historia:

o---o---o---o master / o---o---o A

Que es exactamente lo que quería.

(No sé dónde está B este momento)

2).

Después de esto, realicé muchos squash y cambié el orden de las confirmaciones en A , para hacer que la historia se vea como quiero.

3).

Ahora, lo que también quiero hacer es:

git checkout B git rebase A

Sin embargo, esto no parece funcionar y no sé por qué. Si hago git log , veo las confirmaciones que estaban allí antes de hacer el paso 1.

Además, tengo la misma cantidad de conflictos que ya resolví en el paso 1. Pasé mucho tiempo haciéndolo, no quiero volver a hacerlo.

Este ejemplo sugirió usar --onto , lo que hice:

git checkout B git rebase --onto A

Pero esto elimina la confirmación en B completo y hace que A y B apunten a la misma confirmación, es decir, la última en A

Mi pregunta es: ¿Cómo puedo rebase B de A para que parezca que B comenzó desde A ? (que en realidad era cierto al principio).

Mi mejor conjetura es que estoy usando --onto mal. O que debería usar otra cosa (como la cherry-pick ).

Answer 1

Respuesta corta a ¿Cómo puedo cambiar la base de B de A para que parezca que B comenzó desde A? _{Suponiendo que desea mover exactamente un compromiso:}

git rebase --onto A B~ B

_{Si quieres mover más de un uso de commit:}

git rebase --onto A old_A B

El resto de la respuesta.

Su rama de B sigue existiendo (puede comprobarlo), pero su elemento principal sigue siendo el objeto de confirmación exacto que A tenía antes.
Para ver una representación gráfica de este uso:

git log --graph --decorate --all

Para ver todas las ramas y dónde están uno respecto al otro.

Lo que originalmente tenías:

o---o---o---o  master
     /
      o---o---o  A
               /
                o B

Lo que tienes ahora:

o---o---o-----------o  master
     /               /
      o---o---o(B~)   o---o---o A
               /
                o B

En términos de uso de --onto , debe tener un punto de partida y un punto de finalización. utilizar:

git rebase --onto [target] [rebasing stops] [rebasing head]
git rebase --onto A B~ B

Y lo que obtienes:

o---o---o----------o  master
     /              /
      o---o---o      o---o---o A
            (old_A)           /
                               o B

[branch_name]~ indica la confirmación principal de la rama.

La B~ es la rama que no quieres cambiar. (Sucede que es la antigua A )

Alternativamente, si B era la única confirmación que tenía A como padre (es decir, B es el final de una cadena de confirmaciones que se derivan del maestro), podría hacer

git checkout B
git rebase master
git checkout B~   # this is the commit before B (the A commit)
git branch -d A   # remove the old A branch (it was rebased, and so is now invalid
git branch A      # recreate the A branch on the commit that is based on the original A

Answer 2

Si ya ha vuelto a basar A. Debería darse el caso de que B esté exactamente donde lo dejó. La rama (un puntero) que era A simplemente se ha movido a su nueva ubicación.

Lo que recomendaría para cambiar de forma efectiva B a A es, como sugirió, usar ''cherry-pick''. Este comando intenta aplicar los cambios realizados en una confirmación a la rama en la que lo ejecuta.

Entonces, si las ID de confirmación de la confirmación a la que B apuntó originalmente eran ''123456'', entonces recomendaría mover su ''B'' actual al mismo lugar que la nueva ''A'' con git branch -f BA luego ejecutar git cherry-pick 123456 que aplicará los cambios sobre A.

Creo que la bandera --onto se usa para establecer la ubicación de destino desde la que se aplican los confirm.It está por defecto en "upstream" (fuente: http://git-scm.com/docs/git-rebase ).

La forma en que me gusta pensar en el comando rebase es la siguiente:

git rebase --onto <Starting here> <Apply all commits from HERE> <TO HERE>

Usando esto, probablemente habría sido más sencillo cambiar de base B al maestro, luego apuntar A a la confirmación que precede a B.

git rebase master B

(como el punto de inicio (--onto) es implícitamente ''maestro'')

luego, para usar git branch -f AB^ (el ^ significa ''el padre de'')

Answer 3

Tengo el mismo problema con mi flujo de git, y encontré una manera mejor y más rápida de hacerlo.

(1) Historia del proyecto al principio:

    master ---A---B---C
                /
                 D---E---F feature1
                          /
                           G---H feature2

(2) Rebase feature1 en maestro y fuerza empujada:

    master ---A---B------------------------C
                /                           /
                 D---E---F feature1(old)     D---E---F feature1
                          /
                           G---H feature2

(3) Rebase feature2 en featrue1 (la nueva)

    master ---A---B---C
                       /
                        D---E---F feature1
                                 /
                                  G---H feature2

La parte más confusa es cómo hacerlo (3) .. pero nadie tiene una respuesta clara de hacerlo.

Creo que muchas personas se encontraron con el mismo problema que yo, cuando intentábamos hacer "rebase --onto", ¡encontramos que feature1 (antiguo) en realidad no existe!

    git rebase --onto feature1 feature1(old) feature2

La solución es utilizar a continuación en su lugar:

    git rebase --onto feature1 feature1@{1} feature2

La sintaxis feature1 @ {1} significa "el último estado conocido de feature1 antes del rebase", la respuesta se remite desde https://coderwall.com/p/xzsr9g/rebasing-dependent-branches-with-git