En el trabajo hemos tenido algunos problemas con el sistema control de versiones que usamos, svn, en cuanto al mantenimiento de las distintas branch. Un compañero (Karl) ha comentado que usar git, podría ayudarnos con el mantenimiento de las branches, trunk y los merges entre ellos. En git, cada commit genera en una base de datos un identificador único en forma de hash. Esto ayudaría en cualquier momento a conocer en que branches está disponible un commit concreto y administrar correctamente el código por las distintas ramas del árbol.
Se da la circunstancia que estoy desarrollando un proyecto personal con un amigo, por el gusto de aprender bien python y jquery (y las malas artes del 2.0 famoso). y ya nos hemos visto en la necesidad de disponer de un sistema control de versiones, así que, con el objeto de probar y conocer mejor git, ambos hemos decidido instalarlo: bah!, pasando de svn.
La primera impresión ha sido bastante buena. La gestión de las branch parece «mágica» (sí he escrito mágica y no magia; algún día explicaré qué es eso de mágica). Sin moverte del mismo path del sistema de archivos, puedes cambiar de branch (git checkout [branch_name]) y mágicamente si haces un ls, descubres que la estructura de ficheros se ha modificado a la de la branch elegida.
En fin, menos introducciones y más al tajo.
Lo primero es crear el repositorio. En git los repositorios no tienen por qué estar centralizados en un servidor, es más un «cliente» puede actuar de servidor para sí mismo o para otros. Cuando termine la explicación de cómo se usa, os daréis cuenta de esto. En cualquier caso, voy a seguir el modelo de cliente-servidor, tal como funciona en svn para que quede más claro.
Comencemos. En el servidor (host.dominio.com) crear un usuario devel (por ejemplo):
Loguearse con ese usuario y hacer
cd git/nombre_proyecto.git
git init --bare
ya está creado el repositorio sin código de nuestro proyecto. Para subir el código, lo vamos hacer desde nuestro sistema cliente (nuestro estación de trabajo). Para ello vamos a usar de capa de transporte, ssh, de tal modo que pase cifrado. Aconsejo subir tu clave pública al servidor para no tener que estar escribiendo user y pass todo el tiempo. Nos vamos al directorio donde tangamos ya nuestro código y le pasamos los siguientes comandos:
git init
git remote add origin ssh://devel@host.dominio.com/home/devel/git/nombre_proyecto.git
git add .
git commit -m "Apertura del repositorio"
Este commit, no escribe en el servidor, sino que lo hace en local generando su correspondiente entrada hash (el identificador único que identifica la operación) en la bbdd de git.
finalmente, con push, lo empujamos al servidor
Si por lo que sea, queremos obtener una copia del repositorio en otro ordenador o path, podemos optar por traerlo clonado desde el servidor. Esto es algo parecido a un checkout, sólo que se trae toda la base de datos de todo lo sucedido en el repositorio. Es decir, que en un momento dado este clon, podría convertirse en el repositorio raiz.
Clonar un repositorio ya creado:
cd proyecto
git clone ssh://devel@host.dominio.zona/home/devel/git/nombre_proyecto.git
Para crear una branch del proyecto es pasmosamente fácil:
Donde branch_proyecto es el nombre de la branch del repositorio
Para ver la branch en la que estás:
Para añadir ficheros al proyecto (svn add, svn commit). Lo primero es asegurarse que la branch en la principal :
y ahora sí a añadir:
git commit
Y finalmente hay que hacer un push, si quieres que llegue el cambio al repositorio del servidor. De esta forma, otros usuario podrán usar tus cambios:
Para tener actualizado tu repositorio local con el remoto:
Equivale a svn update y el –rebase es para revisar si otro usuario ha hecho antes un push
Más o menos con esto te puedes hacer una idea y manejarte con git. Más información en la página del proyecto oficial.
En cuanto a gestores de tickets para git, se puede usar el clásico Trac con el plugin correspondiente, aunque en realidad me gustaría probar http://www.redmine.org/ un trac para git. Intentaré hablaros pronto de redmine