¿Cuál es una forma recomendada de administrar queues de parches git en repositorys no relacionados?

Por lo tanto, tengo muchos repositorys que necesito para administrar los sets de files en git.

Principalmente trabajo en lo que llamaré issue-branches (No estoy seguro si esa es una terminología oficial para git, pero sus twigs de corta vida para cada número). Tengo el hábito de volver a basarme si acaban tardando más en completarse, o incluso aplastando si tengo compromisos de testing y error involucrados.

Vengo de un flujo de trabajo mercurial con "MQ" como mi "Me siento cómodo" en el que hago algo, más o less como:

 for i in $LIST_OF_REPO_PATHS_ON_DISK; do echo $i hg -R $i qseries done 

Esto es ultra simplificado donde hago que los repos sean más legibles, y no repito nada si no hay parches en mi queue.

La premisa aquí es que elimino cosas no desarrolladas en las que ya no estoy trabajando o que son rechazadas.

Sin embargo, en git, una twig es el método usado, así que no puedo hacer "git branches" (ya que muchos repos tienen múltiples twigs usadas en casos normales), pero me gustaría hacer algún tipo de "twigs que son delante del maestro, o el origen remoto ".

Para mí, todos mis repos están en github, pero no en el upstream de todos estos repos (algunos upstreams están en gitolite alojados en otro lado). Se puede suponer que mi fork github contiene todas mis copys de twigs funcionales, también configuro un control remoto "pr" en repos. También logro rastrear encabezados de request de extracción, por lo que puedo verificarlos fácilmente localmente sin tener que agregar un control remoto nuevo, adicional .

¿Hay otras maneras de abordar este problema de seguimiento de mi propio trabajo, si no hay una manera de hacer lo que quiero con git como se describe arriba?

Para mercurial escribí una publicación en el blog sobre exactamente lo que hago: http://blog.drapostles.org/archives/126