Rastreando otro git-repository

Intento establecer un entorno de desarrollo "networkingmine", que debería facilitar que varias personas desarrollen y mantengan nuestra propia versión de "networkingmine", incluidas nuestras propias funciones y ajustes. No estoy tan familiarizado con las sucursales remotas, pero pensé en una configuration como esta:

  • sucursal principal : para su deployment
  • Sucursal de desarrollo: aquí estamos desarrollando nuestras nuevas funciones
  • twig de la comunidad : aquí es donde me quedé atascado. Me gustaría tener una sucursal que esté rastreando el repository de networkingmine de la comunidad github, para que pueda decir en esta twig 'git checkout v2.0' y luego en la twig de desarrollo 'git merge community' y resolver conflictos de fusión debido a nuestras propias características allí. Después de la próxima descarga de networkingmine, yo comtesting v2.1 en la twig de la comunidad y lo fusiono con la twig dev nuevamente, y así sucesivamente …

Por supuesto, puedo agregar un control remoto a mi sucursal local, sacar del repository de la comunidad y enviarlo a mi origen, pero luego las otras personas no lo verían y tendrían que agregar el repository remoto de la comunidad (¿no?). ¿Es esto posible o cuál es otro enfoque para resolver este problema de "seguir un proyecto de reference en mi propio proyecto"?

Gracias

Ene

Por cierto: mi repository de origen se crea usando gitosis.

Ya sea que esté en su split de desarrolladores o de la comunidad (área de trabajo), necesitará usar twigs de características para desarrollar, editar y proponer sus desarrollos para que puedan rejoin de una manera estructurada. Es decir, debe elegir un enfoque para fusionar las contribuciones y promoverlas a un nivel superior. git-scm.com/book/es/Git-Branching-Branching-Workflows

Tómese el time para comprender cómo funcionan los controles remotos, y que las twigs rastreadas son duplicates exactos (hasta el punto del scope o empuje común), por lo que no puede planificar que las contribuciones de las distintas personas se asignen a la misma twig de la comunidad . cada persona debe tener su propia twig de características. Puede volver a utilizar los nombres de las twigs una vez que la característica esté completa.

git sí mismo ( github.com/git/git ) tiene una secuencia publicada de twigs: – pu (actualizaciones potenciales), siguiente , y finalmente amo . Antes de pu hay twigs queueboradoras individuales (cada una construida a partir de envíos de series de parches en el caso de la list git), y pu puede rebobinarse si / cuando el mantenedor lo necesita. el siguiente es más estable. Los usuarios obtienen actualizaciones y vuelven a establecer su trabajo en la última versión relevante.