Tutorial Git gestión de versiones (Introducción)

Un programa de gestión de versiones permite organizar y documentar los cambios realizados en un proyecto (habitualmente código de programación). Además también nos permite deshacer cambios, exportarlos e importarlos en otros proyectos.

Es una herramienta fundamental en todo proyecto de software, sobre todo si este esta siendo desarrollado por varios programadores simultáneamente ya que esta herramienta nos permite saber en todo momento, muy fácilmente, que ha modificado otro desarrollador así como resolver conflictos entre los cambios que realiza cada uno. Después profundizaremos más sobre esto.

Antes de empezar debo decir que git esta disponible para casi todos los sistemas operativos que existen, y se puede manejar por comandos o por interfaz gráfica. Este tutorial se basará en los comandos ya que son idénticos para todas las plataformas y una vez conocidos manejar la interface gráfica es trivial.

Como instalar
En ubuntu, kubuntu, linux mint o debian desde la terminal ejecutamos:

sudo apt-get install git

Para Fedora, Centos o RHEL

sudo yum install git

En windows lo que tenemos que hacer es bajarnos el programa y seguir el proceso habitual (siguiente, siguiente…)
https://git-scm.com/downloads

Para empezar lo que vamos a hacer es crear una carpeta donde vamos a trabajar, la llamaré mirepositorio.

Ahora tenemos que acceder a la terminal, desde linux la ejecutamos desde la lista de programas y en windows desde inicio > ejecutar > cmd y desplazarnos a la carpeta que hemos creado.

Para linux: cd /ruta/de/la/carpeta/mirepositorio
Para windows: dir C:\ruta\de\la\carpeta\midirectorio

Si tienes problemas para llegar a este paso consulta una guía de manejo de la terminal en tu sistema operativo.

Ahora lo que vamos a hacer es configurar git para ello le damos un nombre de usuario y correo electrónico con el que se van a guardar tus cambios de esta forma:

git config --global user.name "4m1g0"
git config --global user.email 4m1g0@todohacker.com

Lo siguiente que tenemos que hacer es convertir la carpeta donde estamos en un repositorio. Para eso ejecutamos:

git init

Aparentemente nada ha cambiado pero ahora, se esta llevando cuenta de los cambios que habeis hecho en ese repositorio, por ahora ninguno.

Ahora vamos a hacer algún cambio, por ejemplo podemos añadir un nuevo archivo de texto que ponga «Hola, gracias por visitar TodoHacker» y hacemos un git status para ver que ha cambiado

git status

Como vemos nos dice que hay archivos sin seguimiento y nos los lista, en este caso solo 1. Por ahora ese cambio está en lo que se llama nuestro Workspace, nuestro espacio de trabajo, y no lo podrá ver nadie, ni tampoco quedará guardado en el sistema de versiones por ahora, así que podemos seguir haciendo modificaciones o editando nuestro archivo.

En el momento en que decidamos que el cambio es significativo y queramos documentarlo como una nueva versión de nuestro proyecto debemos hacer lo siguiente.

git add archivo1.txt

(obviamente archivo1.txt debe ser sustituido por el nombre que le hayáis puesto al archivo)

Si el comando no dice nada quiere decir que todo ha funcionado correctamente.

Consejo: git permite usar comodines en los comandos, por ejemplo: git add *.txt (añade todos los archivos con extension.txt) si agregas un archivo por error al repositorio, puedes deshacer el entuerto usando git rm –cached archivo1.txt antes de hacer commit.

git rm --cached archivo1.txt

Una vez hecho esto el nuevo archivo pasa a formar parte de nuestro proyecto, pero por ahora aún no hemos confirmado los cambios que hemos hecho en el. Para confirmarlo debemos hacer git commit -m seguido del mensaje que queramos adjuntar para describir el cambio que acabamos de realizar, estos mensajes que añadimos con cada cambio van a ser muy importantes para que otros desarrolladores vean rápidamente que estamos haciendo e incluso para nosotros mismos en caso de una revisión futura.

git commit -m'Añadido nuevo archivo: archivo1'

Nota: sin usar la función -m funcionaría igualmente y al pulsar enter muestra un editor de texto en el que se puede escribir cómodamente la descripción, sin embargo yo suelo hacerlo siempre con la opción -m por que es más rápido excepto cuando el cambio requiere una explicación de varias lineas.

Una vez hecho esto tenemos nuestro cambio registrado en el sistema de versiones y podemos consultarlo con el comando git log.

git log

Si te fijas el commit muestra la descripción, y tus datos, además de esto verás un código de este tipo: 20cc6fbcab98068395bbfd0dd36. Eso es la referencia del commit, tenlo en cuenta por lo que usaremos más adelante en el tutorial.

El siguiente paso es hacer una modificación en nuestro workspace, vamos a añadir más lineas al archivo que habíamos creado y modificar la existente, en la siguiente imagen puedes ver los cambios que he hecho.

Como puedes ver, el git status muestra que hay cambios en el archivo1.txt pero no están añadidos para hacer commit. Más abajo he puesto git diff, este comando, por defecto, permite visualizar los cambios que hay en mi workspace y es muy útil ejecutarlo antes de hacer un commit para revisar lo que hemos cambiado y comprobar que todo esta bien. La sintaxis es muy simple, si la linea esta precedida por un signo menos «-«, se elimina y si esta precedida por un signo mas «+», se añade, las lineas que no tienen nada al principio son lineas de referencia, que no se modifican.

El siguiente paso es añadir los cambios que hemos realizado al repositorio y hacer un commit, esta parte ya nos la sabemos: git add archivo1.txt (para añadir los cambios de ese archivo) y git commit.

git add archivo1.txt
git commit -m'Corregido archivo1 y añadida una mejor descripcion del tutorial'

Consejo: Es una buena practica que los mensajes de commit sean claros y expliquen resumidamente los cambios que estas haciendo y a que afectan, de esta forma otra persona que lo lea (o tu mismo más adelante) podrá hacerse una idea de lo que se arregla sin tener que leer el codigo.

Por último comentar que cuando tu eliminas físicamente un archivo del workspace, este no desaparece del repositorio automáticamente, de forma análoga a cando creamos un archivo tenemos que hacer git add archivo, al borrarlo tenemos que hacer git rm archivo, por ejemplo:

git rm archivo1.txt

Consejo: Si tienes varios cambios en tu workspace y quieres hacer commit de todo, a veces es incomodo tener que hacer add de todos los archivos modificados y rm de todos los borrados. Para evitarnos esto existe el modificador -a, que agrega todos los cambios que haya y elimina todos los archivos que ya no existan en el workspace.

git commit -a -m'Esto es un cambio nuevo'

Como trabajar de forma remota
Si has llegado hasta aquí ya tienes los conocimientos básicos para hacer tus propios commits y llevar un control de versiones en tus proyectos, pero lo habitual es que trabaje más de una persona en el mismo proyecto, o aun que estés trabajando tu solo, lo más habitual es que se trabaje sobre un repositorio remoto.

Hay muchos servicios de hosting gratuitos, el que vamos a usar en este tutorial es https://github.com/. Lo primero de que debes hacer es crear una cuenta en esa web, una vez hecho tendrás la posibilidad de crear un repositorio vacío.

Nota: Es posible que te de la opción de inicializar el repositorio con un readme, en este caso vamos a elegir la otra opción: «repositorio vacío» al final de este tutorial entenderás que implica la otra opción.

Una vez hecho nos llevará a una pantalla como la siguiente:

Puedes ver que al lado de la url del repositorio hay dos opciones: HTTPS y SSH en este caso vamos a seleccionar HTTPS, la opción de SSH tiene muchas ventajas pero no están dentro de los objetivos de este tutorial.

Lo primero que tenemos que hacer ahora es añadir una rama remota, por ahora el nombre poco importa, la idea es que vamos a decirle a nuestro repositorio que hay una copia en internet en una url, no te preocupes mucho por la sintaxis de este comando por ahora, para ello:

git remote add origin [TU URL]

En el espacio de la url debes añadir la que aparece en tu github, en mi caso seria: https://github.com/4m1g0/mirepositorio.git (Asegurate de que estas añadiendo la version HTTPS y no SSH)

Ahora vamos a enviar a github, todos los commits que habíamos hecho hasta ahora, nuevamente, no te preocupes demasiado por la sintaxis de este comando por ahora.

git push -u origin master

Este comando te pedirá tu usuario y contraseña de github. Una vez ejecutado satisfactoriamente podrás navegar por la web de github un poco y verás que puedes ver los commits detallados, navegar por los archivos, etc.

Ahora podemos seguir trabajando en local normalmente, hacer tantos adds y commits como queramos, y en el momento en que queramos compartir esos commits enviarlos a github:

Vamos a hacer una modificación más en nuestro workspace, esta vez añadiremos un archivo nuevo: archivo2.txt con este texto:

Volverán las oscuras golondrinas
en tu balcón sus nidos a colgar,
y, otra vez, con el ala a sus cristales
jugando llamarán;
pero aquéllas que el vuelo refrenaban
tu hermosura y mi dicha al contemplar,
aquéllas que aprendieron nuestros nombres...
ésas... ¡no volverán!

Añadimos los cambios en este nuevo archivo y hacemos commit.

git add archivo2.txt
git commit -m'Añadido poema de Bécquer'

Una vez hecho esto tenemos los cambios en local y pero como puedes ver en la pagina de github nada ha cambiado.
Para subir estos cambios tenemos que utilizar el comando «git push»

git push

Una vez hecho esto podrás ver los nuevos cambios en la web.

Manejar cambios entre varios desarrolladores
Hasta este punto del tutorial, sabes como hacer tus cambios y publicarlos, pero ¿que pasa si otra persona esta publicando cambios al mismo tiempo? Para esta parte del tutorial vamos a simular 2 usuarios, usuario A eres tu, y usuario B en un amigo que te esta trabajando contigo.

El usuario B no tiene en local su carpeta con los archivos del proyecto, así que le pasas la url de tu repositorio (version HTTP), en mi caso: https://github.com/4m1g0/mirepositorio.git

git clone https://github.com/4m1g0/mirepositorio.git repositorio2

Con ese comando el usuario B descargará los archivos que hay en tu repositorio en una carpeta llamada «repositorio2» que se generará automáticamente. Una vez hecho esto el usuario B podrá hacer los commits que quiera en local y subirlos, de la misma manera que hemos visto anteriormente.

Vamos a suponer que B hace los cambios que aparecen en la imagen y los sube al repositorio de github.

Ahora el usuario A tiene una copia del workspace desactualizada, por que los cambios que ha hecho el usuario B (y que ya aparecen en la web) no están en su repositorio local. Para arreglar esto se usa el comando git pull que descarga todos los commits que te faltan.

git pull

Hasta aquí ningún problema, pero ¿Qué pasa si tu ya habías hecho modificaciones en tu copia local?

Vamos a suponer que el usuario B ha hecho las modificaciones anteriormente mostradas, pero tu aun no has actualizado tu repositorio y cambias algo, por ejemplo eliminamos el archivo1.txt y hacemos commit, ahora al intentar subir los cambios nos va a dar el siguiente error:

Nos dice que el último commit que hay en el repositorio remoto es más reciente que los que tienes tu, es decir que estás desactualizado, y que tendrás que mezclar los cambios remotos con los que tienes tu. Lo que vamos a hacer es bajarnos los cambios remotos, para ello usamos git pull normalmente y veremos que automáticamente nos abre un editor de texto con un mensaje de commit: «Merge branch master of…», simplemente guardamos y cerramos el editor.

git pull

Una vez hecho esto tenemos nuestro repositorio actualizado con todos los cambios, los que había hecho el usuario A y los del usuario B, el programa es suficientemente inteligente como para saber que mantener de cada uno de los cambios, sin que nosotros hagamos nada. Esto es así siempre que hayamos modificado archivos distintos o incluso dentro del mismo archivo si los cambios son muy diferenciados. El problema está en si ambos usuarios cambian las mismas lineas al mismo tiempo, en ese caso el programa no sabe que hacer y te preguntará, no obstante es un tema amplio que abarcaré en otro tutorial sobre git avanzado.

Mi recomendación es que si trabajas en grupo, subas tus cambios lo antes posible por que en caso de conflicto cuanto menores sean los cambios más simple será mezclarlos.

Git es mucho más extenso que esto, pero confío en que si has llegado hasta aquí comprendiendo todo, puedas defenderte perfectamente trabajando en cualquier repositorio de pequeñas dimensiones y si estás interesado en conocer más sobre git (Técnicas de merge, Ramas/Branches, rebase, rollaback, etc) no te pierdas el tutorial de git avanzado de TodoHacker.com en el que estamos trabajando.

¡Si tienes cualquier duda o sugerencia no dudes en añadir un comentario!

Tutorial de git (introducción) by 4m1g0 is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Based on a work at https://todohacker.com/tutoriales/tutorial-git-gestion-de-versiones.