Icono del sitio Home Assistant Fácil

Crear un repositiorio en Bitbucket con Mercurial

Luis del Valle Hernández

bitbucket-mercurialEn este minitutorial os voy a enseñar como podemos crear un repositorio en Bitbucket con Mercurial y los primeros pasos que debemos seguir. Resulta ser un binomio perfecto para los desarrolladores y nos permite trabajar en diferentes equipos siempre sincronizados. Como desarrollador estoy acostumbrado a trabajar con un equipo de sobremesa en la oficina y un portátil cuando voy a ver a clientes o estoy de viaje. En estos casos resulta muy cómodo tener una serie de herramientas que te permitan estar actualizado en todos los equipos.

Lo primero que tenemos que tener claro es qué es un repositorio. Si nos vamos a la Wikipedia podemos ver una amplia descripción del término. En resumidas cuentas podemos decir que un repositorio es un sitio, un lugar en alguna máquina donde podemos almacenar cualquier tipo de archivo digital. Si lo aplicamos al software nos servirá para tener centralizado todo nuestro código de una manera que sea accesible a todos los usuarios que necesiten acceder a el, ya sean desarrolladores o no. Algo que va muy ligado al término repositorio de software es control de versiones. ¿Qué es esto? Un control de versiones permite a un equipo de programadores trabajar sobre un proyecto de manera organizada. Esto se puede aplicar a nivel individual, a un solo programador. La función básica de este tipo de sistemas es que no se machaquen las modificaciones entre los diferentes desarrolladores. Vamos a poner un ejemplo práctico. Imaginaros que tenemos un programador que está trabajando con un archivo en la línea 1.000 y otro programador está trabajando en el mismo archivo pero en la línea 500. Cada uno hace una modificación. El primer programador ha terminado su tarea y comprueba si hay una versión nueva en el repositorio, esto se hace a través del comando Pull en Mercurial, lo veremos más adelante. Como no hay una nueva versión de ese archivo procede a subir su modificación con el comando Push. El segundo programador ha terminado su modificación y procede a actualizar el proyecto en el repositorio. Lo primero que debe hacer en estos casos es comprobar si hay una nueva versión, comando Pull. Como el programador uno había modificado el mismo archivo notifica que hay una modificación y realiza un Merge. Un Merge combina los dos ficheros de diferentes versiones. Si no hay ninguna inconsistencia en el código, que no se haya modificado la misma línea de código, se hará automáticamente. En caso contrario habrá un conflicto y se tendrá que resolver de forma manual, esto sería lo más adecuado. En resumidas cuentas esto sería un control de versiones.

Ahora bien, en el mercado nos encontramos diferentes software para el control de versiones que se dividen en dos grandes grupos, modelo cliente-servidor y el modelo distribuido.

Modelo cliente-servidor

Como su nombre indica, tenemos un cliente que será el desarrollador y accede a un servidor donde se encuentra el repositorio central. Digamos que estamos trabajando con el repositorio del servidor. Hay muchos productos de este tipo pero vamos a destacar dos. Apache Subversion que es software libre y Visual Studio Team Foundation Server de Microsoft orientado a la plataforma .NET y es un software propietario.

Modelo distribuido

En este modelo, cada desarrollador trabaja con un repositorio local. Tras hacer las modificaciones pertinentes se comparte el código con los demás desarrolladores que tengan configurado el repositorio. Los más conocidos que se basan en el modelo distribuido son Mercurial y Git.

