Del control de versiones de software usando Git y Github (1)

Hace unos cuantos meses entre amigos y compañeros de trabajo empezamos a usar determinadas aplicaciones para agilizar el desarrollo de las herramientas que usamos en el día a día, teniendo experiencia de otros trabajos con Subversion y algo de práctica con GiT sugerí el uso de Github y Gitorious, con la idea de descentralizar el desarrollo y no depender de una conexión a la red para poder hacer las actualizaciones necesarias, que en el caso de Subversión; esa es su mayor contra.

Si bien es cierto que en las primeras pruebas con Github este no me llamaba mucho la atención, ya que al principio se encontraba restringido a 5 proyectos lo cual no resultaba práctico teniendo en cuenta que a las pocas semanas había surgido una opción con menos restricciones: Gitorious.

Inmediatamente me di a la tarea de conocer Gitorious dejando de lado Github, sin embargo estas dos aplicaciones aún se quedaban cortas para llevar todo el proceso de Administración de Cambios: registro de incidentes, histórico de cambios, procesos documentados, seguimiento a tickets, planeación, etc.. algo en lo que la gente de Google ya había trabajado al lanzar GoogleCode.



Se que para muchos el uso de estas herramientas es tarea cotidiana, también me he encontrado con quienes aún les resulta una tarea compleja; como quiera que sea el tema es sencillo siempre que vaya acompañado de práctica y dado que en los últimos días he retomado este tema al estar capacitando a uno que otro compañero, les platicaré cual ha sido mi  experiencia a este respecto y si les resulta útil ó consideran que son necesarios más detalles, trabajaremos en ello.

Lo primero será tener una cuenta en Github, el cual es un proceso muy sencillo: escoge un álias, registra una cuenta de correo, contraseña y listo! Toma en cuenta que este solo es el primer paso, ya que para poder subir código será necesario contar con una llave publica registrada en Github, esto quiere decir que será necesario crear nuestro par de llaves en SSH; si bien las guías para realizar todo este proceso se encuentran muy bien documentadas en el sitio de Github, haremos una pequeña reseña para conocer el proceso. Por cierto, se hecha de menos OpenID ya que de esta manera podrías asociarla a tu cuenta en Gmail por ejemplo y se evitaría la creación de un usuario y contraseña mas, sin embargo es solo una opinión. Considera que para proyectos OpenSource la tarea de la gestión de tu cuenta es sin costo y puedes subir tantos repositorios quieras, la condición es: compartir.

Linux/OSX
1. Abrir una terminal de shell
2. Ejecutar el siguiente comando para crear una llave de 2048 bits y almacenarla en nuestro directorio raiz

4. Esto nos va a generar dos archivos, de los cuales tomaremos el archivo que termina con .pub (en este caso la llave pública) que tendrá un contenido similar al siguiente:

5. Y lo registraremos en github, en la sección de Editar Perfil->Editar Llaves Públicas SSH

Ahora bien, podemos probar con cualquier proyecto que sea de nuestro interés, en mi caso tomaré WLPass (cortesía del buen Diego Ubach) para describir un flujo sencillo de GiT.
1. Realizar un fork del proyecto

2. Pedir un clon del proyecto a Github con GiT

3. Crear un branch para trabajar en los cambios locales (v0.1-201012.20)

4. Hacemos unos cuantos cambios
(en este caso, agregar el .gitignore donde declaro archivos que no voy a usar y borrar el directorio de build de NetBeans)

5. Y los registramos para llevar el histórico, en este caso a nivel de archivo; esta es una buena practica ya que los cambios se registran por componente.

6. Nos regresamos al master para registrar los cambios en la rama principal

7. E integramos los cambios de la rama en la cual hemos trabajado a la rama principal

8. De esta manera, empujamos los cambios que hemos realizado a Github para llevar el control del proyecto.

9. Ya desde el sitio de Github podremos verificar los cambios realizados.

El proceso sencillo y como comento, solo se requiere algo de práctica; dejaré para la siguiente la parte de integración de parte del dueño del proyecto y la homologación de los cambios. Si observas hay varias opciones que husmear en Github, una que creo importante (aunque algo incompleta) es el de los issues pero dejaremos ese tema para el siguiente post.

Cosas que revisar:

  • git clone
  • git checkout 
  • git checkout -b
  • git commit
  • git merge
  • git push

Referencias:
  • Github
    • http://www.github.com
  • Gitorious
    • http://www.gitorious.org/
  • Manual en linea de GiT
    • http://git-scm.com/
  • OpenSSH
    • http://www.openssh.com/

buen camino...!

Popular Posts