Archivo de la categoría: Control de versiones

Cómo sincronizar repositorios forkeados con Git

Un día nos creamos cuentas en GitHub y en BitBucket, forkeamos un proyecto, hicimos clone de nuestra copia; y todo anduvo bien. Pero otro día, el proyecto original avanza y nuestro código queda desactualizado.

En lugar de tener que borrar nuestro fork y crear uno nuevo, vamos a sincronizarlo con el proyecto original.

Para el ejemplo, voy a tomar mi desactualizada copia de Magento2.

Fork de Magento2 en GitHub

Lo primero será ejecutar, dentro del directorio local del proyecto, el siguiente comando:

git remote -v

Lo cual nos mostrará los repositorios remotos de nuestro repositorio:

origin    git@github.com:barbanet/magento2.git (fetch)
origin    git@github.com:barbanet/magento2.git (push)

Ahora, agregamos el upstream para nuestro repositorio, que es el repositorio original desde el cual hicimos el fork.

Siguiendo mi ejemplo, ejecutamos:

git remote add upstream git@github.com:magento/magento2.git

Si volvemos listar los repositorios remotos, tendríamos que ver:

origin    git@github.com:barbanet/magento2.git (fetch)
origin    git@github.com:barbanet/magento2.git (push)
upstream    git@github.com:magento/magento2.git (fetch)
upstream    git@github.com:magento/magento2.git (push)

Hasta acá sólo agregamos los repositorios con los cuales vamos a sincronizar. Ahora toca actualizar nuestra copia local.

Sigue leyendo

Usando múltiples cuentas en GitHub

Con la adopción de GitHub como servicio por parte de muchas empresas, es muy probable que nos toque algún proyecto en el cual no podamos usar nuestra cuenta personal.

Con esto se nos presenta un inconveniente: usar múltiples cuentas al mismo tiempo.

Para resolver este escenario, lo primero será crear un nuevo par de claves, sin perder las que ya estamos usando. Abrimos la consola y ejecutamos:

damian@linux:~$ ssh-keygen -t rsa -C "damian@ejemplo.com.ar"

A continuación veremos lo siguiente:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/damian/.ssh/id_rsa):

Acá es importante cambiar el nombre de la clave para evitar pisar las que ya tengamos en nuestro sistema.

Enter file in which to save the key (/home/damian/.ssh/id_rsa): /home/damian/.ssh/id_rsa_ejemplo

Sigue leyendo

Evitar comentarios vacíos en los commits de SVN

De más está decir que la intención de los comentarios en un commit es para que, si hay que trazar una modificación, exista una aclaración o especificación coloquial de lo que se estuvo haciendo.

A veces, ya sea por vagos o distraídos, puede ser que se nos pase por alto ingresar el comentario al commit que estamos realizando.

Si bien podríamos considerar esto como una mala práctica (el no ingresar los comentarios), en pequeños desarrollos, en los cuales trabajemos solos (o casi), esto no traería mayores consecuencias.

Muy distinto es el efecto si llevamos ésta cuestión a proyectos grandes (tanto en código como en personas).

Para evitar que se filtren los comentarios vacíos, podemos ajustar nuestro repositorio para que valide dicha condición y nos impida ingresar el commit.

Para empezar, vamos al directorio

cd /path/a/mi/repositorio/hooks

Dentro del directorio vamos a ver los varios archivos .tmpl que tiene nuestro repositorio por defecto. A nosotros nos va a interesar trabajar con pre-commit. Veamos paso a paso como habilitarlo y aplicar nuestra regla para evitar comentarios vacíos.

Copiamos pre-commit.tmpl y le damos permiso de ejecución a nuestra copia.

cp pre-commit.tmpl pre-commit
chmod +x pre-commit

Sigue leyendo

Relocalización de repositorios SVN

Retomo nuevamente el tema repositorios, y en particular con Subversion.

El comando svn que vamos a ver hoy se llama switch.

Con ésta herramienta podemos ir alternando nuestro proyecto (o parte de él) con los distintos branches que tenga el repositorio, y también podemos apuntar el proyecto entero a otra dirección de repositorio.

Yo me voy a centrar en ésta última parte, en la de la relocalización de un repositorio entero.

La primera pregunta sería: ¿por qué tengo que relocalizar el repositorio?. El escenario más común podría consistir en que por cuestiones externas al desarrollador, la dirección inicial usada para el checkout ya no esté disponible y ahora el mismo repositorio esté accesible a través de otra url.

Si éste es nuestro caso, para poder seguir trabajando sin tener que hacer un nuevo checkout y padecer todos los problemas que ello implique, basta con volver a apuntar nuestra copia local con la nueva url.

La forma de hacerlo sería la siguiente.

cd /path/a/copia/local
svn switch --relocate http://url.original/repositorio/trunk http://url.nueva/repositorio/trunk .

Espero que el ejemplo sea claro.

Primero, nos paramos en el directorio en el cual se encuentra nuestra copia de trabajo, y luego corremos el comando agregándole el parámetro –relocate junto con la url original y seguida a esa, la nueva url.

Un detalle, el punto final es parte del comando.

Otro detalle, y el último, es que lo que cambia es la url, pero no el repositorio físico. El repositorio físico debe ser el mismo con el que estábamos trabajando.

Ejemplo de repositorio con SVN con un proyecto Magento

Hace ya un buen tiempo, estuvimos charlando con Pablo Montero (compañero de andadas en cuanto a Magento se refiere) sobre cómo estructurar un repositorio (con Subversion) para trabajar con la plataforma.

Vale aclarar que el ejemplo que voy a armar, es sólo eso: un ejemplo. Otra aclaración oportuna, sería que si bien el ejemplo lo aplico con Magento, puede pensarse para cualquier otro proyecto y sería más o menos válido (hay mucho de decisiones arbitrarias al momento de crear un repositorio).

Antes de continuar, voy a dar por sentado que mínimamente tenemos una noción del uso de los trunk, tags y branches en SVN.

A manera de repaso simple (intencionalmente demasiado simple), vamos a considerar que:

  • trunk: es la rama principal del proyecto y es dónde se alojará la versión productiva.
  • tags: se utiliza para dejar marcada, por ejemplo, una implementación; y de esa forma poder volver a ese punto sin mayores problemas.
  • branches: suelen utilizarse como líneas de desarrollo independientes del trunk, las cuales en algún momento pueden volver a mergearse con la línea principal.

De seguro podríamos hablar mucho más sobre los branches, pero lo vamos a dejar para otro post. La idea hoy es armar un repositorio para que podamos trabajar con nuestra plataforma de ecommerce favorita.

Antes de pasar a la estructura propuesta, vamos a introducir un término/concepto adicional dentro de los branches que es el de vendor. Dentro de ésta carpeta, podríamos incluir el software de terceros que usamos para nuestro proyecto.

Sigue leyendo