Mi experiencia me dice que es preferible trabajar con un modelo distribuido ya que en todo momento puedes acceder a los proyectos compartidos aún sin tener conexión con el servidor, algo muy importante en nuestra profesión y más si viajas de un lado para otro. Por lo tanto os aconsejo este modelo y entre los dos grandes, Mercurial y Git, yo no he notado apenas diferencia a no ser la sintaxis de los comandos, cada producto tiene la suya propia. Yo ya me he acostumbrado a Mercurial y es el que utilizo así que os voy a explicar la configuración y primeros pasos con Bitbucket.

  1. Descargamos la versión de Mercurial para nuestra plataforma desde la página de descarga en mi caso Windows 64 bits.
  2. La instalamos, no tiene misterio en Windows, next, next, next, … , finish.
  3. A simple vista parece que no tenemos nada instalado pero si abrimos una línea de comandos (Tecla Windows + R) y tecleeamos hg (mercurio en la tabla periódica de elementos) nos aparecen los comandos básicos de Mercurial.

     

     

  4. Ya tenemos el software de Mercurial instalado ahora solo nos hace falta crearnos una cuenta en Bitbucket, es muy sencillo y además es gratis. Hay un plan gratuito para equipos pequeños de hasta 5 usuarios con ilimitados repositorios públicos y privados.

     

     

  5. Una vez creada la cuenta ya podemos crear nuestro primer repositorio y lo hacemos pulsando en Repositories->Create repository. En la siguiente pantalla nos pedirá información sobre nuestro repositorio.

     

     

    En la configuración del repositorio tenemos que tener en cuenta los siguientes parámetros.

    • Owner: el propietario del repositorio. En este caso como hemos creado un grupo de trabajo lo asignamos al grupo.
    • Name y Description: nombre y una breve descripción del proyecto.
    • Access level: nivel de acceso del repositorio. Si quieres que solo tu y los usuarios que elijas vean el repositorio marca This is a private repository en caso contrario se la publico a todo el mundo.
    • Forking: un Fork es una rama de tu proyecto que se crea de forma separada a diferencia de un Branch. Forking es la manera de crear una copia de tu proyecto en un punto determinado. Aquí tenemos tres opciones:
      • Allow forks: permite forks privados y forks públicos.
      • Allow only private forks: solo se permiten forks privados.
      • No forks: no se permiten forks en este proyecto
    • Repository type: se trata del tipo de repositorio. Bitbucket solo ofrece Mercurial y Git, en este caso elegimos Mercurial.
    • Project management: En esta opción vamos a elegir como queremos gestionar nuestro proyecto tenemos dos funcionalidades que podemos añadir.
      • Issue tracking: esta opción permite el seguimiento de incidencias como informes y errores además de otras tareas de gestión de proyectos.
      • Wiki: con esta opción podremos mantener y gestionar la documentación de nuestro proyecto.
    • Language: aquí seleccionamos el lenguaje de programación de nuestro proyecto. Hay un montón de opciones como C#, Java, JavaScript, HTML/CSS, etc…
    • HipChat: habilitando esta opción se activan las notificaciones de un chat para los integrantes del equipo de desarrollo del proyecto.
  6. Una vez tenemos creado el repositorio en Bitbucket ya podemos clonarlo en local en nuestro equipo.
  7. Nos vamos a la línea de comandos, vamos a la carpeta donde queremos crear nuestro repositorio y pegamos lo que hemos copiado de Bitbucket. Al pulsar Enter nos pedirá la contraseña que hemos puesto al darnos de alta en la aplicación. Esto nos creará una carpeta con el nombre de nuestro proyecto y dentro todos sus archivos.

     

     

Con estos 8 pasos ya tenemos en nuestra máquina local el proyecto gestionado con Mercurial. Ahora solo hace falta un paso más para dejarlo preparado y poder ver los primeros pasos con Mercurial. Si entras dentro de la carpeta que en mi caso se encuentra en C:\miprimerproyecto verás que lo único que se ha creado es una carpeta con un nombre .hg. Aquí se van a guardar todos los ficheros de configuración de Mercurial de nuestro proyecto. Para no tener que estar metiendo cada dos por tres el usuario, debemos de entrar dentro de esta carpeta y editar, con el mismo Notepad, el archivo hgrc. Importante, no se toca ningún archivo más ya que podríamos fastidiar el repositorio y perder los cambios que hayamos hecho. Cuando abrimos el archivo nos muestra lo siguiente.

