Es este post voy a hablar un poco de los sistemas de control de versiones (VCS), fundamentalmente de los repositorios de código distribuidos y en particular de Git.
Repositorios de código distribuidos
En los últimos años la tendencia dentro del desarrollo de software es pasar de repositorios de código centralizados a repositorios distribuidos.
En los repositorios centralizados, como su propio nombre indica, hay un único repositorio central contra el que se sincroniza todo el mundo y es en este repositorio donde se almacena el código y se mantiene toda la información del proyecto: histórico, ramas, etiquetas, etc.. Sus principales ventajas son que todo desarrollador sabe donde está el repositorio y además “puede saber” lo que están haciendo los otros y para los administradores es fácil gestionar los permisos y el propio repositorio en si. Y las principales desventajas son que al ser único cualquier problema en el mismo puede llevar desde su posible inaccesibilidad temporal hasta la pérdida de toda la información, si no se tienen unos correctos y probados procedimientos de backup y recuperación. Son ejemplos de este tipo: CVS y Subversion.
Los repositorios distribuidos son aquellos en los que la idea de un repositorio central no existe como tal, éste está distribuido, es decir cada uno de los desarrolladores tiene una copia en local con toda la información: históricos, ramas, etiquetas, etc. con lo que no se necesita estar conectado para realizar operaciones contra el repositorio. Cuando el grupo de trabajo es grande se puede disponer de un lugar donde mantener una copia pública del repositorio, como GitHub o Gitorius, para no tener que estar sincronizando continuamente con el de los demás miembros del grupo, pero no sería imprescindible. Una ventaja de este sistema es que si hay algún problema con el servidor donde se mantiene la copia pública del repositorio se podría montar uno nuevo simplemente copiando el contenido de “cualquiera” de los repositorios locales de cualquiera de los desarrolladores. Al trabajar contra el repositorio local también se gana en velocidad ya que no es necesario acceder a la red para realizar las actualizaciones pero al cargarlo por primera vez se descarga una copia completa con lo que esta primera acción puede ser costosa. Que cada uno disponga de una copia del repositorio podría llegar a crear grandes divergencias en el código si no se realiza de forma cuidadosa y organizada, pero esto también puede suceder en los repositorios centralizados es, en principio, una cuestión de trabajo organizado en grupo. Son algunos ejemplos de este tipo: Git, Mercurial, Bazaar y Darcs.
Git, un poco de historia
Git fue desarrollado en 2005, inicialmente por Linus Torvalds, creador del kernel de Linux, para el mantenimiento de dicho kernel. Para su creación surgieron dos razones fundamentales, la primera que se rompió el acuerdo para usar la licencia de forma gratuita con, BitMover, la empresa que desarrollaba BitKeeper, software privativo de control de versiones distribuido que usaban desde 2002, por desavenencias con la comunidad de desarrolladores ya que dicho acuerdo les impedía trabajar en productos libres que fuesen competencia directa suya, siendo la gota que colmó el vaso para BitMover el desarrollo por parte de Andrew Tridgell de un cliente libre de BitKeeper. Y, la segunda, que ninguno de los sistemas de control de versiones que existían en esos momentos cumplía los requisitos que necesitaban que eran fundamentalmente:
- Velocidad
- Diseño sencillo
- Fuerte soporte para desarrollo no lineal (cientos de ramas en paralelo)
- Totalmente distribuido
- Capaz de manejar grandes proyectos de forma eficiente (velocidad y tamaño de datos)
Por tanto, Git es un sistema de control de versiones distribuido diseñado para gestionar proyectos grandes y pequeños de forma eficiente y rápida. Es software libre con licencia GPLv3. Hay disponibles versiones para Linux, Solaris, Mac OS X y Windows.
Instalación de Git
La instalación de Git es muy fácil, en Ubuntu sólo hay que hacer:
$sudo apt-get install git-core
Configurando Git
Lo primero es decirle a Git quienes somos para que sepa quien está realizando la tareas sobre el repositorio. Esto se puede hacer de forma global (–global) o por repositorio independiente.
$ git config --global user.name "Suso" $ git config --global user.email "suso@suso.com"
De forma global crea el fichero .gitconfig en el home del usuario. Si queremos sobreescribir esta información en alguno de los repositorios locales ejecutaríamos lo mismo pero sin la opción global dentro del directorio raíz del repositorio, de esta forma se modificaría el fichero .git/config.
Inicialización del repositorio
Lo primero que vamos a hacer es crear un directorio donde realizaremos el desarrollo de software y del que queremos generar el repositorio. Mediante init vamos a crear el repositorio local asociado a ese directorio. Con este paso hemos creado ya el repositorio local.
$ mkdir android $ cd android $ git init
Trabajo en repositorio local
Git tiene una forma de trabajar peculiar porque usa una especie de índice intermedio donde vamos añadiendo los ficheros antes de subirlos al repositorio local. Esa tarea se hace mediante la opción add. Una vez finalizada la edición de los ficheros, todos los que queramos subir al repositorio antes tienen que ser añadidos de esa forma. Para saber que ficheros están esperando a ser subidos se puede hacer de dos formas, bien con la opción diff o con la opción status. Para finalizar, mediante la opción commit se suben o actualizan en el repositorio local.
$ git add main.c server.c server.h $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: main.c # modified: sercer.c # modified: server.h # $ git commit
De esta forma ya tenemos nuestro repositorio local actualizado.
Trabajo con repositorios remotos
Pero si queremos tener una copia de nuestro repositorio en un lugar público para compartir nuestro código o para mantener una copia de seguridad podemos usar:
- git pull . Bajamos las actualizaciones de un repositorio remoto.
- git push. Subimos nuestras modificaciones a un repositorio remoto.
- git clone git://github.com/suso/Git_test.git. Hacemos un clonado en local del repositorio remoto Git_test
Aquí os dejo un gráfico explicativo del funcionamiento obtenido de wikipedia.
Conclusiones
Para los no expertos en estos asuntos es un poco lio esto de los sistemas de control de versiones, además escoger bien la forma de trabajar en grupo es fundamental para no llevarte sorpresas desagradables. Todavía sigo buscando un documento fácil y conciso de buenas prácticas en el desarrollo de software en grupo usando sistemas de control de versiones pero no consigo hallar nada que me convenza, a lo mejor es porque no soy programador y no los comprendo bien, ¿quién sabe? de todas formas prometo no cejar en el empeño porque el tema es realmente interesante.
Hasta otra …
Referencias: