¿Cómo se combinan los cambios en twigs no maestras de un repository github bifurcado?

En las dos preguntas siguientes de StackOverflow, la respuesta aceptada describe cómo fusionar los cambios de un repository bifurcado en la situación en la que bifurca un repository, se modifica el repository original y luego desea fusionar los cambios realizados en la twig principal nuevamente en su repository bifurcado.

  • Fusión entre horquillas en GitHub
  • Fusionar cambios desde el repository remoto de github a su repository local

Sin embargo, no tengo claro cómo mantenerte al día con las sucursales no maestras en el repository original que has ahorrado. Por ejemplo, cuando originalmente bifurqué el repository de tejidos de bitprophet , contenía las siguientes twigs:

  • dominar
  • 0.9
  • 0.9-doc-rewrite (ya no existe)
  • path-and- # 24 (ya no existe)

Las dos últimas twigs ya no existen, y ahora hay una nueva twig flexible-task-declarations . He buscado, fusionado y empujado mi twig maestra, de modo que maestro, origen / maestro y ascendente / maestro tienen el mismo hash SHA1 y apuntan a la misma instantánea git. Sin embargo, no estoy seguro de cómo eliminar las twigs que ya no existen y actualizar las nuevas twigs para que mi tenedor esté actualizado. ¿Debo realizar un seguimiento de cada twig ascendente y luego search, fusionar y pulsar cada twig individualmente, o hay una forma mejor?

Escenario 1: eliminar las twigs que ya no existen

Para eliminar las twigs que ya no existen, seguí las instrucciones en la respuesta a la pregunta de StackOverflow. ¿ Cómo elimino una twig de Git tanto localmente como en Github? emitiendo los siguientes commands:

 $ git push origin :0.9-doc-rewrite $ git push origin :path-and-#24 

Escenario 2: fusión de cambios en una twig no principal existente

Para actualizar la twig ascendente / 0.9, hice lo siguiente:

 $ git checkout --track origin/0.9 $ git fetch upstream $ git merge upstream/0.9 $ git push 

Escenario 3: Seguimiento de las nuevas twigs no maestras

No estoy seguro de que esta sea la mejor manera de manejarlo, pero esto es lo que hice:

 $ git branch flexible-task-declarations upstream/flexible-task-declarations Branch flexible-task-declarations set up to track remote branch flexible-task-declarations from upstream. $ git checkout flexible-task-declarations $ git push origin flexible-task-declarations 

Para confirmar que todas las twigs están en el mismo compromiso:

 $ git branch -av 

Esto mostrará todas las twigs, local y remota, y mostrará el post de confirmación más reciente y el hash SHA1.

La investigación web puede arrojar luz sobre un mejor método para manejar el escenario 3

  • Guía de Github: mantener sincronizada una bifurcación git con el repository bifurcado : proporciona un atajo para fusionar octo tanto desde el repository de origen como de origen, al mismo time, pero no describe el paso inicial de get la bifurcación que está en sentido ascendente pero no configuration de origen localmente
  • Utilice y mantenga su fork actualizada con el repository maestro de Git de las preguntas frecuentes del desarrollador de xmpp4r

Una diferencia key entre un tenedor Git, cuando se compara con un simple clon Git, o un pago SVN, es que su tenedor nunca se mantendrá actualizado con el repository maestro a less que lo haga. Afortunadamente, hay una herramienta simple para ayudarte a hacer esto. Su horquilla está separada e igual que la maestra en términos de Git, por lo que si desea realizar un seguimiento de los cambios en el maestro, puede crear una twig de seguimiento en su repository bifurcado y fusionar esos cambios en la twig maestra de la horquilla siempre que quiera comprometer algo. Recomiendo encarecidamente la gem 'GitHub', que es una herramienta que puede instalar para ayudarlo a seguir fácilmente los cambios en cualquier otro repository relacionado con el suyo. Vea el text README en la parte inferior de esta página para la installation y el uso: http://github.com/defunkt/github-gem/tree/master

  • Collaborative Github Workflow de eqqon (buen artículo sobre el flujo de trabajo de Github):

Ignora el Github Fork Queue ¡ Es malvado! La queue de la horquilla es una herramienta para los mantenedores a los que les gusta elegir compromisos únicos de los contribuyentes pero no desean fusionarse en toda su sucursal. Si juegas con la queue de la horquilla, corromperás tu tenedor (aunque se puede arreglar, lee Algo salió mal). Muchos novatos en github sienten que deberían hacer algo con la queue de espera porque hay muchos cambios posiblemente conflictivos allí y no saben cuál es la supuesta forma de mantener actualizado el tenedor. Lee ¡Manteniendo tu tenedor al día y averígualo!

Flujo de trabajo Github de Django

El proyecto Django tiene instrucciones sobre cómo queueborar en Github, que utiliza lo que parece ser la forma estándar de manejar bifurcaciones y tirar de los cambios ascendentes.

Diferente configuration de horquilla inicial

La publicación de invitados de Long Nguyen titulada Configurar sus repositorys de Git para proyectos de código abierto en GitHub en el blog de Michael Hartl describe un método interesante para configurar un repository de Github que haya bifurcado. Los objectives de este método según el artículo son:

  • Mantenga los repositorys sincronizados para que cada uno contenga el repository "oficial" completo
  • Permitir que los desarrolladores obtengan actualizaciones oficiales
  • Aliente el trabajo en sucursales que no sean maestras

Básicamente, tienes 3 remotas Git Repo Ton Considera:

  • local: tu actual repository git en tu estación de trabajo.
  • origen: cuál es su versión bifurcada de la tela: cumulusware
  • upstream: bitprophet / fabric , el que está en el origen de todos los otros repositorys bifurcados

Puede agregar aguas arriba como un repository remoto a su local.

  git remote add upstream http://github.com/bitprophet/fabric.git 

mira las twigs remotas

  git branch -r 

y presione (elimine) los que existen en el origen pero que ya no existen en el flujo ascendente

  git push origin :anOldBranch 

Entonces

  git remote prune origin 

borrar las twigs en su repository local (que ya no existe en el origen, ya que las acaba de eliminar)

Las twigs que existen tanto en origen como en sentido ascendente también deben estar sincronizadas (cambiar las twigs locales por encima de las de origen antes de empujar su trabajo al origen puede ser una buena forma de hacer una request de extracción muy fácil hacia el origen: bitprophet solo tener una fusión de avance rápido para include tu trabajo)

No sé si podría tener un process / command / script más simple para sincronizar dos repositorys distantes.

Encontré esta respuesta mientras buscaba cómo hacer el Escenario 3 en la respuesta aceptada limpiamente. Después de investigar un poco, con git 1.8 puedes hacer lo siguiente:

 git fetch upstream ;make sure you have all the upstream changes git checkout --no-track upstream/0.9 ;grab the new branch but don't track it git branch --set-upstream-to=origin/0.9 ;set the upstream repository to your origin git push ;push your new branch up to origin