Listado de ramas remotas con git

En el uso cotidiano de git, el manejo y cambio de ramas en local no suele ser un problema. branch y checkout son comando habituales con los que trabajar. Sin embargo, el problema viene cuando quieres contribuir o hacer algún tipo de desarrollo colaborativo contra un repositorio que no conoces. En este caso, tras hacer el clone correspondiente, únicamente tienes, por ejemplo la rama master. Si empleas github o algún interfaz de gestión de repositorios, entonces averiguar el nombre de todas las ramas que tiene el proyecto es más sencillo. Sin embargo, hacerlo desde consola ya no tanto.

Listado de ramas

Si lo que nos interesa es averiguar aquellas ramas que están disponibles para un proyecto, con el comando git también lo podemos lograr. La forma más sencilla,

shell> git branch -r
  origin/test
  origin/prueba
  origin/HEAD
  origin/master

Y si nos interesa tener un listado completo de las ramas remotas y locales,

shell> git branch -a
* master
  origin/test
  origin/prueba
  origin/HEAD
  origin/master

Rápido, limpio y sencillo. Sabiendo aquellas ramas disponibles, si queremos cambiar a alguna, únicamente habrá que realizar el checkout correspondiente, tanto sea local como remota.

Referencias

• http://git-scm.com

Leer más

Previsualización de fichero .md de github

Si alguna vez has creado un fichero readme.md en github, sabrás que si sintaxis, aunque no muy compleja sí resulta cuando menos confusa las primeras veces. Dicha sintaxis es conocida como Markdown, y uno de los grandes problemas que hay a la hora de escribir dicho fichero, es que lo que escribes hasta que hagas un commit y lo veas en github, no sabes cómo queda.

Por suerte, hoy en medio de una búsqueda y de forma casual encontré una herramienta, grip, escrita en python y que permite interpretar perfectamente los fichero .md y visualizar sin el commit cómo se verá en la web.

Instalación

Esta herramienta en realidad está pensada como un módulo de python y no está disponible en los repositorios de las principales distribuciones, pero por suerte, con pip la instalación es rápida.

shell> pip install grip

Uso

Tras su instalación ya tenemos disponible el software necesario y con un navegador, sencillamente lo ejecutamos sobre un directorio de nuestro proyecto que tenga un fichero readme.md y seguidamente abrimos la dirección localhost:5000 y tendremos ahí, en formato perfectamente visible, cómo queda nuestro fichero interpretado.

shell> grip

Si nuestro proyecto tiene más de un fichero o el nombre no es readme.md, que es el que coge por defecto, entonces le pasamos el nombre para que lo lea, interprete y deje visible en el navegador.

shell> grip CHANGES.md

Y también podemos cambiar el puerto al que queremos acceder simplemente indicándoselo,

shell> grip CHANGES.md 8080

Ya no tenemos excusa para no tener unos perfectos readme en nuestros repositorios, ya que este comando aparte de interpretar el fichero, cualquier cambio que hagamos en el mismo, con sólo refrescar la página lo podremos ver aplicado.

Leer más

Ahorrar espacio en git

git, del que ya comentamos cosas más de una vez, es fantástico a la hora de gestionar un proyecto con varias ramas y muchos cambios, pero tiene un curioso problema, el espacio que puede llegar a ocupar un repositorio. Bajo la carpeta del repositorio están almacenados todos los cambios y todas las ramas, para poder acceder a cualquier versión preliminar y esto, lógicamente, ocupa espacio.

Por poner un ejemplo claro, de un repositorio que tengo actualmente está ocupando 90Mb, mientras que si sumas todos los ficheros que forman parte del repositorio su tamaño ronda aproximadamente los 50Mb. Una diferencia de casi 40Mb es espacio extra que está ocupando. Cierto es que con los discos actuales no es un problema, pero aun así es bueno saber cómo poder optimizar este espacio.

Por suerte git tiene un comando para ello, gc (garbage collector), que no es más que un pequeño "recolector de basura", al más puro estilo java, que se encarga de eliminar todos aquellos objetos que son inalcanzables. Aunque se supone que git realiza esta tarea automáticamente si lo considera oportuno, también podemos forzar dicho purgado de forma manual.

Es importante saber que ningún objeto que sea alcanzable será borrado, sino que se borrarán branches, tags, entradas de logs, blobs, trees y objetos que hacen referencia a parent commits, pero que no sean alcanzables desde ningún punto. A mayores de la recolección de basura, gc también se encarga de organizar y empaquetar todos los objetos en un único archivo usando delta compression¹ .

En un ejemplo de uso, mi repositorio pasó de ocupar 90Mb a 80Mb sin perder ningún dato de interés. No es mucho, pero siempre puede ser interesante para ahorrar espacio.

shell> du -sh proyect_1
90M proyect_1/

shell> cd proyect_1

shell> git gc
Counting objects: 7503, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3783/3783), done.
Writing objects: 100% (7503/7503), done.
Total 7503 (delta 4257), reused 6237 (delta 3398)

shell> cd ..

shell> du -sh proyect_1
80M proyect_1/

1. Método de compresión optimizado para snapshots con pequeñas diferencias entre ellos.

La entrada Ahorrar espacio en git la puedes leer en El mundo en bits.

Leer más

No refs in common and none specified

Hoy trabajando con git me apareció el siguiente mensaje de error,

shell> git push
Enter passphrase for key '/home/javier/.ssh/public_key': 
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to 'git@git.domain.com:secretProyect'

Hay que decir, que cuando comencé a trabajar con el proyecto, hice un "git clone" del repositorio vacío, por lo tanto cuando ejecuté el "git push" obtuve ese maravilloso error.

Por suerte la solución fue sencilla,

shell> git push origin master
Enter passphrase for key '/home/javier/.ssh/public_key': 
Counting objects: 12, done.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (12/12), 8.01 KiB, done.
Total 12 (delta 4), reused 0 (delta 0)
To git@git.domain.com:secretProyect
 * [new branch]      master -> master

Más acerca de git en este blog.

Leer más

Metasploit se pasa a git

Recientemente actualicé la versión de metasploit, con la utilidad que trae para tal efecto, msfupdate, y obtuve un interesante mensaje relacionado con el cambio de sistema de versiones. Por lo que parece han decidido dejar de emplear svn y pasarse a git. Más concretamente ahora está el código disponible en https://github.com.

shell> msfupdate
[*]
[*] Attempting to update the Metasploit Framework...
[*]

[*] Deprecation Note: The next version of Metasploit will
[*] update over the git protocol, which requires outbound
[*] access to github.com:9418/TCP.
[*] Please adjust your egress firewall rules accordingly.
En la revisión 16314.

Aunque svn todavía está disponible para su uso, vamos a ver cómo pasar al nuevo sistema. Para ello debemos de instalar las utilidades de clonación de repositorios git. Prácticamente están disponibles para todas las distribuciones.

shell> apt-get install git-core
shell> yum install git
shell> pacman -S git

Una vez instalado el software, ya sólo queda clonar el código, para tener nuestra copia local y por lo tanto, nuestro framework disponible y actualizado.

shell> git clone git://github.com/rapid7/metasploit-framework.git

Cloning into metasploit-framework...
remote: Counting objects: 180679, done.
remote: Compressing objects: 100% (48858/48858), done.
remote: Total 180679 (delta 127197), reused 179204 (delta 126049)
Receiving objects: 100% (180679/180679), 199.89 MiB | 8.94 MiB/s, done.
Resolving deltas: 100% (127197/127197), done.

Ahora cada vez que deseemos actualizarlo, simplemente

shell> git pull

La entrada Metasploit se pasa a git la puedes leer en Puppet Linux.

Leer más

Crear un proyecto en GitHub

GitHub es un excelente gestor de proyectos gracias a git, el controlador de versiones que emplea a bajo nivel. En los últimos tiempos se dio mucho a conocer y la verdad es que si vas a desarrollar algo y necesitas tener una copia en la nube, ¿por qué no usarlo?

Hace unos cuantos post's vimos cómo funcionaba git para control local o subir a repositorios remotos, pero siempre conocidos y controlados. Ahora vamos a ver cómo poder unir de forma fácil y simple git + GitHub.

• Registro de clave SSH en GitHub
  
  Para comenzar, vamos a crear una clave RSA de ssh para autenticar nuestro equipo contra GibHub. Para ello,

  shell> cd ~/.ssh
  shell> ssh-keygen -t rsa -C "user@empresa.com"
  

  Una vez generada, vamos al menú "Account Settings" y en la opción "SSH Keys/Add SSH key" añadimos el contenido de nuestra clave pública (~/.ssh/id_rsa.pub). Una vez subida, podemos verificar su correcto funcionamiento al intentar conectarnos por ssh a GitHub. 

  shell> ssh -T user@github.com
  Hi username! You've successfully authenticated, but GitHub does not provide shell access.
  

• Configurar nombre y e-mail
  
  Vamos a configurar el nombre de nuestro usuario de GitHub y el correo electrónico.

  shell> git config --global user.name "USER NAME"
  shell> git config --global user.email "user@empresa.com"

• Configurar el token de GitHub
  
  Este token no es más que un método para permitir el acceso a ciertas herramientas que no sean ssh al repositorio remoto. Para obtener dicho código vamos al menú de "Account Settings" y en la opción "Account Settings" copiamos el valor de "Your API token is".
  Una vez lo tenemos, configuramos nuestro git local para que identifique contra GitHub correctamente. Para ello,

  shell> git config --global github.user "USER NAME"
  shell> git config --global github.token TOKEN

• Creamos un nuevo proyecto en GitHub
  
• Inicializar repositorio local
  
  Para comenzar a trabajar con GitHub primero tenemos que crear un directorio local en nuestra máquina que luego se sincronizará con el remoto.

  shell> mkdir ~/PROY_1
  shell> cd ~/PROY_1
  

  Ahora, dentro de esta nueva carpeta de proyecto, inicializamos un nuevo repositoio git, tal como sigue.

  shell> git init
  

   En este punto, el repositorio únicamente es local y no se sincroniza con repositorios remotos.
• Agregar descripción del proyecto
  
  Este es un paso altamente recomendable, aunque no estricto en GitHub. Especialmente si tu proyecto va a quedar libre, es necesario agregar una pequeña descripción de qué va, para que la gente lo pueda leer y entender. Para ello, creamos dentro de la carpeta del proyecto, el fichero README.

  shell> vi README
  

  Ahora, añadimos dicho fichero al proyecto y realizamos nuestro primer commit. Este todavía sigue siendo local. Hay que recordar que git trabaja en local y luego sincroniza a remoto.

  shell> git add README
  shell> git commit -m 'first commit'

• Agregar ficheros al proyecto
  
  Esta es la parte más importante, ya que es sobre la que se hará el trabajo día a día. Dentro de la carpeta de nuestro proyecto, crearemos el código, las imágenes, los ficheros de configuración, etc. Todo lo que queramos y cada vez que añadamos algo nuevo, habrá que ejecutar estas opciones. La primera es para añadir los ficheros y la segunda es para realizar un commit.

  shell> git add .
  shell> git commit -m 'last change log'
  

  En caso de que no queramos añadir todas las carpetas y ficheros del proyecto a git, podemos pasarle de una en una.
  El número de commit's que se realicen dependerá del programador, pero cada nueva funcionalidad importante o cada parche aplicado es una buena opción, para así poder tener unos buenos métodos de trazado.
• Subir modificaciones a GitHub
  
  Esta es la parte más importante, ya que hasta aquí todo el como trabajar con git, del que recordemos, ya hemos hablado en alguna ocasión. Así que ahora vamos a ver cómo poder sincronizar nuestro repositorio local, con el repositorio remoto de GitHub.
• Asociar local con remoto
  
  Con la siguiente ejecución asociamos nuestro repositorio local al remoto de GitHub. Hay que establecer los nombres de usuario y del proyecto correctamente. En mi caso USER y PROY_1.

  shell> git remote add origin git@github.com:USER/PROY_1.git

• Sincronizar repositorios
  
  Y ahora simplemente sincronizamos todo el contenido local y remoto gracias a git. Esto lo tendremos que hacer cada vez que queramos publicar o subir algo nuevo.

  shell> git push -u origin master
  

Una vez tengamos la cuenta de GitHub creada y sincronizada, se podrán ver los archivos del proyecto en la siguiente URL: https://github.com/USER/PROY_1

Leer más

git (III)

Las ventajas de git ya se han comentado y también cómo instalarlo y configurarlo, así que ahora toca comenzar a usarlo en nuestros proyectos, para tener un control de versión de los ficheros y evitar cualquier contratiempo en el código o en los ficheros.

Comenzamos creando un directorio de trabajo para el nuevo proyecto, así como la estructura que deseemos para el mismo.

shell> mkdir ~/proyecto_1
shell> cd ~/proyecto_1
shell> mkdir bin src img

Será sobre este directorio sobre el que creemos un repositorio git.

shell> git init
Initialized empty Git repository in ~/proyecto_1/.git/

Si alguno de los ficheros y/o directorios no nos interesa que esté dentro del repositorio, lo añadimos al fichero .gitignore.

shell> echo "bin" > .gitignore

Y a continuación añadimos los ficheros al repositorio, como primer commit.

shell> git add .
shell> git commit -m "Comenzamos el proyecto"
[master (root-commit) e89cb3e] Comenzamos el proyecto
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore

Comprobamos que todo fue correcto.

shell> git log
commit e89cb3ed08f2e3ada7d2c7132807d87cecba1dbb
Author: Javier
Date:   Tue Oct 18 20:07:44 2011 +0200

    Comenzamos el proyecto

Leer más

puppet manifest for git

Como se comentó en el último post sobre git, antes de comenzar a usarlo y crear repositorios, se muestra la clase que permite la configuración automática de git cuando un usuario se crea desde puppet.

class usuarios {
   define add_user($username, $git=false) {
      user { "$name":
         ensure        => present,
         membership    => inclusive,
         comment       => $username,
         home          => "/home/$name",
         provider      => useradd,
         shell         => "/bin/bash",
      }

      file { "/home/$name/":
         owner         => $name,
         group         => $operatingsystem ? {
            suse       => "users",
            default    => "$name",
         },
         mode          => 750,
         ensure        => directory;
      }
      if $key {
         file { "/home/$name/.gitconfig":
            owner      => $name,
            group      => $operatingsystem ? {
               suse    => "users",
               default => "$name",
            },
            mode       => 0600,
            require    => File["/home/$name"],
            content    => template("templates/gitconfig.erb");
         }
      }
   }
}

Leer más

git (II)

Prácticamente todos los sistemas GNU/Linux tienen en sus repositorios la versión de git para poder instalarla y comenzar a usarla.
La instalación de git en sistemas debian/ubuntu, como siempre, desde repositorios oficiales,

shell> apt-get install git-core

Para sistemas Windows: http://code.google.com/p/msysgit

Una vez terminada la instalación de git, queda configurarlo para poder usarlo de forma adecuada. Si la instalación es para un único usuario, lo más simple es ejecutar los siguientes comandos, que configuran el nombre, el email y establece colores para una mejor visualización de los datos de los repositorios.

shell> git config --global user.name "USER NAME"
shell> git config --global user.email "USER@COMPANY.COM"
shell> git config --global color.status auto
shell> git config --global color.branch auto

Estos comandos escriben en el fichero ~/.gitconfig la configuración propia del usuario. Y el contenido será similar al siguiente:

shell> cat ~/.gitconfig
[user]
 name  = Javier
 email = javier@company.com
[color]
 status = auto
 branch = auto

En el siguiente post sobre git, se explicará cómo poder instalarlo usando puppet y configurarlo para cada usuario que maneje puppet.

Leer más

git (I)

La semana pasada vi como un buen colega recomendaba el uso de git para tener un control de versiones de una página web. Hablando con él, allí nos pusimos a comentar sobre repositorios, branch, etc. Ahí le dije que intentaría escribir algún post acerca de git y cómo usarlo, ya que desde hace tiempo, lo uso para tener un mejor control de las cosas que se hacen. En este primer post, se hará una introducción a git a nivel teórico, para luego pasar a un nivel práctico en las siguientes entradas.

git es un software de control de versiones, escrito inicialmente por Linus Torvalds, pensado para la eficiencia y la confiabilidad del mantenimiento de diferentes versiones de código fuente u otros archivos. El diseño de git surgió de la experiencia y necesidades de Linus, así como de la necesidad de mantener una gran cantidad de código distribuida entre mucha gente, en donde la rapidez y el rendimiento son importantes.

Las principales características son:

• Fuerte apoyo al desarrollo no-lineal.
• Gestión distribuida.
• Compatibilidad con diferentes sistemas/protocolos ya existentes (http, ftp, rsync).
• Eficiencia trabajando con grandes proyectos.

Dentro de la nomenclatura git, las partes más destacables son:

• Repositorio
  
  Contiene todo el historial de las diferentes versiones en la línea temporal, con las ramas y etiquetas. En git, al ser un sistema distribuido, no existe un único repositorio central, sino que cada copia es un repositorio completo, por lo que suele existir un repositorio local y un repositorio remoto.
• Rama (branch)
  
  Una rama es una copia del código principal sobre el que se realizarán determinados cambios y por ello merece un nombre especial. Para verlo más fácilmente, una rama es cada una de las versiones del kernel. Cada rama, cuelga del principal, pero con determinados cambios muy concretos. Por ejemplo, se podría tener una versión de una web y luego realizar una rama para cada implementación final. git facilita la creación de ramas y el trabajar rápidamente con ellas.
• Etiqueta (tag)
  
  Una etiqueta es un concepto similar al de una rama, pero sin desviarse de la línea de código principal. Una etiqueta marca un punto concreto al que poder regresar para revertir cambios.

Leer más