svn o git o algo más?

Nuestro equipo está desarrollando un juego.

Me gustaría probar un prototipo separado que está basado en nuestro código, pero será un poco diferente.
Usamos svn para el repository de código.

Ahora, para mi propio prototipo, ¿cómo debería configurar un repository para poder mantener las actualizaciones desde el svn pero no permitirme comprometer mis cambios accidentalmente?

Creo que la ramificación (¿o bifurcación?) Es el concepto relevante aquí, pero en realidad no lo he configurado yo mismo.

Sería útil si alguien pudiera diseñar la estrategia conceptual.
Debajo está lo que estoy pensando aunque no he hecho una bifurcación / merging_back.
¿Estoy en el path correcto al abordar esto?

  1. tenedor el proyecto
  2. aplicar mis cambios al proyecto bifurcado y seguir obteniendo actualizaciones del tronco principal
  3. fusionar mis cambios a los principales (repo de svn de mi equipo) si es necesario.
  • ¡cualquier consejo práctico (como elegir entre svn / git) sería muy apreciado!

Creo que puedes hacerlo con solo usar SVN: "fork the project" == "crea una twig" para tu caso. Es un process común: crear una bifurcación, realizar cambios, fusionar periódicamente troncales (lo que se conoce como fusión de synchronization), fusionarlo nuevamente a la troncal si el prototipo fue exitoso u olvidarse de la sucursal. Tal vez, al trabajar con la copy de una base de código, corrija algunos errores en el código original, de modo que pueda volver a seleccionar las correcciones de la versión original del tronco (esta es la razón por la que no debe dividir el proyecto en un repository separado).

Si prefiere Git, eche un vistazo a estas herramientas:

  • SubGit . Usted lo instala en su repository SVN y crea una interfaz Git para el repository SVN (interfaz Git pura, no git-svn) con la combinación sobre la marcha, ignora y label la traducción. Así que puedes probar ambas interfaces y finalmente apagar las interfaces (dejando solo Git si tu equipo decide cambiarlo por completo o tal vez solo SVN, si Git no te conviene).
  • También puede usar git-svn, pero proporciona una funcionalidad bastante restringida: puede enviar solo el historial lineal, no convierte ignora o tags sobre la marcha; no es compatible con cherry-picks
  • Puede ver SmartGit como reemploop de git-svn: compatible con ignores, tags, cherry-pick e incluso svn: externals

Creo que la respuesta depende de qué tan grande sea su proyecto y cuán lejos planee avanzar en su desarrollo.

El proyecto más grande será, y tan lejos como pueda, notará que la herramienta práctica para usted personalmente es más valiosa que cualquier consejo de nadie.

Elegiría el control de versión distribuida sobre centralizado en cualquier caso. Y git es uno de los DVCS más avanzados del mercado. No te equivocarás con eso.

En nuestro proyecto estamos usando git en las estaciones de trabajo de los desarrolladores y el control de la versión centralizada está en el server como almacenamiento principal (Serena de PVCS). No tenemos un complemento para sincronizar Serena y Git automáticamente y hacerlo manualmente y teniendo en count esta pequeña exageración para usar los beneficios de Git.

Pero en tu caso, git-svn y SubGit te ayudarán.

Sin embargo, si necesita algo más que el control de la versión (y no puede usar github por algún motivo) – wiki de seguimiento de problemas, documentation, por favor considere fósiles . Se basa en los mismos principios que git, pero tiene seguimiento de problemas, documentation wiki, interfaz web y un ejecutable increíblemente pequeño que no necesita instalarse.

Pero si los cambios son insignificantes o no planeas ir muy lejos, ¿por qué no te apegas a la opción estándar que otros usan?