# example repository config (see «hg help config» for more info)
[paths]
default = https://ldelvalleh@bitbucket.org/programarfacil/miprimerproyecto

# path aliases to other clones of this repo in URLs or filesystem paths
# (see «hg help config.paths» for more info)
#
# default-push = ssh://jdoe@example.net/hg/jdoes-fork
# my-fork = ssh://jdoe@example.net/hg/jdoes-fork
# my-clone = /home/jdoe/jdoes-clone

[ui]
# name and email (local to this repository, optional), e.g.
# username = Jane Doe <jdoe@example.com>

Todo lo que está precedido con # significa que son comentarios así que los podéis borrar y nos quedaríamos con la siguiente configuración sustituyendo la ruta de tu repositorio por la que yo pongo. Solo hay que añadir el username para que lo recuerde.

[paths]
default = https://ldelvalleh@bitbucket.org/programarfacil/miprimerproyecto

[ui]
username = Luis del Valle <ldelvalleh@programarfacil.com>

Hay una opción para guardar la contraseña pero yo no lo recomiendo, así siempre te enterarás y tendrás que validar cualquier actualización del código.

Ahora vamos a ver como podemos hacer nuestro primer commit que sirve para marcar donde hemos hecho un cambio. Es muy importante este concepto ya que podemos asemejarlos a los puntos de control de nuestro cambios es decir, si en algún momento queremos volver hacia atrás en las modificaciones de nuestro proyecto, lo haremos dando saltos marcados por los commits que hayamos hecho. Mi experiencia me dice que en cada commit el código debe estar estable, debe funcionar correctamente para que si volvemos para atrás por algún motivo podamos empezar desde algo que funciona correctamente. Está claro que a veces es difícil mantener este compromiso pero se debe hacer en la medida de lo posible.

Si añadimos un nuevo archivo a nuestro proyecto la secuencia de comandos que debemos hacer en la línea de comandos sería la siguiente:

  1. Vamos dentro de la carpeta de nuestro proyecto.
  2. Ejecutamos el comando hg add, que añade los archivos nuevos al control de versiones.
  3. Creamos un punto de control commit con el comando hg commit -m «Un comentario describiendo que se ha modificado».
  4. Obtenemos los cambios más recientes hg pull. Esto se hace para estar seguros que estamos trabajando con la última versión.
  5. Actualizamos el repositorio local hg update.
  6. Mandamos los cambios al repositorio maestro con hg push.

Y hasta aquí una pequeña introducción de como debemos utilizar esta maravillosa herramienta que nos ofrecen para realizar un desarrollo ágil dentro de un grupo de desarrolladores. Antes de concluir os dejo unas referencias muy interesantes para todos aquellos que tengan una especial manía a trabajar desde la línea de comandos. Estas herramientas trabajan en modo gráfico y se adaptan a los menús contextuales de Windows e incluso hay una que la podemos configurar para trabajar desde Visual Studio.

En este minitutorial os voy a enseñar como podemos crear un repositorio en Bitbucket con Mercurial y los primeros pasos que debemos seguir. Resulta ser un binomio perfecto para los desarrolladores y nos permite trabajar en diferentes equipos siempre sincronizados. Como desarrollador estoy acostumbrado a trabajar con un equipo de sobremesa en la oficina y un portátil cuando voy a ver a clientes o estoy de viaje. En estos casos resulta muy cómodo tener una serie de herramientas que te permitan estar actualizado en todos los equipos.

