Los sistemas de control de versiones (VCS) permiten que los equipos hagan una copia de seguridad del código fuente de sus proyectos y también que puedan archivarlo. Esto facilita la tarea de revisar y hacer modificaciones en el repositorio o restaurar las versiones anteriores en caso de que un error impida el buen funcionamiento del código.

El control de versiones es el proceso sistemático de seguimiento y gestión de actualizaciones del código fuente y los recursos. Los sistemas de control de versiones son fundamentales para tener flujos de trabajo eficientes, ya que actúan como la única fuente de verdad para programadores, artistas y otros miembros del equipo y, a la vez, permiten que todos contribuyan a una base de código compartida de forma independiente. También actúan como una red de seguridad, lo que permite «deshacer» las actualizaciones de código si se introduce un error catastrófico durante el desarrollo.

Algunos factores, como el tamaño y la distribución geográfica de un equipo, pueden influir en el sistema de control de versiones que un desarrollador de juegos podría elegir implementar. Para los desarrolladores individuales, una solución local podría ser todo lo que necesitan para mantenerse al día, mientras que los equipos más grandes deben buscar un sistema de control de versiones más robusto y escalable que los ayude a colaborar desde distintas zonas horarias y ubicaciones.

El control de versiones también admite la creación de ramas. Una rama es una copia única de un código gestionado dentro de un VCS. Con la creación de ramas, los desarrolladores y otros miembros del equipo pueden trabajar de forma independiente dentro de canales separados. El control de versiones ayuda a que los desarrolladores trabajen de forma colaborativa y sincronizada dentro de una base de código compartida.

Los sistemas de control de versiones son un pilar central de DevOps, ya que permiten que los equipos colaboren e iteren rápidamente el código fuente de un proyecto.

Trabajar con control de versiones significa que siempre tienes una copia de seguridad. Las actualizaciones de proyectos individuales se recopilan periódicamente en un grupo singular, conocido como «confirmación» (commit), antes de fusionarse con el código fuente principal. Es esencial usar un software para el control de versiones a fin de hacer un seguimiento de todas las modificaciones que se hagan en cada archivo de un proyecto. En caso de un error o una regresión, los usuarios pueden regresar a una versión anterior de ese archivo prácticamente de forma instantánea. El control de versiones también proporciona un registro de todos los cambios, de quién hizo los cambios y de todas las iteraciones hechas con cada cambio. Si se implementa un sistema de control de versiones, todas las partes interesadas y todos los miembros del equipo pueden trabajar fluidamente en muchos archivos al mismo tiempo. Los sistemas de control de versiones permiten fusionar todas las ediciones y los cambios del código en un repositorio centralizado.

Al contar con acceso a un historial completo del proyecto y la capacidad de deshacer errores, los sistemas de control de versiones simplifican el seguimiento de errores y facilitan la restauración de funciones eliminadas anteriormente.

Al crear un nuevo repositorio en su sistema de control de versiones, se abre la rama principal: Esto se denomina rama principal o troncal principal. Aquí es donde la base de código ingresa al canal en el que se compila y se implementa para que lo vea el usuario final.

Entonces, ¿qué son las ramas? Bifurcar es el proceso de crear ramas del código a partir de la rama principal. Esto permite que los desarrolladores introduzcan los cambios que deseen en su rama del código sin confirmarlos en la rama principal. Así, los desarrolladores no necesitan tener el historial completo de los archivos en un mismo servidor; en cambio, pueden mantener todo el historial de los cambios hechos en su código a lo largo del tiempo. El sistema de control de versiones puede tomar estas ramas separadas y fusionarlas en la rama principal. Si un desarrollador no está listo para fusionar en la rama principal las ramas en que trabajó, puede confirmar sus cambios en una rama separada y, luego, fusionarla en la principal cuando lo desee.

Una estrategia de bifurcación adecuada es fundamental para evitar conflictos en el código y problemas con las compilaciones. Afortunadamente, los buenos sistemas de control de versiones permiten que los equipos sincronicen sin inconvenientes con la rama principal y corrijan cualquier posible conflicto con el código: incluso después de haber confirmado el código con la rama de integración principal.

Los sistemas de control de versiones distribuidos permiten subir el código, crear ramas y fusionarlas sin necesidad de conectarse al servidor principal. Cada colaborador trabaja desde un repositorio clonado almacenado en la nube. Su principal ventaja es que los miembros de un equipo pueden trabajar por separado, a gran velocidad y sin preocuparse por redes o VPN lentos. Incluso es posible trabajar en un proyecto sin conexión, pero igual se necesita una conexión a Internet para subir o bajar actualizaciones.

Los sistemas de control de versiones distribuidos pueden presentar largos tiempos de espera si alguna vez necesitas descargar todo el historial de tu proyecto, en especial en proyectos grandes con historiales de cambios extensos. Los estudios que trabajan con archivos binarios grandes deben controlar cuidadosamente el uso del almacenamiento, ya que estos archivos pueden ocupar espacio rápidamente.

Los estudios que busquen flexibilidad y el potencial de aumentar la productividad deben considerar el control de versiones distribuido.

Los sistemas de control de versiones centralizados utilizan un flujo de trabajo de registro/inserción para conectarse al servidor principal. Cualquier cambio o actualización del código fuente se almacena automáticamente en el repositorio como una versión nueva. Los sistemas de control de versiones centralizados cuentan con poderosas capacidades de bifurcación y fusión que no requieren que el repositorio se clone en varios equipos. En ese sentido, es potencialmente más seguro.

Los sistemas de control de versiones centralizados requieren una conexión de red. Dado que los equipos están vinculados a una sola versión del proyecto almacenado en un servidor, las interrupciones del servicio pueden provocar demoras importantes. Otra desventaja del control de versiones centralizado es que pueden traer dificultades al momento de tener que ampliar el tamaño del proyecto. Cuantos más desarrolladores estén contribuyendo a tu proyecto, menos oportunidades habrá de impulsar cambios en un entorno estable, lo que puede generar problemas tales como conflictos al fusionar el código.

Si estás interesado en sistemas de control de versiones que sean fáciles de configurar y usar, puedes considerar un flujo de trabajo centralizado.

Los sistemas de control de versiones locales son la forma más sencilla de tener un control de versiones y los utilizan principalmente los desarrolladores individuales en vez de los equipos. Con el control de versiones local, todos los datos del proyecto se almacenan en una sola computadora y los cambios realizados en los archivos del proyecto se almacenan como revisiones. Cada revisión contiene solamente las actualizaciones implementadas desde la revisión anterior. Si hay un problema con una versión específica de tu proyecto, debes examinar todo el conjunto de revisiones para reconstruir cómo se veían los archivos del proyecto en un momento específico a fin de diagnosticar el problema.

Como están vinculados a una sola computadora, los sistemas de control de versiones locales son inherentemente menos flexibles que los sistemas centralizados y distribuidos para el mismo fin. La colaboración entre los miembros de un equipo es un desafío y, si la base de datos se ve comprometida, puede ser difícil (si no imposible) restaurar la información que se perdió.

En general, está bien comenzar con el control de versiones local, pero en cuanto comience a aumentar el tamaño del proyecto (incluso si se pasa de un equipo unipersonal a uno de dos personas), es mejor trabajar de forma distribuida o centralizada.