git

Usar múltiples cuentas con repositorios remotos puede resultar complicado.  En esta entrada explico cómo podemos conseguir que Git utilice la clave SSH correcta para el repositorio en el que estemos trabajando.

Creación de diferentes claves públicas

Para generar una clave nueva ejecutaremos el siguiente comando:

$ ssh-keygen -t rsa -C "your_email@youremail.com" -f "your_user_id_file"

La opción -C es un comentario para ayudar a identificar la clave.  La opción -f especifica el nombre del fichero.

En el ejemplo, crearemos 2 claves que debemos guardar en el directorio ~/.ssh/:

~/.ssh/id_rsa_user1
~/.ssh/id_rsa_user2

Una vez creadas, las añadiremos al anillo de claves del agente SSH de autentificación ejecutando los comandos:

$ ssh-add ~/.ssh/id_rsa_user1
$ ssh-add ~/.ssh/id_rsa_user2

NOTA: Podemos eliminar todas las claves anteriormente cacheadas mediante el comando:

$ ssh-add -D

Finalmente podemos comprobar las claves almacenadas mediante el comando:

$ ssh-add -l

Importación de la clave pública en GitHub

Debes importar la clave púbica generada anteriormente en su cuenta GitHub asociada.

Consulta la documentación de GitHub para ver cómo hacerlo.

Configuración de SSH

En el directorio ~/.ssh/ crearemos un fichero llamado config:

$ cd ~/.ssh/
$ touch config

He introduciremos un contenido similar a este:

#user1 account
Host github.com-user1
	HostName github.com
	User git
	IdentityFile ~/.ssh/id_rsa_user1

#user2 account
Host github.com-user2
	HostName github.com
	User git
	IdentityFile ~/.ssh/id_rsa_user2

Clona tu repositorio y modifica su configuración Git

Clona tu repositorio git

$ git clone git@github.com-user1:user1/your-repo-name.git

Si ya tenías una copia local será necesario que actualices el origin:

$ git remote set-url origin git@github.com-user1:user1/your-repo-name.git

Ahora ve al repositorio Git local que quieres configurar y ejecuta:

$ git config user.name "user1"
$ git config user.email "user1@example.com" 

o puedes tener tu configuración git global:

$ git config --global user.name "user1"
$ git config --global user.email "user1@example.com"

Repite el proceso con el otro usuario y su repositorio.

A partir de aquí, podemos usar el flujo normal para publicar nuestro código

$ git add .
$ git commit -m "your comments"
$ git push

vía

Anuncios

Subversion Logo
Tipos de merge:

  • sync o catch-up: un merge que introduce en la rama destino todos los cambios de la rama fuente que “todavía no tenemos” en la rama destino.
  • cherry-pick: un merge que introduce un o más cambios específicos de la rama fuente en la rama destino.
  • reintegrate: similar a un sync merge, pero pensada para ser utilizada en la otra dirección.

Asumamos un orden parcial entre branches, de tal modo que cada branch tiene (0 o más) Feature Banches que son menos estables que ella, y Release Branches que son más estables que ella, y ella se considera el padre de cada una de estas. Un merge se puede realizar entre una branch padre y uno de sus Feature o Release branches inmediatas, y en ninguna otra parte.

  • Un merge a una Feature Branch desde su padre normalmente es un catch-up.
  • Un merge desde una Feature Branch a su padre normalmente es un reintegrate.
  • Un merge a una Release Branch desde su padre normalmente es un cherry-pick.
  • Un merge desde una Release Branch a su padre podría ser un catch-up o un cherry-pick. (¿Funciona un catch-up correctamente y has hecho cherry-picks en la otra dirección? Puede que no.)

Subversive Logo
Inicialmente tenía conectados en Eclipse varios proyectos con un SVN utilizando el plugin Subclipse.

Debido a unos problemas en la creación de patches, tuve que cambiar a Subversive.

El problema viene porque una vez eliminado el plugin de Subclise y añadido el de Subversive, la única opción que aparece al pulsar botón derecho sobre un proyecto –> Team, es “Apply Patch…

Esto es debido a que Eclipse “recuerda” que el proyecto estaba conectado al SVN usando Subclipse (que ya no está disponible) y no me permite volver a conectarlo usando Subversive.

Para solucionarlo tenemos dos opciones.

La primera opción (des-instalar/re-instalar los plugins):

  1. Des-instala Subversive
  2. Re-instala Subclipse
  3. Verifica que los proyectos están conectados al SVN
  4. Botón derecho sobre el proyecto –> Team –> Disconect. Asegúrate de marcar “Do not delete the SVN meta-information (e.g. .svn subdirectories).
  5. Des-instala Subclipse
  6. Re-instala Subversive
  7. Botón derecho sobre el proyecto –> Team –> Share Proyect…

