Buenas prácticas para el control de versiones

Esta es, con diferencia, la mejora más sencilla que puede introducir en su flujo de trabajo y, sin embargo, es con la que más luchan algunos desarrolladores. Cuando trabajas con otras herramientas de gestión de proyectos, es probable que ya hayas dividido el trabajo en tareas pequeñas y manejables. Los compromisos deben tratarse exactamente igual.

Una única confirmación sólo debe referirse a una tarea o ticket, a menos que una única línea de código solucione mágicamente varios errores. Si estás trabajando en una función de mayor envergadura, divídela en tareas más pequeñas y haz commits para cada una de ellas.

La mayor ventaja de utilizar commits más pequeños es que, si algo sale mal, se pueden detectar y revertir los cambios no deseados con mucha más facilidad.

Los mensajes de confirmación describen la historia de su proyecto. Al fin y al cabo, es mucho más fácil encontrar el cambio que ha añadido las tablas de puntuaciones altas a tu juego si su mensaje de confirmación dice "se han añadido tablas de puntuaciones altas al menú" en lugar de "¡apuesto a que no puedes superar mi puntuación en estas nuevas tablas!".

Cuando se trabaja con un sistema de tickets de tareas como Jira o GitLab, es aún mejor incluir un número de ticket en tu commit. Muchos sistemas pueden configurarse para que trabajen conjuntamente con confirmaciones inteligentes, de modo que puedas hacer referencia a los tickets y cambiar su estado desde tu mensaje de confirmación.

Por ejemplo, un commit que diga "JRA-123 #close #comment task completed" establecería el ticket de Jira JRA-123 como cerrado, dejando el comentario "task completed" en el ticket.

Para más información sobre la configuración de este flujo de trabajo, consulta la documentación en Jira o el servicio Pivotal Tracker en GitLab.

La única vez que se debe utilizar "commit -a" (el comando de Git para "confirmar todos los cambios") o cualquiera de sus equivalentes es con la primera confirmación de un proyecto. Normalmente, esto ocurre cuando los únicos archivos del proyecto son README.md.

Una confirmación sólo debe incluir archivos relacionados con el cambio que está confirmando en el repositorio. Usted debe ser particularmente cuidadoso cuando trabaje con proyectos de Unity porque algunos cambios pueden resultar en que varios archivos sean marcados como cambiados, tales como escenas, Prefabs, o Sprite Atlases, aún cuando usted no tenía la intención de hacerles ningún cambio.

Si, por ejemplo, introduces accidentalmente un cambio en una escena en la que está trabajando otra persona, puedes causarles un quebradero de cabeza cuando vayan a introducir sus cambios y vean que primero tienen que fusionar los tuyos.

Este es uno de los errores más comunes que cometen las personas que se inician en el control de versiones. Es importante entender que sólo debes confirmar tus propios cambios en el proyecto. Para obtener más información, consulte esta entrada del blog sobre cómo acelerar su flujo de trabajo.

Tan a menudo como sea necesario, incorpora los últimos cambios del repositorio a tu copia de trabajo. No es buena idea trabajar de forma aislada, ya que esto sólo aumenta la probabilidad de conflictos de fusión. Consulte la tabla anterior para hacerse una idea del flujo de trabajo diario típico de cada sistema.

Los flujos de trabajo de Plastic SCM son un poco diferentes porque se puede trabajar en configuraciones centralizadas, distribuidas o multisitio.

Las configuraciones multisitio pueden ser bastante singulares, y cada usuario puede trabajar en un flujo de trabajo centralizado o distribuido.

Considere el siguiente ejemplo:

• Dos equipos
• Cada equipo dispone de un servidor in situ
• Los miembros del equipo se registran de forma local o distribuida en cada sede, pero se benefician de la velocidad de un servidor in situ cercano
• Los servidores se empujan unos a otros para mantenerse total o parcialmente sincronizados.

Independientemente del VCS que su equipo elija para trabajar, asegúrese de que todos se sienten cómodos utilizándolo y comprenden las herramientas que tienen a su disposición.

