formato de parche funciona razonablemente bien, en busca de una mejor manera

Question

Tengo dos ramas que son lo suficientemente diferentes que rebase parece no funcionar - o no sé cómo hacerlo

.

Tengo una rama "público" con un montón de archivos eliminados (usando filter-branch). A pesar de que la mayor parte de las confirmaciones coinciden en términos de los deltas, la confirmación ID son todos diferentes. He probado un buen número de métodos para extraer los cambios de mi rama dev a mi sucursal pública ... Me resulta difícil de creer que puede hacer lo que yo quiero que haga - pero sospecho que no sé cómo hazlo. En cualquier caso, esto funciona bien, pero parece mal.

git checkout dev
git format-patch --stdout last_sync_tag > catchup.mbox
git checkout public
git am catchup.mbox
git --skip # talks about a missing file
git --skip # talks about a missing file
git --skip # talks about a missing file

Cualquier consejo o sugerencias, que probablemente incluirá No filtrar-ramifican hacia fuera archivos que no desea en la rama pública (aunque, ¿cómo entonces deshacerse de ellos?), Son bienvenidos.

Mi árbol (s) se ven más o menos así:

dev: a-b-c-d-e-f-g-h-i-j-k
pub: t-u-v-w-x

t ≅ a, u ≅ c, v ≅ d, w ≅ e, x ≅ g. i, j, k son nuevos parches que me gustaría pasar más.

checkout pub
rebase --onto pub i  # I really expected this to work

Answer 1

cherry-pick puede ser útil. Yo no lo he utilizado en su situación, pero creo que debería funcionar. La única pena es que no está diseñado para trabajar en un rango de confirmaciones por lo que si desea script / automatizarlo que tendría que utilizar algo como git rev-list.

Una vez más, no he probado esto, pero un script bash como esto puede darle un punto de partida bueno

git checkout public
for rev in $(git rev-list --reverse last_sync_tag..dev) ; do
   git cherry-pick $rev && git tag -f last_sync_tag $rev || exit 1
done

Answer 2

¿Mantiene regularmente los archivos de su rama dev que no están en público? ¿O son simplemente dando vueltas?

Si no tiende a realizar cambios en ellos, y estás bien con la reescritura de la historia un poco, lo que podría hacer es hacer arreglos para que los creó como una sola comprometerse con base en su rama pública; y combinar que de nuevo en público, pero con "-s nuestro" para que dejen de hecho entrar. ( respuesta anterior acerca de la combinación git -s nuestro )

Algo así como:

git checkout -b dev public
git am create-dev-only-files.patch
git checkout public
git merge -s ours dev
git checkout dev
# write more dev patches...
git checkout public
git merge dev
# and this should merge in the patches without bringing in the
#  dev-only files

Así que si a continuación, realizó cambios posteriores en su rama dev y los combinó en público, si no va a modificar esos archivos que no están en público, todo lo demás simplemente aplicar. Pero si el conjunto de archivos que desea suprimir el público cambia, esto podría ser complicado. Se podría tratar de evitar que mediante la adición de un gancho pre-commit a unstage archivos en particular antes de comenzar cualquier cometen en la rama pública, por ejemplo.

Answer 3

Debido a que usted ha utilizado "filter-branch" Vas a tener que ayudar a encontrar el correcto git commit para realizar el rebase a.

Voy a adivinar aquí, pero se supone que tienes que cometer un 'casi' común, que tiene dos versiones, la cabecera de la rama pública y el lugar de su rama dev que esto corresponde a cometer (a filtrar ONU). Llame a la cabeza del público comprometerse <PH> y el dev comprometerse que esto corresponde a <DevPH> (antes del filtrado).

con la rama dev desprotegido, que quiere hacer algo como esto:

git rebase --onto <PH> <DevPH>

Esto le dice a tomar rebase los parches introducidos por cada confirmación desde <DevPH> en la rama actual y aplicar estos compromete a <PH>. Creo que esto es lo que necesita.

Editar:

Su actualización de la cuestión muestra que h es equivalente a la cabecera de la cadena pública en la rama dev y que desea transplantar todo, desde aquí en adelante en la rama dev a la rama pública. Si lo que el comando es

git rebase --onto pub h

Answer 4

Bueno, si yo no quiero a tierras fileit en .gitignore. Probablemente es la configuración de código no real, de modo que no es necesario el seguimiento en absoluto.