Lo primero que tenemos que tener claro es qué es un repositorio. Si nos vamos a la Wikipedia podemos ver una amplia descripción del término. En resumidas cuentas podemos decir que un repositorio es un sitio, un lugar en alguna máquina donde podemos almacenar cualquier tipo de archivo digital. Si lo aplicamos al software nos servirá para tener centralizado todo nuestro código de una manera que sea accesible a todos los usuarios que necesiten acceder a el, ya sean desarrolladores o no. Algo que va muy ligado al término repositorio de software es control de versiones. ¿Qué es esto? Un control de versiones permite a un equipo de programadores trabajar sobre un proyecto de manera organizada. Esto se puede aplicar a nivel individual, a un solo programador. La función básica de este tipo de sistemas es que no se machaquen las modificaciones entre los diferentes desarrolladores. Vamos a poner un ejemplo práctico. Imaginaros que tenemos un programador que está trabajando con un archivo en la línea 1.000 y otro programador está trabajando en el mismo archivo pero en la línea 500. Cada uno hace una modificación. El primer programador ha terminado su tarea y comprueba si hay una versión nueva en el repositorio, esto se hace a través del comando Pull en Mercurial, lo veremos más adelante. Como no hay una nueva versión de ese archivo procede a subir su modificación con el comando Push. El segundo programador ha terminado su modificación y procede a actualizar el proyecto en el repositorio. Lo primero que debe hacer en estos casos es comprobar si hay una nueva versión, comando Pull. Como el programador uno había modificado el mismo archivo notifica que hay una modificación y realiza un Merge. Un Merge combina los dos ficheros de diferentes versiones. Si no hay ninguna inconsistencia en el código, que no se haya modificado la misma línea de código, se hará automáticamente. En caso contrario habrá un conflicto y se tendrá que resolver de forma manual, esto sería lo más adecuado. En resumidas cuentas esto sería un control de versiones.

Ahora bien, en el mercado nos encontramos diferentes software para el control de versiones que se dividen en dos grandes grupos, modelo cliente-servidor y el modelo distribuido.

Modelo cliente-servidor

Como su nombre indica, tenemos un cliente que será el desarrollador y accede a un servidor donde se encuentra el repositorio central. Digamos que estamos trabajando con el repositorio del servidor. Hay muchos productos de este tipo pero vamos a destacar dos. Apache Subversion que es software libre y Visual Studio Team Foundation Server de Microsoft orientado a la plataforma .NET y es un software propietario.

Modelo distribuido

En este modelo, cada desarrollador trabaja con un repositorio local. Tras hacer las modificaciones pertinentes se comparte el código con los demás desarrolladores que tengan configurado el repositorio. Los más conocidos que se basan en el modelo distribuido son Mercurial y Git.

Mi experiencia me dice que es preferible trabajar con un modelo distribuido ya que en todo momento puedes acceder a los proyectos compartidos aún sin tener conexión con el servidor, algo muy importante en nuestra profesión y más si viajas de un lado para otro. Por lo tanto os aconsejo este modelo y entre los dos grandes, Mercurial y Git, yo no he notado apenas diferencia a no ser la sintaxis de los comandos, cada producto tiene la suya propia. Yo ya me he acostumbrado a Mercurial y es el que utilizo así que os voy a explicar la configuración y primeros pasos con Bitbucket.

  1. Descargamos la versión de Mercurial para nuestra plataforma desde la página de descarga en mi caso Windows 64 bits.
  2. La instalamos, no tiene misterio en Windows, next, next, next, … , finish.
  3. A simple vista parece que no tenemos nada instalado pero si abrimos una línea de comandos (Tecla Windows + R) y tecleeamos hg (mercurio en la tabla periódica de elementos) nos aparecen los comandos básicos de Mercurial.

Ya tenemos el software de Mercurial instalado ahora solo nos hace falta crearnos una cuenta en Bitbucket, es muy sencillo y además es gratis. Hay un plan gratuito para equipos pequeños de hasta 5 usuarios con ilimitados repositorios públicos y privados.

Una vez creada la cuenta ya podemos crear nuestro primer repositorio y lo hacemos pulsando en Repositories->Create repository. En la siguiente pantalla nos pedirá información sobre nuestro repositorio.

En la configuración del repositorio tenemos que tener en cuenta los siguientes parámetros.

Una vez tenemos creado el repositorio en Bitbucket ya podemos clonarlo en local en nuestro equipo.

