Introducción a Git desde cero

Hoy en día, no es raro que un grupo de programadores estén repartidos por distintos países y zonas horarias mientras colaboran en un proyecto. Los sistemas de control de versiones distribuidos, como Git, son los que hacen esto posible. La creación de una aplicación hasta la adición, prueba y envío de nuevas características comienzan en una introducción a Git desde cero.

Esta serie de guías no pretende ser una referencia completa sobre Git, sino una visión general del trabajo colaborativo en el desarrollo de software. Antes de empezar, asegúrate de que la herramienta de la línea de comandos (git) está instalada en tu sistema. Si necesitas ayuda para verificarlo, te recomendamos repasar Software en Linux: instalación mediante línea de comandos.

Un poco de historia

Hasta principios de la década de 2000, los programadores solían compartir su trabajo de persona a persona. A medida que un proyecto sumaba más colaboradores, este método se volvió lento, propenso a errores y poco eficaz. Los sistemas de control de versiones nacieron para dar respuesta a esas necesidades. Con esas herramientas, los desarrolladores pudieron hacer las mismas tareas más fácilmente.

En 2002, la comunidad del kernel Linux fue una de las primeras en adoptar un sistema de control de versiones conocido como BitKeeper. Algún tiempo después, Linus Torvalds ideó Git y lo lanzó en mayo de 2005 tras un conflicto con BitKeeper. Dos meses después, un ingeniero de software japonés llamado Junio Hamano fue nombrado mantenedor, función que sigue desempeñando hasta hoy.

Las soluciones basadas en la web, como GitHub, Bitbucket o GitLab, no deben confundirse con Git propiamente dicho. Estas herramientas sólo proporcionan espacio para almacenar código en la nube y una interfaz amigable para realizar diversas operaciones. En estos posts utilizaremos GitHub, pero el proceso es muy similar si eliges una de las otras opciones.

Términos frecuentes

Antes de seguir avanzando, conviene definir algunos términos comunes que encontraremos más adelante:

• Un repositorio es una carpeta que contiene los archivos y subdirectorios de un proyecto. Puede ser público o privado, dependiendo de quién deba tener acceso.
• Una rama es una ruta de desarrollo separada en el mismo repositorio. En un mismo proyecto suelen utilizarse ramas separadas para trabajar en nuevas características sin interferir con la versión de producción. Una vez que el código es revisado y probado, un administrador del repositorio puede fusionar los cambios en la rama principal.
• Un commit es una instantánea de un repositorio en un momento dado. Permite a los programadores incluir comentarios y pedir la opinión de otras personas. Usando el hash que lo identifica puedes volver a un estado anterior del proyecto si es necesario. Antes de que los archivos y directorios puedan ser comiteados, necesitamos decirle a Git que los rastree. Normalmente nos referimos a este paso simplemente como agregar los archivos al área de staging.
• Un pull request (o simplemente PR) es un método para informar a otros desarrolladores y discutir los cambios recientes antes de incorporarlos a la ruta de desarrollo principal.
• Un fork es un proyecto independiente que se basa en un repositorio determinado. A diferencia de las ramas, no es local a este último. Sin embargo, también puede fusionarse con él a través de un pull request adecuado.
• Se puede utilizar un archivo .gitignore para indicar qué contenido local no queremos incluir en el repositorio. Esto nos ayuda a evitar enviar archivos temporales o exponer información sensible en una solución basada en la web.

Con esto en mente, vamos a hacer una introducción a Git desde cero y aprovechar GitHub para un proyecto de desarrollo de software. Aunque sencillo, el ejemplo que vamos a trabajar en los próximos posts nos ayudará a ilustrar los conceptos fundamentales de los sistemas de control de versiones. ¡Nos leemos en breve!