Git: hacer una twig como maestro en Github mientras se mantiene maestro real en BitBucket

Tengo un proyecto alojado en bitbucket como proyecto privado. El proyecto ahora es público al recortar muchos códigos fuente y configuraciones del proyecto raíz. He puesto el proyecto público en github.

Como se trata de un proyecto interno, sigo trabajando en el proyecto de manera git, y luego envío cualquier cambio público apropiado al proyecto en github. He estado administrando dos proyectos usando SVN en ambos ya que SVN era la herramienta que se había usado originalmente antes de Git. A medida que empujo más productos de interno a público, siento que esta es una manera realmente estúpida de hacerlo.

Creo que el proyecto público debería ser el maestro, ya que el proyecto interno tiene muchas adiciones además de lo que es público, pero quiero mantenerme alejado de github para el proyecto interno.

theProject(on github) ->(branch)theProject_INTERNAL(on bitbucket) 

Quiero continuar trabajando en 'theProject_INTERNAL' y solo fusionar algunos cambios en 'theProject' mientras mantengo el proyecto interno absolutamente prohibido para el público.

¿Cómo puedo lograr esto sin muchos dolores de cabeza con Git?

Usa una twig de rastreo . La supresión de la twig master de BitBucket tiene los cambios que publicará en público, en el repository de GitHub:

 $ git checkout -b master_of_bitbucket_on_github remote_bitbucket/master 

Esto creará la twig master_of_bitbucket_on_github en el repository de GitHub, que rastreará la twig master de BitBucket.

Si no lo hace, deberá configurar la bifurcación remota remote_bitbucket .

O puede hacer lo contrario: crear una twig de seguimiento en el repository de BitBucket rastreando una twig de GitHub si no desea hacer reference a su repository privado en el repository de GitHub.

Desarrolle cada característica en una twig independiente de características INTERNAS (que usted acaba de presionar allí) y cuando sienta que su código está bien para la rebase pública de esa twig en la parte superior de la twig pública (consulte: http://git-scm.com/ book / de / Git-Branching-Rebasing ) y push

la ventaja es que no necesitas empujar todo … y puedes hacer una carrera en seco localmente antes de hacer algo mal públicamente.

pero lo que no entiendo es, ¿para qué necesitas svn? (lo cual es bueno, porque svn es realmente malo de todos modos)

Siempre puede tener tantas sucursales públicas y privadas como desee. Lo que los hace privados es la configuration correcta de los controles remotos.

Si fuera un proyecto nuevo, iría sobre algo como:

  1. Crear proyecto público en GitHub

  2. Clonarlo en una máquina privada (mi estación de trabajo)

    Sugerencia: cambie el nombre de "origen" a otra cosa para minimizar la confusión

  3. Agregue otro control remoto: bitbucket

  4. Crea una sucursal local basada en el maestro

  5. Empujar la twig a bitbucket

(Estoy usando un sistema similar para mi colección de files dotfiles: tengo una twig "privada" que solo existe en un repository desnudo en mi estación, y la clono en la estación y algunos virtuales).

Cuando trabaja, quiere estar seguro:

  • obviamente, que usted no comete accidentalmente + empuja algo privado a la twig pública

  • que la twig privada está configurada correctamente para seguir el bitbucket remoto, no el "origen", es decir, GitHub

Si desea utilizar diferentes máquinas para trabajar en el proyecto, considere la creación de un repository propio (quizás en algún lugar de su networking privada) donde puede agregar tantos controles y enganches precomstackdos como sea necesario (incluso puede grep el contenido de los files fuente).

Eso hará que sea más fácil implementar el repository en otra máquina, además puede ayudar a networkingucir la dependencia de la networking o implementar algún control de acceso.


Aquí está el esquema final que incluye el proxy:

 .------------------------------------------------------------------------------. : . . : : [github.com] ----------. . [bitbucket.org]-. . : : branches: : . branches: : . : : master : . private : . : : : : the internets : :--------------------------:-----------------------:---------------------------: : : : all your base : : [local_git_proxy] '..................... : : : remotes: : : : : public git://github.com/...or.so..' : : : private git://bitbucket.org/...or.so..' : : branches: : : master set up to follow public/master : : private set up to follow private/private : : any other team branches : : hooks: : : hooks to prevent you from leaking data to public : : maybe some hooks to automate pushing/fetching : : : : [actual_dev_machine] : : remotes: : : origin: git://local_git_proxy/...or.so... : : branches: : : master set up to follow origin/master : : private set up to follow origin/private : : your own "crazy" branches : : : '------------------------------------------------------------------------------'