Archivo de la etiqueta: git

Lo que he aprendido: magit

He empezado a usar Magit. Tanto escuchar Magit es el mejor modo para git jamás creado y yo empecé a usar Emacs por Magit me han convencido a darle una oportunidad. Eso y que el modo git normal que usaba no me carrula bien en el ordenador del curro (¡Windows!).

La cuestión es que Magit me flipa, puedo manejar mi repo desde Emacs solo dando a un par de teclas y ayudando por tanto a mis pobres bracitos lesionados por el ordenador.

Lo más curioso de este modo es que funciona a base de ventanitas (pop ups) en las que se nos dan opciones diversas. A cada ventanita se accede con una tecla y podemos acceder a la ventanita de las ventanitas con h (help). Cada ventanita se divide en dos pedazos, en la parte superior activamos las opciones y en la inferior elegimos el comando. No os preocupéis que enseguida lo veremos todo mucho más claro.

Por cierto, si como yo usáis Emacs con GUI y menús (¡sacrilegio!) tendréis en la barrita un menú de Magit con las diferentes órdenes y sus teclas correspondientes.

Lo básico: status, add y commit

Empezamos a usar Magit en un repositorio existente diciéndole que nos muestre el estado del mismo en una de sus ventanitas con la siguiente orden:

M-x magit-status RET
magitStatus

La ventanita de estado

Sigue leyendo

Lo que he aprendido: la nube como repositorio remoto

Después de commitear 600MB en imágenes de Matlab pensé que algo había que hacer si no quería romper GitLab, que ya se rompe bastante por sí solo. Estuve jugando con los interiores de git y me divertí mucho, pero finalmente decidí dejarlo, eliminar el repositorio y hacer uno nuevo decentemente. Ahí fue cuando apareció el blog de Notxor con su flamante nueva entrada sobre git. Resulta que él en lugar de usar un servicio del estilo de GitHub tiene su propio repositorio remoto en su nube, en este caso una Nextcloud. ¡La solución a mis problemas de espacio!

Veamos cómo he adaptado el proceso a mi caso.

El repositorio central

He optado por utilizar como remoto una carpeta que tengo sincronizada en el Google Drive mediante la herramienta Copia de seguridad y sincronización ya que en el currelo tenemos mucho almacenamiento en el Drive (lo que tiene venderle tu alma a Google).

Ahí he creado un repositorio bare, es decir, uno en el que no hay árbol de trabajo. En un repo de este tipo en lugar de haber una carpeta .git con las movidas de git y luego nuestro archivos, hay solo lo que suele haber en la carpeta .git a pelo. La idea de esto es que sea un repositorio central, no uno donde se trabaja. Así, los colaboradores enviarán allí su código (push) y recuperarán los cambios (fetch/pull).

Para crear uno que se llame repo.git hacemos:

git init --bare repo.git

Se suelen apellidar .git para diferenciarlos de los repositorios normales y corrientes.

El repositorio de trabajo

Ahora que ya tenemos creado el repo remoto nos queda configurar el local. Aquí tenemos varias alternativas dependiendo de la situación en la que estemos

  • Si no hemos empezado a currar todavía, clonamos el repo vacío en algún punto de nuestro ordenador. Nuestro repo clonado sí tendrá árbol de trabajo:
git clone RUTA/repo.git 
  • Si ya tenemos el repo local, pero no hemos establecido el remoto:
git remote add NOMBRE RUTA/repo.git
  • Si es un repo cuyo remoto es otro y queremos cambiarlo o añadir uno adicional:
git remote set-url NOMBRE RUTA/repo.git

Ahora ya podemos funcionar normal entre ambos repositorios, igual que si estuvieran en GitLab y el Drive, Dropbox, Nextcloud o lo que sea se encargará de sincronizar nuestros repo central.

¡Muchas gracias a Notxor por compartir lo que sabe con todos nosotros! 😀

Referencias

Cómo estoy utilizando git en el blog de Notxor

How do you use “git –bare init” repository? en StackOverflow

What is a bare git repository?

git init en el manual

Push to only bare repositories

Using Git and Dropbox together effectively? en StackOverflow1


Mientras escribía oía:


  1. ¡Gracias a Notxor por el enlace! 

Lo que he aprendido: git y Matlab

Acabo de descubrir de una manera tontísima que Matlab se da cuenta de que el contenido de una carpeta está bajo control de versiones. Abrí una carpeta con mi código octaviano en Matlab y vi que junto a cada archivo salían chirimbolillos de colores:

git