La segunda opción (si no quieres des-instalar/re-instalar):

  1. Crea un nuevo workspace vacío
  2. Abre Eclipse utilizando dicho workspace
  3. File –> Import –> General –> Existing Projects into Workspace
  4. Selecciona el proyecto del viejo workspace
  5. Botón derecho sobre el proyecto –> Team –> Share Proyect…

vía

git
Si no entiendes las motivaciones que hay detrás del diseño de Git, eres candidato a vivir un mundo de penurias. Con suficiente empeño puedes forzar a Git a actuar del modo que tú crees que debería hacerlo en vez del modo en que él quiere hacerlo. Pero eso es como usar un destornillador como si fuera un martillo; hace el trabajo, pero lo hace mal, lleva más tiempo, y estropea el destornillador.

Lee el resto de esta entrada »

El Génesis de GIT

17/06/2013

Genesis GIT
La Creación de GIT

  • El primer día: el almacén (repository) y el árbol de trabajo (working tree)

    Soy joven, el mundo es maravilloso y tengo mucho tiempo libre.

    Tengo tanto tiempo, que decido que quiero escribir un libro. El proyecto en el que estoy trabajando en una modesta historia y explicación de todo, con el título provisional de “El Libro”. Tiene una tabla de contenido contenido.txt y un solo capítulo:

    .
    ├── capitulo1.txt
    └── contenido.txt

    Según empiezo a escribir, empiezo a pensar que debería llevar un control de mis cambios. Necesito algún tipo de sistema de control de versiones. ¿Cómo de complicado puede ser esto?

    Lee el resto de esta entrada »

Para que el tema de los merges del SVN funcione bien, se supone que la forma de trabajo sería la siguiente:

Creación de una nueva rama de código:

  • Todas las ramas (branchs) se deberían crear a partir de una rama principal (trunk)
  • A la hora de crear un branch se “aconseja” poner como comentario:
    Branch from trunk rev:28495
    donde Branch es el nombre de la rama y 28495 es la revisión de partida del trunk de la que se crea la rama

Mezcla de nuevos cambios del trunk al branch:

  • Actualiza tu copia de trabajo a la última versión del branch
  • Averigua el número de revisión del último merge (si todavía no se hizo ninguno, el número de revisión de creación, que, si sigues las indicaciones deberías tener en alguno de los comentarios)
  • Utiliza la herramienta de merge de subclipse para mezclar el trunk en tu copia de trabajo (Team -> Merge)
    • Las URL‘s que aparecen en “From” y en “To” deberían ser las del trunk
    • La revisión del “From” debería ser el número de revisión del último merge
    • La revisión del “To” debería ser “Head
    • Pulsa en el botón Merge y espera a que termine
    • En la consola se muestra un log del proceso realizado. Si aparece algún conflicto (marcado con una C roja, lo que hay que hacer es localizar dichos ficheros en el navegador de archivos, botón derecho y pulsar en Team -> Edit Conflicts, lo que abrirá un nuevo editor con dos paneles con una versión en cada lado. Se resolverán los conflictos (como se realiza normalmente al subir cambios al SVN) y, una vez corregidos, se vuelve al navegador de archivos, sobre el mismo y se pulsa Team -> Mark as Resolved.
  • Probar todo una vez mezclado 🙂
  • Subir los cambios de la mezcla a la rama y poner como comentario:
    Merged trunk changes 28495-29536 into branch X
    donde X es el nombre de la rama y 28495 y 29536 se refieren a los números de revisión inicial y final que se mezclaron

Pasar cambios de un branch al trunk

  • Actualiza tu copia de trabajo a la última versión del trunk
  • Averigua el número de revisión del último merge (si todavía no se hizo ninguno, el número de revisión de creación del branch, debería aparecer en los comentarios)
  • Utiliza la herramienta de merge de subclipse para mezclar el branch en tu copia de trabajo (Team -> Merge)
    • Las URL‘s que aparecen en “From” y en “To” deberían ser las del branch
    • La revisión del “From” debería ser el número de revisión del último merge
    • La revisión del “To” debería ser “Head
    • Pulsa en el botón Merge y espera a que termine
    • En la consola se muestra un log del proceso realizado. No debería aparecer ningún conflicto ya que se supone que el branch contiene lo último del trunk mas sus propios cambios.
  • Probar todo una vez mezclado 🙂
  • Subir los cambios de la mezcla al trunk y poner como comentario:
    Merged branch X changes 29536:29776 into the trunk
    donde X es el nombre de la rama y 29536 y 29776 se refieren a los números de revisión inicial y final que se mezclaron

Algunos enlaces de interés
Subversion Branching and Merging Techniques

A %d blogueros les gusta esto: