Taller de git de Hack Madrid.

Fotografía de Daniel Mery

El pasado día 27 tuve la suerte de poder asistir al Taller de git organizado por Hack Madrid.

Gracias a este evento, y a esta entrada que leí en el tren camino del taller, he podido retomar mi viejo e interrumpido proyecto y comenzar a respaldar lo que voy ajustando en mi openbox.

Tened claro que esto no es el inicio de una serie sobre git, ni un curso completo, sino solo una puesta en orden de lo que pude probar en el taller, y de mi primera prueba, solo, en mi equipo, para que no se me olvide.

Os cuento …

Nociones básicas.

Que es el control de versiones.

Esto parece bastante obvio, pero no todo el mundo lo tiene claro.  Hay que entender que el control de versiones es tan antiguo cómo la escritura en si misma, ya que hace referencia a cualquier cambio en un texto, o en su acepción más amplia, en un producto  o en las características del mismo.

Su difusión actual, en el mundo de la informática, nace de la necesidad de los programadores de identificar los cambios hechos en su código, siempre demasiados y demasiado rápido, lo que hace un control manual prácticamente inviable, y de ahí que se haya dado a múltiples sistemas automatizados para hacerlo.

De todos ellos quizás el más conocido sea git desarrollado por Linus Torvalds durante su trabajo en el núcleo de Linux.  El boom de la Web, el trabajo colaborativo de las comunidades de Software Libre y OpenSouce, y la necesidad del trabajo en equipo han dado lugar a la aparición de repositorios en la nube, de los que los más conocidos son GitHub y GitLab.

Teniendo en cuenta lo anterior, si se piensa un poco, se entiende fácilmente que un control de versiones no es más que, una serie de fotografiás en el tiempo del estado de un archivo, sea del tipo que sea, que permite reconstruir en cualquier momento una situación anterior.

Estas fotografiás, pueden estar almacenadas en nuestro propio sistema – control de versiones local -, en un repositorio centralizado en un red local – control de versiones centralizado -, o en la web – control de versiones distribuido -.  Esto lo podéis ver mucho mejor explicado aquí.

Puesta en Marcha.

Visto todo lo anterior, nos centramos ya en el objeto de esta entrada, que no es otro que un uso simple de git, una aplicación que viene por defecto en cualquier distribución de GNU/Linux, por lo que su instalación no da para mucho, pero vamos, por que quede claro:

$ sudo apt install git

Crear cuenta GitHub o GitLab.

Una vez instalada nuestra aplicación, el paso siguiente, si vamos a querer compartir esos contenidos en la web, será el de crearnos una cuenta en cualquiera de las dos plataformas más conocidas, GitHub o GitLab.  Que cada uno elija su suerte, yo para este ejemplo he usado GitHub.

Configuración básica.

El siguiente paso es decirle a nuestro git quienes somos mediante estos comandos:

$ git config –global user.name "mi_nombre"
$ git config –global user.email "mi_email"

Estos dos datos se corresponden a los que hayamos utilizado para crear nuestra cuenta en GitHub o GitLab.  Si, cómo suele ser habitual, ansias, que sois unos ansias ;), lo hacéis en ambas, usad los mismos datos.

Para comprobar que hemos introducido correctamente los datos podemos usar:

$ git config –list

Uso.

Estados de los archivos.

Para entender el funcionamiento hay que tener claro que git trabaja en tres áreas:

  1. Working area: Es la carpeta en la que mantenemos los archivos de los que queremos llevar el control de versión (la carpeta de nuestro proyecto).
  2. Staging area: Es un estado intermedio en el que indicamos a git que ese archivo esta listo para someterse a control (ya lo damos por bueno).
  3. Repositorio: Es la base de datos en que se almacenan las fotos de las diferentes versiones. Esto se guarda en una carpeta .git, que no es recomendable tocar, dentro de la carpeta que estemos controlando.

Para verlo más claro quizás os sirva esta imagen:

Añadir el control de versiones a una carpeta.

El siguiente paso es indicar a git que carpeta queremos controlar – nuestro proyecto -. En mi caso, voy a comenzar a hacer seguimiento de los cambios que efectúo en mi openbox, por lo que me ubico en mi carpeta correspondiente y ejecuto la inicialización del control de versionest:

$ cd .config/openbox/
$ git init
  Initialized empty Git repository in home/asim.config/openbox/.git/

Es importante no olvidar que podemos crear en nuestra carpeta un fichero .gitignore, en el que incluir las rutas de archivos o carpetas que no queremos sean controlados – si es que los hay -.

Ver la situación de nuestro repositorio.

Una vez hecho lo anterior tenemos una forma para revisar la situación de nuestros ficheros:

$ git status

que nos indica lo siguiente:

On branch master
Initial commit
Untracked files:
  (use "git add <file>…" to include in what will be committed)

        autostart
        debian-menu.xml
        menu.xml
        rc.xml

nothing added to commit but untracked files present (use "git add" to track)

Vamos a suponer que estamos satisfechos con nuestro fichero autostart, así que haríamos:

$ git add autostart

Si ahora repetimos:

$ git status

veremos este resultado:

On branch master
Initial commit

Changes to be committed: (use "git rm –cached <file>…" to unstage)

  new file: autostart

Untracked files: (use "git add <file>…" to include in what will be committed)

  debian-menu.xml
  menu.xml
  rc.xml

Es decir nos dice:

  • Estamos en la rama principal
  • El fichero autostart esta en la staging area
  • El resto de ficheros siguen en la working area.

Para subir todos ellos, una de las opciones más habituales es:

$ git add .

No os repetiré el status por no ser más reiterativo.

Hacer un commit.

Una vez que tenemos los ficheros que interesan en la staging area, vamos a hacer un commit, es decir una foto, de la situación actual de nuestro repositorio:

$ git commit -m "Estado inicial de mi Openbox"

Esta será mi primera “foto” de configuración de openbox, a partir de la cual iré controlando los cambios que haga.  El texto entre comillas, no es más que un pequeño recordatorio de el por qué de la foto.

Subir al repositorio.

Cómo os comenté al principio, la gracia de todo esto es la de poder colaborar con los proyectos que nos interesen, para lo que necesitamos un repositorio remoto, que en mi caso, sólo usaré para respaldo y para compartir la configuración entre mi escritorio y mi portátil.

Aquí sólo os voy a contar cómo yo he subido mi commit, pero en la serie de Colaboratorio que os indico en referencias tenéis un artículo entero dedicado a cada uno de estos aspectos, con mucha más información y os recomiendo leerla toda con atención.

En mi caso los pasos han sido los siguientes:

  1. En la Web.
    • Entrar en mi página de github: Una obviedad sin nada que explicar.
    • Crear un repositorio openbox: Tan simple como ir a nuestra pestaña de repositorios, pulsar el botón verde de “New” y seguir las indicaciones.
    • Obtener la dirección de ese repositorio: Una vez creado el repositorio en so botón verde “Clone or Download” tomamos la dirección del repositorio.

Con esto hecho tenemos que ir a nuestra consola para hacer la subida, pero hay que tener en cuenta, que al crear el repositorio, nos habrá creado un fichero LICENSE, si la hemos elegido, y un README.md para describir el proyecto, por lo que un push directo nos dará un error – os lo prometo que a mi me ha pasado -.

Lo primero que debemos hacer es sincronizar nuestro repositorio local con el remoto, así que los pasos son:

  • Conectar nuestro repositorio con el remoto:
$ git remote add origin "dirección del repositorio"
  • Traer el contenido creado en el repositorio remoto:
$ git pull origin master –allow-unrelated-histories

Si no incluimos la opción –allow … recibiremos error.

  • Actualizar el contenido:
$ git push origin master

Nos pedirá  el nombre de usuario y la clave de acceso – creo que hay forma de evitarlo, pero aún no sé como – :(.

Y ya está, eso es todo, ya tengo mi carpeta de openbox respaldada en GitHub.  A partir de aquí tocar trabajar y avanzar por las ramas sin perderse, pero eso quedará para otra.

Esto es todo amigos,  bueno sólo falta una cosa que me ha dado gran alegría, aunque sea una pequeñez:  Esta es mi primera entrada con un nuevo flujo de trabajo, ha sido íntegramente creada en org-mode de Emacs y exportada como HTML.  Sólo he hecho en WordPress la última revisión y la inserción de imágenes.

Un fuerte abrazo virtual y ya sabéis:

¡No dudéis en criticar, corregir o sugerir!, así aprendemos todos.

Referencias.

Más allá de las citas que puedan aparecer en el artículo, dejo aquí, los enlaces sin los que esta entrada nunca hubiese sido posible, como agradecimiento y reconocimiento al trabajo de sus autores.

En este caso no puedo dejar de agradecer el trabajo de Elena Mateos López y MrCodeDev que impartieron el taller, a los que estoy muy agradecido por su interés y claridad.  También, he leído y recomiendo, sobre todo para profundizar más, la gran serie de ATAREAO en Colaboratorio que comienza con esta entrada.

Algunas referencias importantes que nos pasó Elena:

Otra que a mi me ha parecido básica y otra entrada que marca unas buenas prácticas que creo imprescindibles para entenderse en este mundo colaborativo.

Si hubiese alguna omisión solo es fruto de mi despiste decirlo y se resolverá de inmediato.

2 pensamientos en “Taller de git de Hack Madrid.

  1. genial post, yo tengo el uso de git tan interiorizado, que no entiendo no trabajar con git…. Solo me gustaria hacer un comenterio sobre los mensajes cuando haces un commit, esos mensajes se recomiendan que tengan un formato, hay una guia de buenas practicas… una vez que la usas, tiene su utilidad cuando ves los listados historicos de commit y todos tienen un formato similar…

    The seven rules of a great Git commit message

    Keep in mind: This has all been said before.

    Separate subject from body with a blank line
    Limit the subject line to 50 characters
    Capitalize the subject line
    Do not end the subject line with a period
    Use the imperative mood in the subject line
    Wrap the body at 72 characters
    Use the body to explain what and why vs. how

    • Muchas gracias por la información – añado a las referencias el post original, ya que me parece más que interesante.
      Por lo demás agradecido por tu comentario, sé que el tema es muy de principiante, pero es lo que soy 🙂 y a Dios gracias, procuro aprender algo cada día.
      Un saludo.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.