¿Te ha pasado que intentas ser tan organizado con tus archivos que terminas con múltiples versiones del mismo? Algo así:
Copiar y generar diferentes versiones del mismo archivo es un enfoque bastante fácil pero también muy propenso a errores, pues es muy fácil olvidar qué cambios tiene cada archivo y cuál es la verdadera versión final que necesitas, es ahí donde un Control de Versiones nos puede ser de mucha utilidad. Pero, ¿Qué es un Control de Versiones? en términos simples es un programa que registra los cambios realizados sobre un archivo de modo que nos facilita recuperar versiones específicas del mismo, y no sólo eso, también permite revertir cambios, ver quién ha modificado el archivo, recuperar archivos perdidos y ¡muchas otras cosas más!
Existen varios programas enfocados al Control de Versiones, en este artículo nos vamos a enfocar en Git. Creado por el fundador de Linux, Linus Torvalds, Git es un sistema de Control de Versiones con funcionalidad plena para cualquier tipo de archivo, así que no importa si eres un programador, un abogado o un estudiante, Git te puede ahorrar muchos dolores de cabeza a la hora de administrar apropiadamente tus archivos, además es un proyecto open source lo cual implica que es gratuito. Para usar Git primero hay que instalarlo y configurarlo, pero primero es necesario entender un poco más a fondo la estructura que Git ofrece.
Conociendo Git
Sí has utilizado antes un Control de Versiones, entonces sabes que hay dos etapas por las cuales pasa un archivo:
- La carpeta local de nuestra computadora: En donde creamos y editamos un archivo.
- El repositorio en donde se almacenan los archivos y sus diferentes cambios.
Git es un tanto diferente pues incluye una tercera etapa conocida como staging, que en términos simples sirve para determinar cuales archivos están listos para almacenarse en el repositorio.
Instalando Git
La instalación depende de tu sistema operativo (Windows, Linux o Mac OS), y aunque hay varias formas de instalar Git, para efectos de este artículo nos enfocaremos en la más sencilla: descargándolo. En la siguiente página puedes elegir la descarga de acuerdo al sistema operativo que uses.
Git se utiliza comúnmente a través de comandos ejecutados en la Terminal o Consola, pero si no eres amante de las consolas, hay varios sistemas gráficos que te proporcionan una interfaz amigable para usar Git. En lo personal, recomendamos utilizarlo por consola pues te permite explotar todo el potencial de Git y utilizarlo con mayor rapidez.
Nota: Para usuarios Windows, Git se puede ejecutar en la consola por default de Windows (MS-DOS), aunque como probablemente sepan es bastante limitada, entonces los invitamos a utilizar Git Bash en la cual podrás ejecutar todos los comandos de Git con mayor facilidad y así tener una mejor experiencia.
Configurando Git
Una vez que se terminó la instalación hay que configurar Git para poder empezar a usarlo, y eso es bastante sencillo, únicamente hay que indicarle a Git cual es nuestro usuario y correo para que así pueda identificarnos. En la terminal ejecuta los siguientes comandos
$ git config —global.username “Tu nombre”
$ git config —global.email tu_correo@example.com
Para poder comprobar que has configurado correctamente Git, ejecuta lo siguiente en tu terminal:
$ git config user.name
=> “Mayra Cabrera”
$ git config user.email
=> “mayra@correo.com”
Si las salidas corresponden a lo que ingresaste en los comandos anteriores, felicidades! Haz configurado Git correctamente!
Usando Git
Ahora que tenemos Git instalado y configurado, vamos a utilizarlo para organizar nuestros archivos en un proyecto. Para mostrar esto hemos creado una carpeta denominada “Proyecto Final”. En la terminal dirígete a esa carpeta y ejecuta el siguiente comando:
$ git init
Initialized empty Git repository in /Documents/Proyecto Final/.git/
Success!
Nota: Dependiendo de tu sistema operativo y la carpeta que hayas elegido, la salida se puede mostrar diferente.
El comando git init como podrás imaginar inicializa un repositorio local Git dentro de la carpeta oculta «/.git» en “Proyecto Final”. Este repositorio no está en ningún servidor, está dentro de nuestra computadora por eso se dice que es local. Para visualizar cual es el estado de nuestro repositorio, podemos hay que ejecutar el comando git status:
$ git status
# On branch master
#
# Initial commit
#
nothing to commit (create/copy files and use "git add" to track)
Git nos dice que nuestra carpeta está vacía (“nothing to commit”), y efectivamente como estamos empezando no hemos agregado ningún archivo hasta ahorita. Al agregar cualquier archivo dentro de la carpeta y ejecutar nuevamente el comando git status obtenemos la siguiente respuesta:
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# proyecto.docx
nothing added to commit but untracked files present (use "git add" to track)
“…untracked file present” Significa que Git ha notado que se ha agregado un nuevo archivo a la carpeta pero que todavía no lo está “siguiendo”. Hay que indicarle a Git que queremos que empiece a “seguir” o mejor dicho administrar este archivo, y eso se realiza a través del siguiente comando:
$ git add proyecto.docx
Ahora al ejecutar git status la respuesta de Git es diferente:
$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: proyecto.docx
El archivo “proyecto.docx” se encuentra en staging lo que significa que está listo para agregarse a nuestro repositorio local! Para agregarlo basta con hacer un commit, de esta forma le indicamos a Git que queremos agregarlo al repositorio local.
$ git commit -m "Se agrega primer versión del proyecto”
[master (root-commit) c2b5be1] Se agrega primer versión del proyecto
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 proyecto.docx
Normalmente los commits se realizan junto con un mensaje (por eso el ‘-m’) que indican muy brevemente que contiene el commit. Al ejecutar el comando git status Git nos dice que no han ocurrido modificaciones desde que se agregó el último commit.
$ git status
# On branch master
nothing to commit, working directory clean
Observa como cambia el estatus cuando se modifica el archivo “proyecto.docx” y se agrega uno nuevo archivo denominado “calendario.docx” a la carpeta “Proyecto Final”:
$ git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: proyecto.docx
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# calendario.docx
no changes added to commit (use "git add" and/or "git commit -a”)
Git es lo suficientemente inteligente para avisarnos que hay modificaciones sobre el archivo que ya se encuentra en el repositorio (“proyecto.docx”) y que existe uno nuevo que no está siguiendo (“calendario.docx”). Pero un momento, ¿qué tal si quisiéramos saber exactamente cuáles fueron las modificaciones que se le hicieron al archivo “proyecto.docx”? Bueno Git tiene un comando para eso:
$ git diff proyecto.docx
diff --git a/proyecto.docx b/proyecto.docx
index 977da50..5c5a53c 100644
--- a/proyecto.docx
+++ b/proyecto.docx
@@ -1,3 +1,4 @@
-CurioTek!
+CurioTek!: Un blog adictivo,
+¡Para que calmes tu curiosidad!
No te alarmes por todos los símbolos que ves, lo principal es lo siguiente:
- La línea en rojo antecedidas por el símbolo de “-“, indican aquellas líneas que se borraron del archivo.
- Las líneas en verde antecedidas con el símbolo de “+”, indican aquellas líneas que se agregaron el archivo.
Si tuviéramos un archivo más grande con varias modificaciones el comando git diff nos mostraría todas aquellas modificaciones de la misma forma, indicando que se borró y que se agregó, bastante útil ¿no lo crees? Una vez que estamos contentos con las nuevas modificaciones a nuestro archivo “proyecto.docx” vamos agregarlo al repositorio junto con el archivo “calendario.docx”, y para eso necesitamos ejecutar el siguiente comando:
$ git add *.docx
En este caso la sintaxis del comando git add es un poco diferente, pues especificamos que todos (*) los archivos con terminación ‘.docx’ (“proyecto.docx” y “calendario.docx”) se agreguen a staging. El mismo resultado se hubiera obtenido con los siguientes comandos
$ git add proyecto.docx
$ git add calendario.docx
Nuevamente con git status podemos ver los archivos que están en staging y que estamos a punto de agregar a nuestro repositorio:
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: proyecto.docx
# new file: calendario.docx
Como puedes observar dice modified antes de “proyecto.docx” por ser un archivo que ya se encuentra previamente almacenado, sin embargo para “calendario.docx” Git nos indica que es un new file, porque hasta el momento Git no lo está administrando. Para agregar estos nuevos cambios al repositorio hay que realizar otro commit:
$ git commit -m “Modificación al proyecto y también se agrega el calendario de trabajo"
[master b5e81c1] Modificación al proyecto y también se agrega el calendario de trabajo
2 files changed, 3 insertions(+), 1 deletion(-)
create mode 100644 calendario.docx
Ok, hasta aquí hemos mejorado nuestra organización de archivos, pero ¿qué pasa si trabajamos con un compañero? ¿cómo podemos ver las modificaciones que él ha realizado?. Bueno para esto necesitaríamos un servidor remoto que nos permita compartir información entre diferentes personas. Github nos podría proporcionar un repositorio público y gratuito que nos serviría perfectamente para este propósito, la configuración de Github con nuestro repositorio queda fuera del alcance de este artículo, pero es bastante fácil y lo puedes consultar aquí.
Suponiendo que ya tenemos configurado Github, y que nuestro compañero ya realizó sus cambios y los subió al servidor, existen varias formas en las cuáles podemos visualizar el historial de cambios o commits en nuestro repositorio, una de ellas es con git log:
$ git log
commit 0c2278f625550b6cafff5b861eff9bf08863ec72
Author: Mayra Cabrera <mayra@correo.com>
Date: Sat Jun 21 14:12:51 2014 -0500
Se agrega primer versión del proyecto
commit 38496a62926362a2447fbd3bee7f5882001cdaf3
Author: Mayra Cabrera <mayra@correo.com>
Date: Sat Jun 21 16:03:19 2014 -0500
Modificación al proyecto y también se agrega el calendario de trabajo
commit 6d0fcefb9d2649be5b80512276e8464c4b5ed496
Author: Alfredo Gordián <alfredo@correo.com>
Date: Mon Jun 22 15:01:53 2014 -0500
Se agregan los capítulos restantes
Como su nombre lo indica git log nos regresa un log o un historial de commits que se han realizado a lo largo del tiempo, indicando la persona que realizó cada commit, el día y hora en la cuál lo hizo y el mensaje por commit. Para ver específicamente cuales fueron los commits realizados por una persona, basta con indicárselo a Git de la siguiente manera:
$ git log --author="Mayra"
commit 0c2278f625550b6cafff5b861eff9bf08863ec72
Author: Mayra Cabrera <mayra@correo.com>
Date: Sat Jun 21 14:12:51 2014 -0500
Se agrega primer versión del proyecto
commit 38496a62926362a2447fbd3bee7f5882001cdaf3
Author: Mayra Cabrera <mayra@correo.com>
Date: Sat Jun 21 16:03:19 2014 -0500
Modificación al proyecto y también se agrega el calendario de trabajo
Por otro lado, para ver específicamente los cambios a un archivo en particular podemos utilizar git blame:
$ git blame proyecto.docx
38496a62 (Mayra Cabrera 2014-06-21 14:03:19 -0500 1) CurioTek!: Un blog adictivo,
0c2278f6 (Mayra Cabrera 2014-06-21 14:12:51 -0500 2) Para que calmes tu curiosidad!
6d0fcefb (Alfredo Gordián 2014-06-21 14:12:51 -0500 3) Capítulo 1
6d0fcefb (Alfredo Gordián 2014-06-21 13:35:53 -0500 4) Capítulo 2
6d0fcefb (Alfredo Gordián 2014-06-21 13:35:53 -0500 5) Capítulo 3
Con git blame podemos ver, línea por línea, qué usuario modificó el archivo y cuales fueron las modificaciones que hizo.
Esta pequeña demostración es sólo para que te des una idea de lo poderoso que puede ser Git, si quieres averiguar más (cosa que deberías) les dejamos algunas referencias bastante interesantes con recursos gratuitos:
- Curso gratuito por Code School: https://try.github.io/
Si tienes 15 minutos libres y quieres entender más de git, no dudes en tomar este curso.
- Git basics: http://git-scm.com/
En esta liga pueden leer la documentación oficial de Git
- Git Pro por Scott Chacon: http://git-scm.com/book