Publicación segura de la twig filtrada a otros a través de una request de extracción

Permítanme comenzar describiendo brevemente nuestra configuration. Tenemos un repository "maestro" de GitHub al que solo podemos contribuir mediante requestes de extracción. También tenemos un tenedor privado en GitHub donde se realiza todo el trabajo, y desde donde realmente creamos requestes de extracción. Finalmente, hay un clon local de esa bifurcación privada.

La tarea a mano es reescribir una multitud de posts de compromiso, y obviamente git filter-branch es la herramienta preferida aquí.

Creé una twig temporal en mi repository clonado local y realicé todo el filtrado allí con éxito, lo que aparentemente creó un "historial alternativo" con todas las confirmaciones afectadas por el filter. Luego, como se describe en http://sofes.miximages.com/a/15256575 , he vuelto a establecer la base del maestro local en la twig temporal.

Ahora la pregunta es: ¿cuál sería la forma más segura de:

  1. Actualice la bifurcación de GitHub para que las demás personas del equipo no se vean afectadas (podemos coordinar las actividades necesarias para que esta actualización no suceda de forma inesperada). Supongo que git push --force-with-lease podría ser el path a seguir, sin embargo, nunca lo he intentado junto con filter-branch así que no estoy del todo seguro de si es una buena idea.
  2. Propaga los cambios en el repository maestro mediante una request de extracción

¡Gracias!

Esa respuesta sobre hacer una twig temporal y volver a basar se aplica a otra cosa. Si reescribió su twig filtrada (que es la maestra) además de la maestra, no estoy seguro en qué estado se encuentra ahora su repository.

Deseará deshacer eso reiniciando el maestro nuevamente donde estaba. Si no realizó ninguna confirmación adicional en el master , probablemente pueda volver a restablecer el origin/master mediante el git reset --hard origin/master . Luego haz el filter en el master .


Normalmente no usarías una request de extracción para este tipo de cirugía. Las relaciones públicas son para twigs de características que se comportan bien, no para reescribir el historial (aunque puede reescribir de forma segura las twigs que se han enviado como relaciones públicas). En su lugar, harías el filter, verificaría si era correcto, git push --force , y dejaría que todos supieran que el master ha sido networkingiseñado. No creo que las requestes de extracción estén configuradas para este tipo de cosas.

Este es el por qué. Digamos que el primer cambio que hace el filter es en C. El resultado es básicamente una nueva twig.

  A - B - C - D - E - F - G - H [origin/master] \ C1 - D1 - E1 - F1 - G1- H1 [master] 

Debido a que una confirmación se define mediante la confirmación previa, cuando reescribe una confirmación, Git debe reescribir todos sus elementos secundarios. Incluso si contienen el mismo contenido, serán commits diferentes con diferentes ID de commit.

Si tuviera que enviar esto como una request de extracción … No estoy seguro de lo que Github va a hacer. O lo tratará como una sucursal y hará un gran lío, o Github tiene algo de magia sobre el rebase. ¿Intentalo? Envíalo como un RP y ve lo que Github hace con él. Si no funciona, elimine el PR y hágalo manualmente.


El otro, AFAIK, el problema inevitable es que una vez que su filtrado se impulsa aguas arriba, todos se ven afectados. Todos tendrán que git pull --force y todos tendrán que volver a orderar sus twigs sobre el nuevo maestro.

Así que considere si el filtrado vale la pena solo para cambiar algunos posts de compromiso.