Nos vamos a la línea de comandos, vamos a la carpeta donde queremos crear nuestro repositorio y pegamos lo que hemos copiado de Bitbucket. Al pulsar Enter nos pedirá la contraseña que hemos puesto al darnos de alta en la aplicación. Esto nos creará una carpeta con el nombre de nuestro proyecto y dentro todos sus archivos.

Con estos 8 pasos ya tenemos en nuestra máquina local el proyecto gestionado con Mercurial. Ahora solo hace falta un paso más para dejarlo preparado y poder ver los primeros pasos con Mercurial. Si entras dentro de la carpeta que en mi caso se encuentra en C:\miprimerproyecto verás que lo único que se ha creado es una carpeta con un nombre .hg. Aquí se van a guardar todos los ficheros de configuración de Mercurial de nuestro proyecto. Para no tener que estar metiendo cada dos por tres el usuario, debemos de entrar dentro de esta carpeta y editar, con el mismo Notepad, el archivo hgrc. Importante, no se toca ningún archivo más ya que podríamos fastidiar el repositorio y perder los cambios que hayamos hecho. Cuando abrimos el archivo nos muestra lo siguiente.

# example repository config (see «hg help config» for more info)
[paths]
default = https://ldelvalleh@bitbucket.org/programarfacil/miprimerproyecto

# path aliases to other clones of this repo in URLs or filesystem paths
# (see «hg help config.paths» for more info)
#
# default-push = ssh://jdoe@example.net/hg/jdoes-fork
# my-fork = ssh://jdoe@example.net/hg/jdoes-fork
# my-clone = /home/jdoe/jdoes-clone

[ui]
# name and email (local to this repository, optional), e.g.
# username = Jane Doe <jdoe@example.com>

Todo lo que está precedido con # significa que son comentarios así que los podéis borrar y nos quedaríamos con la siguiente configuración sustituyendo la ruta de tu repositorio por la que yo pongo. Solo hay que añadir el username para que lo recuerde.

[paths]
default = https://ldelvalleh@bitbucket.org/programarfacil/miprimerproyecto

[ui]
username = Luis del Valle <ldelvalleh@programarfacil.com>

Hay una opción para guardar la contraseña pero yo no lo recomiendo, así siempre te enterarás y tendrás que validar cualquier actualización del código.

Ahora vamos a ver como podemos hacer nuestro primer commit que sirve para marcar donde hemos hecho un cambio. Es muy importante este concepto ya que podemos asemejarlos a los puntos de control de nuestro cambios es decir, si en algún momento queremos volver hacia atrás en las modificaciones de nuestro proyecto, lo haremos dando saltos marcados por los commits que hayamos hecho. Mi experiencia me dice que en cada commit el código debe estar estable, debe funcionar correctamente para que si volvemos para atrás por algún motivo podamos empezar desde algo que funciona correctamente. Está claro que a veces es difícil mantener este compromiso pero se debe hacer en la medida de lo posible.

Si añadimos un nuevo archivo a nuestro proyecto la secuencia de comandos que debemos hacer en la línea de comandos sería la siguiente:

  1. Vamos dentro de la carpeta de nuestro proyecto.
  2. Ejecutamos el comando hg add, que añade los archivos nuevos al control de versiones.
  3. Creamos un punto de control commit con el comando hg commit -m «Un comentario describiendo que se ha modificado».
  4. Obtenemos los cambios más recientes hg pull. Esto se hace para estar seguros que estamos trabajando con la última versión.
  5. Actualizamos el repositorio local hg update.
  6. Mandamos los cambios al repositorio maestro con hg push.

Y hasta aquí una pequeña introducción de como debemos utilizar esta maravillosa herramienta que nos ofrecen para realizar un desarrollo ágil dentro de un grupo de desarrolladores. Antes de concluir os dejo unas referencias muy interesantes para todos aquellos que tengan una especial manía a trabajar desde la línea de comandos. Estas herramientas trabajan en modo gráfico y se adaptan a los menús contextuales de Windows e incluso hay una que la podemos configurar para trabajar desde Visual Studio.

Salir de la versión móvil