El punto verde significa que estamos vigilando el archivo y no ha sufrido modificaciones (tracked and unmodified en la jerga) y el cuadradito azul que lo tenemos controlado pero que ha cambiado (tracked and modified). También nos puede aparecer un punto blanco que quiere decir que no tenemos el archivo bajo control (untracked).

Estos simbolitos los veremos a pesar de que no tengamos git instalado, si lo tenemos instalado podremos además añadir y commitear desde la propia interfaz de Matlab. Si hacemos click derecho en algún punto de la ventanita de los archivos veremos que tenemos una opción de Source control desde la que tenemos acceso a las acciones típicas que solemos hacer desde la terminal en versión visual.

matlab

Una cosa importante es decirle a git que archivos de Matlab como los fig y los mat son binarios para que no nos hurgue en ellos y nos los estropee. Para eso tenemos el archivo .gitattibutes, que situamos (generalmente) en la raíz del proyecto y que nos sirve para decirle a git como manejar sus asuntos. Matlab recomienda nuestro .gitattributes tenga esta pinta:

# Marcar como binario
*.mat -crlf -diff -merge
*.fig -crlf -diff -merge
*.p -crlf -diff -merge

Esto le indica a git que no haga ni diff ni merge en esos tipos de archivo y que no toque el final de línea. También podrían marcarse directamente con binary que es equivalente a -text -diff -merge, donde -text es a su vez equivalente a -crlf, es decir, a no tocar el final de línea.

En resumen, no creo que vaya a hacer commits desde la interfaz de Matlab, pero me parece útil ver el estado de cada archivo con un simbolito. También lo veo interesante para acercar a los ingenieros de la piedra y el palo (como yo) al mágico mundo del control de versiones. Conozco a muchísimos que programan en Matlab cosas grandes y serias y a casi ninguno que tenga su código controlado.

Referencias

Set Up Git Source Control en la página de MathWorks

Git for Windows

Git Attributes

Lo que he aprendido: limpiar un repo

Leyendo por ahí como es mi costumbre me he encontrado con un par de trucos de git para hacer limpieza en nuestro repo. La limpieza en cuestión tiene dos partes: eliminar los archivos que hemos creado nosotros pero que no queremos tener bajo control y que el propio git adecente sus historias.

Quitar nuestras mierdas

Para eliminar de un plumazo todos los archivos a los que no estemos haciendo un seguimiento simplemente hacemos:

git clean -f

La -f viene de force, nos obliga a escribirlo si queremos que borre, es precavido él.

Este comando tiene varias opciones interesantes:

  • -d elimina también las carpetas
  • -i inicia el modo interactivo
  • -n no elimina de verdad pero vemos una lista de archivos que eliminará.

Podemos usarlo en combinación con git reset --hard para devolver el repo al estado en el que estaba justo tras el último commit. Otra aplicación interesante es cargarnos los archivos auxiliares que aparecen al compilar algo, es especialmente útil si los tenemos en el .gitignore, así no nos saldrán al commitear y tendremos el repo bien limpio.

Yo lo uso concretamente para matar los archivos auxiliares de LaTeX, que llega un momento en que me agobian y no sé qué demonios es lo que tengo que modificar. Mi .gitignore en un proyecto latexiano suele tener esta pinta:

# Ignorar archivos auxiliares de Latex

! *.tex
! Contenido/
! Figuras/

De esta manera, si me organizo en condiciones solo tengo bajo control los archivos necesarios y puedo destruir el resto con git clean.

Adecentar las cosas de git

Aparte de borrar nuestras basuras, git también es capaz de hacer limpieza sobre sus archivos. Para ello tenemos este simpático comando:

git gc

Sirve para que git gestione mejor el espacio y quite las referencias que ya no sirven, por ejemplo. Podemos ejecutarlo con la opción --auto para que actúe solo si es necesario. No os puedo decir en detalle qué hace ya que git es una cosa muy loca, pero me parece un comando a tener en la recámara, sobre todo en los proyectos grandes o con archivos binarios (como los pdfs).

Nada más por hoy, ¿qué trucos de git usáis vosotros, gentes del Internet? Contadme para que aprenda 🙂

Referencias

Man de git clean

Man de git gc

Undoing Changes en el tuto de Atlassian

Is there a way to clean up git? en StackOverflow

git gc: cleaning up after yourself git-fu

Git Tip of the Week: GC and Pruning


Bailando en la cocina:

Lo que he aprendido: registro de cambios en un documento LaTeX con git

