Categories
Default

Git: Introducción (en Español)

Finalmente tengo un poco de tiempo para actualizar el blog. Estos últimos meses han estado llenos de cambios y cosas nuevas que mas adelante tocaré en un post dedicado a ese tema. Hoy quiero compartir un poco sobre sistemas de control de versiones y específicamente sobre Git. Este post servirá como una introducción a una serie de tutoriales (muy simples) sobre Git que estaré publicando en las próximas semanas.

Git es un sistema de control de versiones (SCM). Este tipo de sistema, como el nombre sugiere, permite llevar un control de revisiones de documentos dentro de un proyecto. Así cada vez que un archivo cambia este sistema se da cuenta de esos cambios y genera una nueva versión. Esto permite mantener un historial de todos los cambios que se han hecho y de ser necesario llevar a un archivo o todo el proyecto a un estado anterior (antes de introducir un bug) entre otros beneficios.

La verdad es que siempre he leído sobre SCM pero no fue hasta hace solo dos años que empecé a usar uno. Mi primera elección fue Subversion (SVN). En ese momento la decisión fue fácil. Había estado mirando unas cuantas descripciones de empleo de algunas compañías (solo por curiosidad) y en ese momento todas requerían conocimiento en SVN.

Bueno: SVN es un SCM muy poderoso y comúnmente usado. Hay mucha documentación y es bastante fácil de manejar en el día a día. Una vez queda configurado y funcionando no hay que tocarlo.

Malo: SVN es un sistema centralizado (lento), la configuración inicial puede ser un poco tediosa y guarda folders (.svn) en todos los directorios de tu proyecto. Esto ultimo me molesta por razones mas estéticas que otra cosa. Es muy fácil librarse de estos archivos con un simple svn export.

Para que uso un SCM
Mi trabajo se centra en aplicaciones web. Trabajo todo el tiempo con CodeIgniter y jQuery. Esas son mis dos herramientas principales. Regularmente trabajo solo en pequeños proyectos y en ocasiones trabajo en proyectos mucho mas grandes (s3mer) con varios developers. En mi experiencia he encontrado que tanto en proyectos individuales como en proyectos en equipo usar un sistema de SCM me ayuda mucho.

He tomado la costumbre de crear un repositorio para cada proyecto en el que trabajo. Cada vez que completo una tarea hago un commit y añado buenos comentarios para mas adelante poder identificar esa revisión. Esto me ha salvado la vida un par de veces cuando por ejemplo hago cambios en varios archivos y esto inserta un problema inesperado, simplemente vuelvo a una versión anterior y listo.

En proyectos con varios developers es muy obvia la necesidad de un SCM. Si tienes a varias personas alterando los mismos archivos constantemente es inevitable que en algún momento esos cambios van a  ser a un mismo archivo y un buen SCM ayuda a resolver esos problemas sin perder el tiempo de los developers.

Otra forma en que usar un SCM me ha ayudado es en el momento de deploy una aplicación al web. Lo que hago es que pongo en el servidor publico un working copy del proyecto así cada vez que hago un cambio en el proyecto es muy fácil actualizar la copia que está en el site publico. Esto ha sido especialmente importante al momento de trabajar aplicaciones para Facebook (FB) porque mi código (FBML Canvas Page) debe estar online para que los servidores de FB puedan llegar a ellos y presentarlos dentro de su site. Usando un SCM se puede configurar lo que se llaman hooks. Estos son acciones que se ejecutan en momentos específicos durante la operación de un SCM. Para desarrollos de FB casi siempre hago un post-commit hook esto es una acción que se ejecuta luego de un commit. En esta acción pongo un script que se conecta a mi servidor publico y actualiza la copia que está ahí. De esta manera cada vez que hago un cambio en el código solo tengo que hacer un commit en mi maquina y los cambios llegan automáticamente al site público.

¿Porque Git?
Cuando primero escuché de Git fue cuando me enteré que el proyecto Ruby on Rails lo estaba usando para manejar su código. Esto llamó rápidamente mi atención porque en ese momento estaba aprendiendo sobre Rails. Definitivamente el que proyectos como RoR, Linux Kernel, Perl, Gnome, Android, Fedora, Debian, Wine y otros estén usando este SCM tiene mucho que ver con mis deseos de probarlo. Pero la razón real detrás de porque me cambié de SVN a Git es la velocidad.

Ya no tengo que esperar por nada. Todo pasa muy rápido porque pasa en mi computadora sin necesidad de ir a un servidor hasta cuando yo le diga que tiene que hacerlo. Todos los cambios y todas las versiones están en mi maquina. En cualquier momento puedo hacer un checkout de otro branch sin necesidad de estar conectado al internet.

Otra razón es el tamaño de los repositorios. Por alguna razón Git es muy eficiente al momento de guardar las revisiones. Todos los proyectos que moví de SVN a Git ocupan menos espacio en mi disco duro.

Bueno: Descentralizado, rápido, fácil de usar, bueno para proyectos individuales, configuración muy sencilla.

Malo: La documentación que he encontrado no es muy buena.

Git me ayuda a principalmente a en mis proyectos individuales. Es muy fácil crear un repositorio nuevo, añadir archivos y empezar a trabajar. Cada cierto tiempo haces un commit nuevo y listo ya tus cambios están seguros.

Durante las próximas semanas estaré añadiendo unos posts sobre como usar Git. Espero en estos posts poder explicar mas claramente las ventajas de Git. Los posts serán tipo tutorial, para que puedan hacer un poco de copy/paste para empezar con sus proyectos.

Seguir a Tutorial 1 >>