¿Está creando parches de modificación de git y luego editando manualmente antes de aplicar un flujo de trabajo válido?

Ok, hay 2 proyectos, A y B. El proyecto en el que estoy trabajando 'B' está en sentido descendente de 'A'. Es decir que B ha agregado características diferentes y crecido en una dirección diferente a A. Pero comparten una historia común.

Hace un time, B se mantuvo con actualizaciones periódicas con cada versión principal de A. Pero este ya no es el caso.

Al rastrear una fuga de memory en B, descubrí que se arregló en A hace más de un año y luego se realizaron muchos cambios en A para mejorar el performance.

Se decidió que todos estos cambios deberían integrarse en el proyecto B.

Entonces esto es lo que estoy haciendo ahora. Obviamente, hay bastantes dificultades que hacen que la tarea sea inmanejable. Pero ninguno de ellos realmente se relaciona con mi pregunta.

Empecé a crear componentes de diff por componente para ver qué había cambiado y decidir qué se podía include sin alterar las características en B que no existían en A.

Creé una nueva twig para cada componente (con el fin de hacerlo más manejable, identificando lo que mantenía references al código modificado fuera de un componente específico) pensando originalmente que podía hacer una fusión, me parece recordar usar fusión antes y crea conflictos en lugar de sobre escribir cosas; pero por alguna razón cuando intenté fusionar un componente de A con B, la mayor parte del código exclusivo de B se perdió.

Sin embargo, lo que podría funcionar, dudaría en dedicar time a una técnica con posibles caídas de pozo que desconozco, es simplemente editar los parches creados a partir del diff.

Luego aplica el parche editado.

Debido a que en el parche puedo ver ambos lados del código uno al lado del otro, puedo eliminar bits (-) donde no deseo que se elimine el código y preocuparme por los conflictos caso por caso.

¿Alguien ha probado esto? ¿O alguien sabe de una técnica de flujo más principal para manejar este tipo de problema?

El otro problema es ¿cómo se puede alterar un parche sin que el sistema git lo corrompa?

En lugar de editar los parches de git, recomiendo seleccionar los commits interesantes y modificar el diff aplicado en el directory de trabajo:

git cherry-pick --no-commit upstream/commit1 (edit changes in working directory) git commit 

Si tienes muchas confirmaciones potencialmente interesantes, puedes probar la rebase interactiva.

 git checkout upstream/master -b upstream-new git rebase -i master 

De esta forma, puede revisar y seleccionar muchas confirmaciones fácilmente; por ejemplo, elija solo confirmaciones que afecten solo a un subsistema. Puede ayudar al process de selección ejecutando un git log --oneline subsystem1/ >/tmp/subsystem1_commits.txt – creará un file con la misma syntax aceptada por git rebase -i .

Acerca de su flujo de trabajo: no creo que haya una solución fácil para su problema. Si el repository en sentido ascendente y su twig divergirán por un time prolongado, perderá la principal ventaja de git: una fácil bifurcación y fusión . Lo que le quedará es un sistema de parcheamiento casi manual, que siempre es un problema. Pero si puede actualizar el repository upstream una o dos veces al año, puede valer la pena hacer lo siguiente:

  • comience desde la versión upstream / master, aplique sus commits a él (=> su twig master-1)
  • selects de selección de cereza de upstream / master cuando sea necesario
  • cuando tienes time para actualizar a la twig ascendente, rebase tu twig master-1 en upstream / master, pero sin las revisiones ya seleccionadas (puedes hacerlo con git rebase -i ). Llamemos a esta twig maestra-2.

De esta manera tendrá la siguiente historia:

 AAAAA- (upstream/master at the beginning) \ -BBAB (your master-1 branch, with a cherry-pick) \ -AAAAAAAA -BBB (your master-2 branch, after the rebase)