Estoy echando una mano a mi hermano con una documentación to guapa para un tema que mejor os cuenta él y me preguntó cómo incluir un registro de cambios en el documento. Un registro de cambios no puede ser muy complejo de hacer si estamos usando git, pensé, así que me puse a investigar las diferentes alternativas, empezando por la opción evidente: git log.

Jugando con git log

Empecemos por los inicios, como todos los que usáis git sabéis mejor que yo, git log nos permite dar un formato al historial de commits con las opciones --pretty y --format. Por ejemplo, podemos mostrar la fecha y la descripción del commit haciendo:

git log --pretty=format:"%ad%x09%s" --date=short > cambios.log

Seguir leyendo →

Lo que he aprendido: borradores en Jekyll

Siguiendo con mis investigaciones jekylleras hoy he aprendido a manejar borradores. Os lo cuento.


Jekyll trata como borradores a los artículos sin fecha que guardamos en la carpeta _drafts/. Para ver cómo quedaría nuestra página con los borradores añadidos, simplemente la creamos con la opción --drafts activada:

jekyll serve --drafts

El borrador se convertirá en una entrada cuya fecha es la fecha de modificación. Me volví muy loca porque tenía una fecha añadida en el bloque YAML (porque copié de otro) y aquello no carrulaba, andad al loro.

No hay una manera directa de publicar un borrador, yo lo muevo de la carpeta _drafts/ a _posts/:

git mv _drafts/borrador.md _posts/AAAA-MM-DD-nombre-artículo.md

Lo hago con git mv porque tengo el contenido de la web bajo control de versiones.

Referencias

Working with drafts en la docu de Jekyll

Imagen vía Attribution Engine. Licencia CC0.

Lo que he aprendido: wikis, git y Gollum

Cuando el otro día GitLab murió, a Mr Frog y a mí casi nos da un patatús. Tenemos un proyecto conjunto ultrasecreto ahí y durante algunas horas de horror pensamos que habíamos perdido todo. Evidentemente, los archivos del proyecto en sí los teníamos en local pero las Issues y la wiki estaban en peligro. Lo de las Issues era grave porque funcionamos en una especie de test driven development (aunque no sea un tema de programación) pero lo de la wiki era catastrófico, ya que es lo que usamos para documentar el proyecto. Y ya sabéis, la documentación es la vida. En fin, que cuando se solucionó el desastre decidimos hacer copias de todo para evitar el apocalipsis nuclear. 

Aquí es donde entra en juego Gollum. No ese Gollum del tesssoro, sino un cacharro para crear wikis basadas en mi amado git. Resulta que las wikis de Gitlab no son más que un repo como otro cualquiera que se puede clonar y tal. La diferencia es que si queremos jugar con ellas en nuestro ordenador tenemos que usar el mencionado Gollum. Digamos que Gollum es a las wikis lo que Jekyll es a los blogs. 

Veamos como se usa. Lo primero es ver cuáles son los requisitos que debemos cumplir para poder instalarlo. De su docu sabemos que es una gema de Ruby que necesita lo siguiente:

SYSTEM REQUIREMENTS

- Python 2.5+ (2.7.3 recommended)
- Ruby 1.8.7+ (1.9.3 recommended)
- Unix like operating system (OS X, Ubuntu, Debian, and more)
- Will not work on Windows (because of grit)

Como lo tenía todo, lo instalé con:

sudo gem install gollum

Me dio un error al intentar instalarlo porque no tenía ni zlib ni libicu-dev, que solucioné fácilmente con:

sudo apt-get install zlib1g-dev libicu-dev

y volviendo a repetir la orden gem install.

Ahora que ya tenemos Gollum perfectamente instalado, clonamos la wiki como cualquier otro repo:

git clone .../proyecto.wiki.git

Ahora si queremos que nos cree la wiki localmente hacemos simplemente en la carpeta que hemos clonado:

gollum

Nos dirá que podemos ver la wiki y editarla en localhost:4567. También podemos modificar los archivos y commitear desde la terminal.

Me parece una herramienta muy interesante, le daré mucho uso. Espero que a vosotros os guste también 🙂

Referencias

Gollum

GitLab Gollum-lib

Gollum the git-enabled wiki

Gollum por Darcy Moore vía Attribution Engine. Licencia CC BY-NC-SA.

Lo que he aprendido: .gitkeep