Si trabajas con Git, no todo el mundo necesita utilizar el mismo cliente GUI. Pero es prioritario que todo el mundo se sienta cómodo con el flujo de trabajo commit > pull > push. En otras palabras, deben tener los conocimientos necesarios para consignar sólo los archivos que necesiten.

Si trabajas con Plastic SCM, anima a los artistas de tu equipo a que se acostumbren a Gluon, una interfaz gráfica de usuario fácil de usar para simplificar su flujo de trabajo. Gluon te permite decidir en qué archivos quieres trabajar, eliminando la necesidad de descargar y gestionar todo el proyecto. También permite bloquear archivos, lo que impide que otros trabajen en ellos. Una vez que haya terminado, envíe los archivos de nuevo al repositorio y desbloquéelos de nuevo según sea necesario.

Cuando se trabaja en un proyecto de larga duración con varios ciclos de publicación, la ramificación de funciones es muy beneficiosa para el flujo de trabajo. A menudo, los equipos trabajan a partir de la misma rama de un repositorio, llamado trunk, master o main.

De este modo, todo el proyecto seguirá el mismo calendario. Sin embargo, puede ser útil dividir el trabajo en varias ramas para colaborar más eficazmente en equipo.

En Git, un flujo de trabajo específico llamado Git Flow se centra en el uso de diferentes ramas para características, correcciones de errores y lanzamientos.

Así, si un desarrollador empieza a trabajar en una nueva función dentro de una rama aislada, ésta se fusionará de nuevo con la rama principal una vez que haya terminado. Mientras tanto, otro compañero de equipo puede hacer una revisión de la versión anterior, o corregir un error, y publicar una nueva versión de forma segura, sin incluir ninguna de las características que aún están en desarrollo.

Plastic SCM también cuenta con ramas de tareas. Para este patrón, se crea una nueva rama para cada tarea de la que se hace un seguimiento. Mientras que en Git Flow, utilizamos ramas de características para desarrollar características completas, a veces grandes. Las ramas de tareas en Plastic SCM están pensadas para durar poco tiempo. Si la ejecución de una tarea requiere más de un puñado de commits, lo más probable es que pueda dividirse en tareas más pequeñas.

Perforce Helix Core utiliza un sistema llamado Streams para facilitar este estilo de flujo de trabajo. Al crear un depósito en el que trabajar, debe configurarlo como un tipo de depósito de flujo. A continuación, puede utilizar la vista Stream Graph para crear nuevos flujos. Cada flujo (que no sea el flujo principal) deberá tener un flujo padre, para que los cambios puedan copiarse aguas arriba.

Hay diferentes tipos de arroyos para diferentes propósitos. Cuando se cambia de flujo en la estación de trabajo local o se copian los cambios, sólo se fusionan los metadatos de los archivos modificados, lo que agiliza el cambio de contexto.

Una vez que hayas completado el trabajo en una rama de características, es una buena práctica utilizar pull requests para devolver tus cambios a la corriente principal del repositorio. Las solicitudes de extracción son creadas por los desarrolladores de la función o tarea. Normalmente es responsabilidad de un desarrollador senior o de DevOps revisar los cambios antes de aceptarlos en la línea principal.

Tanto Plastic SCM como Perforce disponen de herramientas automatizadas para ayudar a gestionar la fusión de ramas en la línea principal. Plastic SCM lo hace con la ayuda de Mergebot, que fusiona automáticamente las ramas de un repositorio una vez que han sido revisadas y han pasado la validación. Perforce dispone de una plataforma adicional, Helix Swarm, utilizada para gestionar las revisiones de código que también puede configurarse con pruebas automatizadas.

Incluso si trabajas en un proyecto en solitario, los principios de organización y control de versiones pueden ser realmente útiles.

Cuando se trabaja en equipo, es fundamental dar prioridad a una comunicación clara. Como grupo, tenéis que poneros de acuerdo sobre vuestras directrices: cómo debéis estructurar el proyecto, qué sistema de control de versiones utilizar y cómo debe ser el flujo de trabajo en ese sistema.

De esta forma, cuando empieces a integrar otras herramientas como Jira, GitLab, herramientas de compilación o pruebas automatizadas, el trabajo que ya has hecho estructurando tu proyecto y flujo de trabajo se verá reflejado.