Cuando no se ha trabajado en el sector de desarrollo de software y no se utilizan o conocen las herramientas adecuadas, lo habitual es que las distintas versiones de los archivos de nuestro trabajo se parezcan a la siguiente lista:

• Fotos de la boda.zip
• Fotos de la boda v2.zip
• Fotos de la boda FINAL.zip
• Fotos de la boda FINAL (ahora sí).zip
• Fotos de la boda FINAL definitiva.zip
• Fotos de la boda FINAL definitiva revisada.zip

Del mismo modo cuando hacemos una copia de seguridad en “la nube”, como puede ser el servicio Drive de Google, se puede configurar para que guarde versiones incrementales de los archivos que vamos subiendo; sin embargo, ninguna de esas soluciones son óptimas cuando nos enfrentamos a dos problemas:

1. Gestionar un gran número de archivos de forma que tengamos un histórico de los cambios realizados y una copia de seguridad fiable.
2. Que varias personas puedan trabajar simultáneamente sobre un mismo proyecto.,

¿Qué hacemos entonces? ¿Cómo podemos solucionar esta situación? Con algo que se llama VCS (Version Control System) o Sistema de Control de Versiones en español.

Pero, ¿qué es exactamente un VCS?

Sin entrar en muchos detalles es un conjunto de elementos de software que permite guardar un histórico de cambios sobre los archivos que conforman un proyecto, mantener un respositorio de los mismos y gestionar distintos usuarios realizando cambios de forma simultánea. Existen un gran número de ellos que dan solución a estas necesidades de formas diferentes: Subversion, SourceSafe, Mercurial y muchos otros; sin embargo mi favorito es con diferencia Git.

¿Cómo funciona Git?

La idea detrás de Git es que cada miembro del equipo tiene una copia del proyecto sobre el que puede realizar cambios y, cuando estos han finalizado, se envían al repositorio principal y se unen en él.

Lo interesante de Git es que guarda los cambios, y sólo los cambios, siendo bastante más ligero y rápido que otros VCS además de que, por la forma en está planteado, gestiona el desarrollo no lineal de una forma excepcional. Me explicaré: ¿cuántas veces ocurre que, por hacer una prueba cambiando una función, el proyecto nunca vuelve a funcionar? Tristemente muchas. ¿y si queremos probar una locura sin comprometer lo que ya tenemos funcionando? ¡Pues a crear una copia del proyecto y luego hacer filigranas para meter en el proyecto real lo que nos interesa!

Pues con Git podemos gestionar esto de una forma muy ingeniosa: las ramas. Una de las formas más sencillas de entender como funcionan las ramas es pensar de la siguiente manera: tenemos el tronco del proyecto principal y, de este, podemos sacar copias para desarrollar ideas o para que distintos programadores puedan trabajar en distintas funcionalidades sin afectar al proyecto y, además, hacerlo de forma paralela al sistema en producción.

Obviamente no es un sistema perfecto y, no pocas veces, se producirán conflictos entre los cambios realizados en distintos momentos del desarrollo y por que distintos programadores modifiquen áreas comunes del proyecto; sin embargo, es muy sencillo resolver estos conflictos y mantener el sistema funcionando correctamente.

Y, ¿cómo uso Git?

Es importante entender que Git se puede usar en local o con un repositorio remoto. Para trabajar con Git en local hay dos formas principales de hacerlo: en línea de comandos y con una inferfaz gráfica. En mi experiencia, para proyectos que sean principalmente código dónde el uso de la consola es continuo (como puede ser un desarrollo PHP para LAMP desde un equipo con Windows, por ejemplo) resulta mucho más cómodo el uso de programas como GitBash que nos permiten gestionar nuestro repositorio Git desde el prompt.

Una alternativa que me gusta por su simpleza, con una interfaz totalmente gráfica, que va bastante bien para desarrollos con archivos más pesados: SourceTree.

El proceso de trabajo con Git es el siguiente: cada vez que completamos una funcionalidad, o una parte importante de ella, y el código es estable hacemos una “fotocopia” del estado actual del proyecto (lo que se llama un commit). Si estamos trabajando en una rama distinta de la principal y queremos que la funcionalidad pase a formar parte del proyecto, solicitamos al responsable del proyecto (o lo hacemos nosotros si somos esa persona) una fusión (merge) de nuestra rama con la rama principal.

Repositorios remotos

Pero, ¿como trabajamos varias personas con un mismo proyecto y, además, tenemos una copia de seguridad de nuestro proyecto? Con un repositorio remoto. Como ya sabemos, “la nube” no es más que el ordenador de otra persona y, por tanto, necesitamos un servidor que acepte y gestione nuestro repositorio. Y hay muchos, siendo los más habituales:

• GitHub:
  • Pros en relación a los demás:
    • Es el respositorio de los proyectos de Software Libre por definición.
    • Muchos programadores tienen una cuenta aquí como portfolio profesional.
  • Contras en relación a los demás:
    • Los proyectos privados requieren tener una cuenta de pago.
• GitLab:
  • Pros en relación a los demás:
    • Permite tener proyectos privados.
    • Gráficamente es bastante atractiva.
• Bitbucket.
  • Pros en relación a los demás:
    • Permite tener proyectos privados.
    • Con proyectos de Unity simples va muy bien.

He trabajado con los tres  y todos han cumplido correctamente; por tanto, la elección entre unos y otros se reduce prácticamente a una cuestión personal y de pequeños detalles.

En resumen

Cuando se trabaja en un proyecto es recomendable tener, de alguna forma, automatizado el proceso de gestión de cambios, la concurrencia y las copias de seguridad. Los sistemas de control de versiones permiten realizar esto y, entre ellos, Git sobresale por su comodidad, simpleza y robustez.

Así que si aún no sabes usarlo, ya estás tardando en aprenderlo porque será tu mejor aliado cuando cualquier proyecto empiece a crecer.