Control de versiones con desarrollo de juegos: ¿cuándo debo ramificar?

Recientemente comencé a usar el Control de versiones con mis proyectos (aunque estoy trabajando solo en ellos). Creo que es una buena manera de mantener el historial de todo el proceso de desarrollo (con seguimiento de problemas) y me permite mantener copias de seguridad de mis proyectos en el camino.

A medida que descubro lentamente las características y ventajas del uso del control de versiones, me quedo estancado en la idea de ramificar. ¿Cuándo debería hacerlo?

¿Debería ser cada vez que voy y desarrollo una nueva función, o solo de vez en cuando cuando alcanzo un cierto hito?

Obviamente, la ramificación es bastante inútil cuando se trabaja solo, pero prefiero tomar buenos hábitos ahora y acostumbrarme.

Mientras leía el libro Game Coding Complete de Mike McShaffry (que es un gran libro por cierto), me perdí totalmente cuando el autor me recomendó mantener tres ramas, algo así como:

• Principal : rama de desarrollo principal donde se realizan cambios regulares.
• Oro : rama de oro donde se mantiene el último hito alcanzado.
• Investigación : Rama para probar cosas que podrían afectar gravemente a la rama Principal (modificando componentes importantes del motor del juego, etc.).

¿Es así como se supone que debe ser? ¿Cómo funciona realmente en el mundo del desarrollo de juegos con grandes equipos de desarrolladores?

Básicamente: ¿ Cuándo se suele ramificar (y fusionar) en el desarrollo del juego?

La ramificación depende un poco del soporte de VCS para la función (es decir, si el VCS lo hace fácil o difícil).

Pero, como mínimo, desea una rama para cada versión de su proyecto con soporte independiente. Es decir, si tiene "Juego 2" y "Juego 2 + Expansión", que son productos independientes creados a partir de la misma base de código, y que necesita para poder parchear y emitir actualizaciones, entonces desea tener cada uno de estos existen en su propia rama fuera de la base de código principal, de modo que las correcciones a la base de código central se pueden combinar en cada uno de estos productos de forma independiente. (Por lo general, estas ramas se crean cuando se lanza cada producto, o tal vez unos días / semanas antes, si tiene personas trabajando en cosas en la base de código que no desea publicar con la versión inicial)

Cuando trabaje con un VCS que hace que el uso de ramas sea difícil o doloroso (SourceSafe, svn, etc.), entonces probablemente será más feliz manteniendo una rama de "lanzamiento" para cada producto lanzado y haciendo su desarrollo principal en "tronco", fusionar los cambios de "troncal" en las ramas de "lanzamiento" si y cuando necesita lanzar revisiones para esos lanzamientos.

Si, por otro lado, está trabajando con uno de los sistemas VCS más nuevos que se basan en la ramificación y la fusión (git, Bazaar, Mercurial, etc.), entonces probablemente será más feliz haciendo su desarrollo en muy poco tiempo -vivo "característica" ramas. Por ejemplo, si está trabajando en la búsqueda de rutas de AI, puede hacer una rama de "búsqueda de rutas" e implementar el código allí. Cuando termine, vuelva a fusionar esa rama en su tronco principal de desarrollo y (opcionalmente) elimine la rama en la que estaba trabajando. El beneficio de este enfoque es que le permite trabajar en múltiples tareas simultáneamente, en lugar de tener que completar una. tarea antes de comenzar con la siguiente.

En mi proyecto de inicio actual (usando git), tengo cinco ramas de características diferentes activas en este momento, trabajando en varias características diferentes. Dos de ellos son enfoques alternativos para hacer lo mismo (para perfilar), dos son ideas mecánicas de juegos experimentales, y uno es un gran refactorizador de mis sistemas de IA, y en realidad está roto de tal manera que el código no se compila correctamente ahora. Pero está comprometido en su rama de características para referencia y respaldo, y estar roto no me impide trabajar en las otras características; Esas otras ramas de características (y el tronco principal de desarrollo también) aún se compilan y se ejecutan correctamente.

