Git (escencial)

En este artículo se muestra el manejo básico del sistema de versionamiento de código git, también algunos tips para aprovechar sus funcionalidades.

Sistema de versionamiento

Un sistema de control de versionamiento de código (VCS en inglés) es un sistema que permite mantener versiones de un trabajo que se desarrolla, por ejemplo al escribir código a medida que se avanza en un programa puede darse el caso de necesitar que los archivos vuelvan a un estado anterior al actual. Los sitemas de versionamiento de código son las herramientas indicadas para ello, así si hemos hecho cambios problemáticos en nuestro código podemos cambiar el código a una versión anterior que no tenía problemas (o al menos no tantos ;) ).

Los sistemas de versionamiento no se limitan a código, sirven también para cualquier archivo.

Existen los CVCS (sistemas de versionamiento centralizado tales como svn) y los DVCS (sistemas de control de versionamiento distribuido como git y bazaar), sólo veremos git por lo que los CVCS no se abarcarán en este artículo.

Empezar a usar git

Requerimientos

Una pc con git instalado y una shell para introducir comandos, si no se tiene instalado git hay que instalarlo en un sistema basado en Debian bastaría con

apt-get install git

Como trabaja git

Lo primero es entender como git considera los cambios en los archivos.

Snapshots y no cambios en los archivos

Git hace "snapshots" en los archivos (es como tomar imágenes de un archivo para ver como luce), a medida que una va haciendo commits git hace snapshots de los archivos considerados y almacena una referencia a ese snapshot. Pero al hacer un nuevo commit git sólo almacena los snapshots que han cambiado.

Un ejemplo claro de esto es cuando uno inicia git, se hará un snapshot incial de por ejemplo un arhcivo. Luego se modifica ese archivo por ejemplo borrando una letra y luego volverla a escribir en el mismo lugar y luego guardar el archivo, para el sistema operativo u otros sistemas de versionamiento el archivo cambió pero en realidad el archivo luce exactamente igual.

Para git este archivo no cambió en lo absoluto y por eso al hacer de nuevo un snapshot git no registrará ningún cambió en el archivo por que los snapshots de ambos lucen iguales.

En cambio si el archivo cambío en al menos una letra los snapshots lucirán distintos y para git este cambio debe ser tomado en cuenta.

Es virtualmente imposible que git no note un cambio en los archivos bajo el principio mencionado arriba. Esto por que git usa algoritmos de checksum en este caso sha-1 hash

Tres estados

Git hace que los archivos estén en uno de tres estados y estos son:

Modificado =

El archivo has sido modificado ero no ha sido marcado para el siguiente commit.

Marcados para commit (staged) =

Es cuando un archivo modificado ha sido marcado para que en el siguiente commit se tome un snapshot de este y se almacene en la base de datos del commit hecho. Cuando un archivo modificado ha sido marcado para ir en el siguiente commit se dice que ese archivo esta en el archivo conocido como índice' o staging area.

Comiteados (commited)

Significa que el archivo esta apropiadamente almacenado en la base de datos correspondiente al commit hecho. Esto sucede sólo con los archivos tomados en cuenta y luego se hace el uso de git commit

Referencias

• http://www.git-scm.com/book/en/v2