Git y Mercurial: QuickStart for the impatient

Deseaba probar los sistemas de control de versiones Git y Mercurial así que decidí versionar un pequeño proyecto para postear al Twitter de manera automatizada los últimos feeds de los blogs que administro. Veamos las fuentes de este proyecto como simpleas archivos alacenados en un directorio simple. Inicialmente este directorio se llamaba RSStoTwitter y pensa cambiarlo a RSS2Twitter pero uno de los blogs está sindicado con Atom así que el nombre no era preciso. No me he preocupado en revisar si el Atom es un RSS, pero supongo que amgos son estructuras XML sencillas y transformables entre sí ya que su finalidad e sla misma. No nos desviemos más y vayamos a lo nuestro.

He creado tres directorios para realizar las pruebas.

git_github: versionará empleando Git y es alojado en el servidor libre de GitHub.com
git_assembla: versionará empleando Git y es alojado en el servidor libre de Assembla.com
hg_freehg: versionará empleando Mecurial (HG por el símbolo del elemento químico Mercurio) y es alojado en el servidor libre FreeHG.org

Para el caso de Git se puede emplear la seguridad de un certificado RSA el cual podemos crear desde el directorio home de nuestro usuario:

cd .ssh
ssh-keygen -t rsa
<nombre para el certificado>
<password>

Para mostrar la llave pública realizamos la impresión en pantalla de un archivo generado en el proceso anterior:

cat id_rsa.pub

Esta llave se puede ingresar tanto en el Sitio de Assembla que hayamos creado como en el Perfil de GitHub.
Assembla es un poco más complejo debido a las mayores opciones que permite. Por ejemplo el soporte para Git debemos agregarlo ya que no está activo por defecto y podemos elminar Subversion.

qct
qgit

Para el caso de GitHub realicé lo siguiente:

cd twitterrssmultifeed/
git init
touch README
git add README
git commit -m ‘first commit’
git remote add origin git@github.com:adagio/twitterrssmultifeed.git
git push origin master

Ese archivo README está vació pero ya se encuentra en el repositorio. Luego de copiar las fuentes de mi aplicación las agregué, hice commit y nuevamente push. Para el caso de Assembla no realicé el paso de crear un archivo README que no forma parte de mi aplicación sino de un ejemplo. Así que luego de copiar las fuentes en el directorio ejecuté los siguientes comandos.

git add .
git-commit -m “first commit”
git remote add origin git@git.assembla.com:twitterrssmultifeed.git
git push origin master:refs/heads/master

Debido al certificado RSA el password me es solicitado, esto se puede automatizar.

Para el caso de Mercurial realizar un proceso similar fue algo accidentado ya que no completaba la operación de commit. Lo más sencillo fue clonar el repositorio al directorio local:

cd mercurial_freehg/
clone http://freehg.org/u/adagio/twitterrssmultifeed/ twitterrssmultifeed/

Y Luego de copiar las fuentes emplear una aplicación que realice el commit ( hg status, hg add, hg commit ):

qct

Esta aplicación detecta de forma automática el sistema de control de versiones empleado. Seguramente lo hace buscando los ficheros .git o .hg, de forma similar para otros sistemas como subversion o cvs.

Finalmente el proceso de push lo realicé sin problemas.

hg push http://freehg.org/u/adagio/twitterrssmultifeed/

Vemos que Git y Hg el proceso de commit está separado del push. La teoría de estos sistemas debe justificar esta implementación y el uso de herramientas gráficas totalmente integradas al sistema operativo como Tortoise nos ocultan estos interesantes detalles que podrían ser muy útiles cuando deseamos conocer si ya hemos sobreescrito algún archivo entre otras aplicaciones bastante prácticas.

Pensaba probar el promocionado sistema Bazaar pero parece que los dos que he explicado son mejores. Es una interesante tarea para quien los use conocer sobre la comparación de fuentes, creación de forks, exportación de proyectos, candados, etc. Pero personalmente le doy el uso más sencillo de versionado personal.

Alrededor de estas tecnologías sitios como Assembla están brindando la posibilidad de realizar un seguimiento a reporte de bug, tener salas de chat, establecer hitos, seguir un proceso formal de desarrollo, entre otras herramientas que deben ser seleccionadas de acuerdo a la naturaleza del proyecto que se tenga.

Saludos.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s