Control de versiones con Git
Últimamente ando bastante engorilado con Git, por lo que este post pretende ser una introducción muy rápida de las cuatro cosillas que estoy aprendiendo sobre este VCS estos días. En siguientes entradas, o lo que es lo mismo sólo $DEITY sabe cuando, muy probablemente escribiré como montar un repositorio Git utilizando el servicio gratuito ofrecido por github.com.
En primer lugar indicar que Git es un sistema distribuido, a diferencia de por ejemplo Subversion o CVS que son centralizados. Esto para nosotros qué quiere decir? Básicamente que no trabajamos con una copia local del código fuente sino con una copia local o clon del repositorio original, más conocido como “master”.
Las ventajas más importante de trabajar de esta forma, siempre bajo mi punto de vista, son que disponemos de todas las utilidades propias del VCS sin ni siquiera tener que estar conectado a una red. Muy útil para acceder al historico de modificaciones de un fichero, comparar versiones, hacer un commit o cualquier cosa que hagas normalmente con tu VCS desde un sitio donde no dispongas de conexión.
Git define también 5 tipos de objetos alguno de los cuales nos serán familiares si hemos trabajado con un VCS antes:
- Blob: El contenido de un fichero gestionado por Git e identificable por el Hash SHA1 que se obtiene del dicho contenido.
- Tree: La estructura del repositorio en un momento determinado (normalmente un commit). Un objeto de tipo Tree tiene N objetos de tipo Blob asociados.
- Commit: Una “foto” del repositorio una vez se han introducido una serie de cambios. Un objeto de tipo commit tiene 1 objeto de tipo Tree asociado.
- Tag: Una etiqueta, normalmente sirve para marcar objetos de tipo commit.
- Índice: Imagen de los cambios que se aplicarán al repositorio en el siguiente commit. En Git, por defecto sólo aplican aquellos cambios que se encuentran reflejados en este índice (están STAGED).
Git a diferencia que otros VCS como Subversion no almacena únicamente los cambios de un fichero sino que almacena el contenido completo de cada revisión. Esto sumado a la forma de trabajar que tiene con los objetos que indiqué antes hacen que en general el funcionamiento de Git sea muy ágil y, bajo mi punto de vista, mucho menos susceptible a error (piensa que cada vez que le pides una revisión en concreto, Git no debe “montarla” sólo “localizarla”).
Sólo por estas cosillas, ya comienzo a estar tentado de cambiar. ¿Habeis trabajado con Git o similar? ¿Qué os parece? ¿Cambiaríais vuestro Subversion/CVS?
Por cierto el libro que estoy leyendo es “Version Control with Git” de la editorial O’Reilly Media por si alguien quiere echarle una leída.
