Elección de credenciales con ssh agent forwarding

Supongamos que tenemos dos usuarios diferentes, uno empresarial y otro personal, que utilizamos en, por ejemplo GitHub.

Para poder hacer uso de las credenciales de ambos usuarios dependiendo del repositorio al que nos conectemos haremos algo similar a lo contado en Configurando múltiples claves SSH para diferentes cuentas github.

Ahora bien, ¿qué ocurre si queremos utilizar estas mismas credenciales desde otro equipo haciendo uso de ssh agent forwarding?

Limpieza de ramas locales tras el merge y borrado en el servidor central

Si utilizas Github o Gitlab, seguramente estará familiarizado en los Pull Requests o Merge Requests. Ambos tienen una opción para eliminar una rama tras hacer el merge del Pull/Merge Request.

El problema es que dicha opción solamente borrará la rama en el repositorio remoto. Ahora bien, cómo podemos «limpiar» nuestras ramas locales?

Supongamos que tenemos la rama «feature»

1. 1. Listado de ramas en el equipo local
      El comando git branch -a muestra que la rama «feature» existe en local pero también muestra la referencia a la rama remota inexistente.

      $ git branch -a
      feature
      * master
      remotes/origin/master
      remotes/origin/feature

   2. «Limpieza» de las referencias locales a las rama remotas
      El comando git remote prune origin --dry-run hace una «simulación» (--dry-run) de «limpieza» de ramas remotas (porque ya no existen en el servidor remoto).

      $ git remote prune origin --dry-run
      Pruning origin
      URL: git@github.com:rubensa/repo.git
      * [would prune] origin/feature

      Una vez comprobado que todo es correcto, podemos proceder a ejecutar realmente el comando de borrado.

      $ git remote prune origin
      Pruning origin
      URL: git@github.com:rubensa/repo.git
      * [pruned] origin/feature

      Una vez mas, ejecutando el comando git branch -a se nos mostrará el estado local de las ramas.

      $ git branch -a
      feature
      * master
      remotes/origin/master

      Podemos ver que remotes/origin/feature ha sido eliminada, pero no así la rama local feature.

   3. Eliminación de rama local
      Si queremos, también podemos «limpiar» la rama local feature:

      $ git branch -d
      Deleted branch feature (was 6493f15).

       

vía

Migración de CVS a GIT

sudo apt-get install cvs
Descargar: cvs2svn usando el comando
svn export --username=guest http://cvs2svn.tigris.org/svn/cvs2svn/trunk cvs2svn-trunk

rsync -ai <URL-CVS> <PROJECT>

NOTA: <URL-CVS> será algo de la forma a.cvs.sourceforge.net::cvsroot/aopalliance/

cp ./cvs2svn-trunk/cvs2git-example.options ./cvs2git.options
vi cvs2git.options
Modificar:

run_options.set_project(
# The filesystem path to the part of the CVS repository (*not* a
# CVS working copy) that should be converted. This may be a
# subdirectory (i.e., a module) within a larger CVS repository.
r'test-data/main-cvsrepos',

por

run_options.set_project(
# The filesystem path to the part of the CVS repository (*not* a
# CVS working copy) that should be converted. This may be a
# subdirectory (i.e., a module) within a larger CVS repository.
r'<PROJECT>',


./cvs2svn-trunk/cvs2git --options=cvs2git.options --fallback-encoding utf-8
mkdir <PROJECT>-git
cd <PROJECT>-git
git init
cat ../cvs2git-tmp/git-{blob,dump}.dat | git fast-import
git log
git reset --hard
git remote add origin <URL-GIT>
git push -u origin --all
git push --tags

vía

GIT: Mantén tu fork actualizado

1. Clona tu fork:
   git clone git@github.com:YOUR-USERNAME/YOUR-FORKED-REPO.git
2. Añade el remote del repositorio original a tu repositorio:
   cd into/cloned/fork-repo
git remote add upstream git://github.com/ORIGINAL-DEV-USERNAME/REPO-YOU-FORKED-FROM.git
git fetch upstream
3. Actualiza tu fork a partir del repo original para mantener actualizados sus cambios:
   git pull upstream master
4. Sube tus cambios:
   git push

vía

Migración de GIT a GIT

git clone --bare <URL-GIT-OLD>
cd <PROJECT>

Comprueba que están bien los datos de todos los desarrolladores:
git shortlog -e -s -n

Corrige con el siguiente script la información que pudiera estar mal:

git-author-rewrite-multiple.sh
————–
#!/bin/sh

for email in user1@olddomain.com user2@olddomain.com
do
git filter-branch -f --env-filter '

OLD_EMAIL="'${email}'"
CORRECT_NAME="'${email%%@*}'"
CORRECT_EMAIL="'${email%%@*}'@newdomain.com"

if [ "$GIT_COMMITTER_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "$OLD_EMAIL" ]
then
export GIT_COMMITTER_NAME="$CORRECT_NAME"
export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags; echo "done for ${email}"

done
————–

git push --mirror <URL-GIT-NEW>
cd ..
rm -rf <PROJECT>

Algunos enlaces de interés
Duplicating a repository
list authors of a git repository including commit count and email
Changing author info

Migración de SVN a GIT

sudo apt-get install git-svn
Descargar: svn-migration-scripts.jar


java -jar svn-migration-scripts.jar authors <URL-SVN> > authors.txt
git svn clone --prefix="" --stdlayout --authors-file=authors.txt <URL-SVN>
cd <PROJECT>
java -Dfile.encoding=utf-8 -jar ../svn-migration-scripts.jar clean-git --force
git remote add origin <URL-GIT>
git push -u origin --all
git push --tags


vía

Configurando múltiples claves SSH para diferentes cuentas github

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

Entendiendo el Workflow de 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.

El Génesis de 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?