A veces se me activa el modo Windows y en vez de crear un repositorio en la terminal como Dios manda, voy a GitHub o GitLab o lo que sea y me monto allí mi sistemita de archivos y hasta escribo y todo usando la web. En uno de estos momento de debilidad, me puse a crear un repo para mis apuntes de italiano en GitLab. Al crear una carpeta me fijé en que me había aparecido dentro un archivo vacío llamado .gitkeep que no tenía ni idea de lo que era.

Una investigación rápida me dio la respuesta: como git no puede seguir el rastro de carpetas vacías, existe una convención (no soportada oficialmente por git) por la que se le añaden archivos .gitkeep a las carpetas vacías que se quiera que git monitorice. Técnicamente ese archivo podría tener cualquier nombre y ni tendría que empezar por punto, lo lleva simplemente para permanecer oculto.

Muy curioso.

Enlazando con las curiosidades, os dejo con una de las versiones más curiosas con las que me encontrado: Eskorbuto en modo folk

Referencias

What are the differences between .gitignore and .gitkeep?

Multiple .gitignore files versus .gitkeep files

GitLab Issue: Create new folder from Web GUI

Lo que he aprendido: git stash

Haber aprendido a usar control de versiones por tu cuenta y riesgo, ser el único de tu entorno laboral que lo usa y para colmo de males ser ingeniero industrial tiene sus problemas. El principal es que no tienes integrado el control de versiones en tu metodología de trabajo y las acabas liando petardas. Empiezas a trabajar en una cosa y luego te das cuentas de que tenías que haber creado una rama, quieres probar dos cosas a la vez y no sabes cómo, etc. En esos casos yo echo mano de mi comando favorito: git stash

Este simpático bicho lo que nos hace es guardarnos el estado actual del repo aparte para que quede limpio y podamos trabajar en otras cosas. Mirad:

$ git stash
Saved working directory and index state WIP on master: 7fe4722 First commit

Luego podemos aplicar los cambios que hemos dejado en espera. Tenemos dos maneras:

git stash pop # lo aplica y lo elimina de la lista de stash
git stash apply # lo aplica pero lo mantiene

Yo uso el apply cuando quiero probar algo que tengo a medio hacer en una rama en otra rama diferente. Si luego queremos que lo quite hacemos:

git stash drop

Por último, me queda decir que podemos hacer más de un stash, git irá poniendo en la lista y podremos acceder a ellos usando su etiqueta. La lista de stash se ve así:

$ git stash list
stash@{0}: WIP on master: 7fe4722 First commit

Por ejemplo, si hubiera un stash número dos podríamos aplicarlo haciendo:

git stash apply stash@{2}

Nada más por hoy. ¡Investiguen y comenten!

Referencias

6.3 Git Tools – Stashing en el Pro Git

Documentación de git stash

Lo que he aprendido: bitácora de un proyecto con Emacs + git

Os voy a contar una idea que tuve ayer para documentar lo que voy haciendo en la tesis. Resulta que Emacs tiene un modo agenda y un modo calendario y pensé que en lugar de usarlos como una agenda de toda la vida podría usarlo como cuaderno de bitácora, ya sabéis que a mí me gusta trucar todo. A ello vamos.


Modos calendar y diary

Antes de nada una pequeña intro sobre estos dos modos. Haciendo M-x calendar Emacs os mostrará un calendario de tres meses centrado en el mes actual. Si queremos introducir una anotación en la agenda nos abrirá lo que él llama diary y al que se puede acceder mediante M-x diary. Es decir, después de organizar un poco las ventanas nos queda algo así:

diary

Podemos apuntar cosas dando botón derecho en el día concreto y eligiendo Insert diary entry, desde la barra superior en Diary > Insert entry o situando el cursor en el día en sí y haciendo i y luego d. Allá cada cual con sus manías.

Este diario nos lo guarda con el nombre diary en la carpeta home en GNU/Linux y en C:\Users\AppData\Roaming en Windows. Es un archivo de texto plano.

Control de versiones para la colaboración

Luego pensé que si ponía este archivo bajo control de versiones y en un repositorio en la red era posible que diferentes personas añadieran sus aportaciones al bitácora. Así se convierte en la herramienta definitiva de documentación para un proyecto. Sabemos quién ha hecho qué y cuando. Podría hacerse lo mismo con una wiki, claro, pero esto nos da la ventaja de que los fans de Emacs (como yo) no tienen que salir nunca de él 😛

He añadido un .gitignore para que git solo se fije en los cambios del archivo diary:

# Ignorar todo excepto diary

*.*
*/*
diary~

!diary

¡Listo! ¡Ya tenemos una nueva manera de documentar nuestros progresos! Espero que os sea útil.

Más

El manual de los modos calendar y diary