En mi experiencia en el desarrollo de juegos profesionales de grandes equipos, todavía estamos atrapados en su mayoría con sistemas de control de versiones más antiguos (y con soporte comercial). Perforce es probablemente el más utilizado, seguido de Subversion. En todas partes donde he trabajado, hemos tenido una rama 'troncal', y luego una rama 'liberación' separada para cada entregable (hito / demo / lanzamiento / etc.). Ocasionalmente, alguien hará una rama personal para un gran cambio que está haciendo o probando, pero esto es extremadamente raro, y generalmente es para cosas como "convertir el juego para que se ejecute con esta biblioteca de física diferente" que en realidad puede no pasar a la producto lanzado.

Ya es una excelente respuesta anterior, pero una cosa a tener en cuenta es cuándo desea ramificarse y cuándo desea etiquetar.

La mayoría de las vcs le permitirán etiquetar (a veces lo llaman etiquetado). Debe aplicar una etiqueta cada vez que realice una compilación importante (ya sea para una prueba de juego, una prueba beta o para una función que ingrese). Si está utilizando algún tipo de integración continua (y debería hacerlo), entonces el sistema CI debe etiquetar las compilaciones exitosas. Básicamente, cada vez que haga algo a lo que desee regresar (ya sea para crear una rama o para verificar cómo hizo algo en esa versión), haga una etiqueta / etiqueta. Por lo general, son de bajo costo y fáciles de agregar.

La otra cosa que recomiendo encarecidamente es que mantenga sus activos y código en el mismo sistema de versiones. Tener una rama (o etiqueta) de código es completamente inútil si no puede hacer coincidir (y luego ramificar) los activos. Esta es una de las razones principales por las que las compañías de juegos aman a Perforce: es igualmente feliz almacenar archivos de arte binarios como almacenar código, y (a diferencia de git) es comprensible para los tipos no técnicos.

Ah, y cada vez que sienta que desea verificar los archivos compilados en su parada de VCS y piense cómo puede evitar hacerlo. En mi experiencia, casi siempre conduce a datos que no coinciden, fuente faltante (donde, por ejemplo, una textura DDS comprimida se registra pero no la fuente png), y el caos en la línea. Si tiene una canalización de activos que está mejor atendida por los archivos exportados que se almacenan en caché en algún lugar (para que no todos vuelvan a generar el mismo conjunto de archivos), tenga un proceso que construya los activos de origen en su VCS y coloque los archivos exportados en un caché (o unidad compartida, o incluso un VCS separado). Pero no verifique esos archivos exportados a mano: lo morderá (especialmente si está trabajando como parte de un equipo).

Me encantó ese libro, y lo recomiendo a todos los que tengan intereses relevantes. Para proyectos independientes de un solo hombre, no hay necesidad real de ramificarse a menos que necesite o quiera crear versiones separadas; como uno para Android y otro para PC, o algo por el estilo.

Como dijiste, si quieres aprender buenos hábitos, seguiría el enfoque de Mike. Tiene mucho sentido y es el enfoque que uso en mis proyectos independientes de dos hombres.

Todo lo que necesite para poder regresar y trabajar más debe ser ramificable (pero no necesariamente ramificado ... todavía).

La razón de esto es simple. Debe poder emitir una versión fija de ese código, no cualquier otro código, por lo que en ese momento debe trabajar en una sucursal.

Los VCS son diferentes. Algunos, como git, son muy fáciles de ramificar desde cualquier commit en cualquier momento posterior, otros, como CVS, son muy engorrosos para trabajar más tarde.

¿Quizás quiera abrir una pregunta sobre stackoverflow, preguntando cómo trabajar mejor con el sistema de control de versiones que ha elegido? Si aún no ha comenzado realmente con mucha historia, ¿puede abrir una pregunta que describa su forma de trabajar y solicitar una recomendación del mejor sistema de control de versiones para usted?