Control de Versiones

¿Qué es?
Es un software que facilita el trabajo de un programador.

• Se podría considerar como el deshacer de un editor de textos pero para el código fuente.

• Permite a múltiples programadores trabajar sobre el mismo código de manera controlada.

• Mantiene un registro de los cambios realizados.

• Permite llevar múltiples versiones del código mientras se continua trabajando sobre dicho código.

¿Qué se debería guardar?
Para saber que debemos guardar en el repositorio haz la siguiente pregunta: ¿Si no tengo una versión actualizada de x, ¿podría compilar, probar y distribuir la aplicación? Si la respuesta es no, entonces x debe guardarse en el repositorio.

Además de los ficheros anteriores, también se debe guardar cualquier cosa que ayude a entender la aplicación, ya sea documentación interna o externa, el texto de los correos electrónicos que hayan sido importantes en el desarrollo de la aplicación, información,....

No se deben guardar los ficheros que se pueden generar con ficheros ya existentes, por ejemplo: la documentación que generamos mediante la documentación incluida en el código fuente usando herramientas auxiliares.

Tags - Etiquetas
Es un nombre que se asigna a un conjunto de ficheros en un estado determinado del proyecto. De este modo podemos recuperar esos ficheros tal y como estaban en ese momento.

Branches - Ramas.
Se llama Trunk a la rama principal del código donde se trabaja normalmente. Es decir, los ficheros del repositorio donde hacemos los cambios diariamente.
Pero, si estamos próximos al lanzamiento de la aplicación, no podemos añadir más funcionalidad pues esa funcionalidad será para una futura versión, y seguramente no estará termianda para el lanzamiento de la aplicación. Entonces, lo que podemos hacer es crear una rama que contendrá el código fuente para una determinada versión de la aplicación. Es lo que se conoce como release branch.

Cuando creamos una rama tenemos 2 proyectos con un futuro distinto para cada uno de ellos. De esta manera tenemos el código de la aplicación que vamos a lanzar y el de la futura versión perfectamente diferenciados.
Si después del lanzamiento de la aplicación se encuentran fallos se corregirán en la rama correspondiente, así podemos generar la misma versión con los fallos corregidos, y esos cambios para reparar el bugs en la release branch se fusionan con la rama principal o trunk branch.

En general, un proyecto tendrá una rama principal (trunk), y por cada lanzamiento podemos añadir otra rama (release branch). Una release branch no cambia mucho durante su vida, sólo para corregir los fallos que se puedan encontrar.

Los cambios significativos en la vida de un proyecto se marcan amenudo con etiquetas. Una etiqueta podría contener el código usado para lanzar una determinada versión de la aplicación.

Merging - Fusionando.
Esos cambios se deben añadir también a la rama principal para que estén corregidos en la próxima versión.
Se pueden fusionar los cambios hechos para fijar el error en la rama correspondiente con la rama de la siguiente versión sin usar el copiar y pegar.
Mantener el código entre las distintas ramas puede ser complicado, por eso es recomendable no tener muchas ramas.

Logs
Cuando un fichero es modificado y puesto en el repositorio se puede añadir una nota. En esa nota no se explica el cambio realizado, ya que este se puede obtener al ver las diferencias entre los ficheros. Lo que debemos poner en el log es el por que se ha realizado el cambio. Si el cambio es para fijar un bug se debe poner la identidad del bug en la aplicación que usemos para llevar el control de errores.