Git para matemáticos 3: Comándos básicos y el día a día.

Esta es la primera de una serie de entradas donde hablo de una herramienta que aprendí a usar hace relativamente poco: git.

1. Introducción y instalación y configuración inicial.
2. Repositorios locales y web.
3. Comandos básicos y el día-a-día.
4. Submódulos (pendiente).
5. Ramas (pendiente).
6. Git y Overleaf (pendiente).
7. Disclaimer: Esto no pretende ser un tutorial completo de cómo usar git y no solo eso, es muy probable que los conceptos no sean exactamente como los platico en estas entradas. Yo no soy un experto en git y más bien me enfocaré en cómo lo uso en la práctica. Si crees que algo de lo que digo puede mejorar, déjalo en un comentario. Por otro lado, la mayoría de lo que diga llevará referencias, pero si algo no queda claro, por favor, házmelo saber.

Me enfocaré en los usos prácticos para alguien que jamás ha usado git. Si tú ya lo usas con frecuencia pero te enfrentas a algunos de mis problemas, las referencias en los enlaces deberían ayudarte.

Comandos básicos de git

En esta entrada vamos ahora sí a meternos de lleno a git. Al final de esta entrada deberías de ser capaz de dejar dropbox y usar git como tu controlador de versiones de todos los días. Incluso, si te quitas el miedo, hasta podrías empezar a colaborar con otros. Después planeo escribir con detalle esta parte, pero con los conocimientos adquiridos hoy, debería bastan para los arriesgados.

A continuación voy a explorar los comandos básicos de git: add, commit, pull y push. Es importante mencionar que no pretendo entrar en detalles acerca de estos comandos, pues, como dije antes, me interesa que los lectores de estas entradas se animen a usar git más que a entenderlo a profundidad. De cualquier manera, para detalles sugiero consultar la documentación.

El contexto para el uso de estos comandos es el siguiente. Supón que ya tienes un repositorio llamado articulo que ha sido vinculado a un repositorio web, como se explicó en otra entrada. Estás dispuesto a comenzar a trabajar, lo cual incluye agregar, modificar o borrar algunos archivos. Además, te gustaría tener tu trabajo "respaldado" en el servidor web al final del día, digamos, por ejemplo, por si quieres llegar a tu casa a seguir trabajando. Dropbox hace esto que menciono de manera automática, así que si quieres pensar esta entrada como la manera de darle la vuelta a Dropbox, está perfectamente bien. Por ahora dejaremos la posibilidad de que colaboradores fuera de esta entrada. En un futuro se discutirá cómo hacer esto.

Para hacer esto explicaré en palabras muy mundanas lo que hacen cada uno de los comandos.

• add: Le dice a git que comience a rastrear un archivo (puede ser uno nuevo en el proyecto o uno modificado). Esencialmente lo que hace es decir "hey git, esto se modificó".
• commit: Guarda el status actual del repositorio. Una manera de pensarlo es que "le toma una foto" a la versión actual de los archivos. Es probablemente el comando más importante de git.
• pull: Descarga la copia más reciente del servidor web y la "mezcla" con los archivos del repositorio local.
• push: Toma la copia del repositorio local, y la sube al servidor web. Esencialmente, funciona como pull pero en la otra dirección.

Habiendo "entendido" estos comandos, les voy a mostrar cómo me funciona a mí un día a día en git en un repositorio al que solamente yo tengo acceso (probablemente en más de una computadora), pero en el cual no va a suceder que dos personas modifiquen los archivos al mismo tiempo.

1. Descarga la última versión del repositorio en el servidor web:
   

   $ git pull

2. Modifica los archivos, trabaja, guarda los archivos cuantas veces sean necesarios. Borra y renomba archivos (ver nota abajo). En fin, trabaja.
3. Cada que un archivo llegue a su versión final de la sesión de trabajo, agreǵalo.
   

   $ git add NombreDelArchivo

4. Cuando hayas terminado de trabajar en este proyecto, o que vayas a tomar una pausa o lo que sea. Haz un commit, es decir, guarda una copia del status el proyecto.
   

   $ git add * #esto es por si se te olvidó agregar algún archivo
   $ git commit -m "Sesión de trabajo muy dura, se hizo bla bla bla"

5. Finalmente, sube todo al servidor web, para que se sincronice.
   

   $ git push

Algunas notas importantes a tomar en cuenta:

• Cuando renombres o borres archivos, hay que hacerlo con git, para evitar dolores de cabeza.
  

  $ git rm ArchivoABorrar
  $ git mv ArchivoOriginal ArchivoRenombradoOMovido

  Si se te olvida hacerlo con git, cuando intentes hacer commit va a dar lata, pero el mensaje de error de git usualmente es amable te dice cómo salir del problema.
• No olvides empujar todo al servidor. Me ha pasado que llega el viernes y no lo hago y entonces intento trabajar el fin de semana y en el servidor solo está la copia vieja. No es tan grave, git te ofrece la posibilidad de hacer eso y hacer que las cosas luego se mezclen bien, pero es mejor evitar dolores de cabeza.

Con esto ya deberías animarte a mandar a volar Dropbox para escribir tus cosas y animarte a usar git.

Git para matemáticos 2: Repositorios locales y web.

Esta es la primera de una serie de entradas donde hablo de una herramienta que aprendí a usar hace relativamente poco: git.

1. Introducción y instalación y configuración inicial.
2. Repositorios locales y web.
3. Comandos básicos y el día-a-día.
4. Submódulos (pendiente).
5. Ramas (pendiente).
6. Git y Overleaf (pendiente).

Disclaimer: Esto no pretende ser un tutorial completo de cómo usar git y no solo eso, es muy probable que los conceptos no sean exactamente como los platico en estas entradas. Yo no soy un experto en git y más bien me enfocaré en cómo lo uso en la práctica. Si crees que algo de lo que digo puede mejorar, déjalo en un comentario. Por otro lado, la mayoría de lo que diga llevará referencias, pero si algo no queda claro, por favor, házmelo saber.

Me enfocaré en los usos prácticos para alguien que jamás ha usado git. Si tú ya lo usas con frecuencia pero te enfrentas a algunos de mis problemas, las referencias en los enlaces deberían ayudarte.

Repositorios, repositorios locales y repositorios web.

En esta entrada vamos a trabajar con la estructura básica de git: los repositorios. Aprenderemos qué son, a crearlos y a trabajarlos de manera local y de manera web. Luego hablaremos de cómo confirgurar las cosas para que la sincronización con la web funcione.

Bueno, al grano ¿qué es un repositorio? "Repositorio" es la palabra fresa que usa git para un "proyecto". Es decir, cuando hablo de un repositorio, normalmente estoy hablando de un proyecto andando. En términos prácticos, un repositorio es simplemente una carpeta a la que se le ha pedido a git que registre los cambios. Es la semilla básica de trabajo en git y es una estructura realmente sencilla. A su vez, permite que sea muy versátil. Por ejemplo, yo tengo un repositorio para cada uno de mis artículos, uno para cada charla que he dado este año, uno para mi tesis de doctorado, uno para mis referencia bibliográficas, uno para mi página pesonal y uno en una carpeta donde tengo todos mis dibujitos.

Existen esencialmente dos maneras de hacerse de un repositorio en tu sistema. Tomar una carpeta existente e iniciar un repositorio en ella o clonar un repositorio existente en algún otro lugar. Vamos a explicar la primera.

$ cd ruta/a/la/carpeta/articulo
$ git init

O alternativamente

$ git init ruta/a/la/carpeta/articulo

Desde ahora nuestra carpeta articulo es un repositorio de git (y debemos tratarla con el respeto que se merece si queremos que git se porte bien, pero más de eso después).

Nuestra carpeta es un repositorio local es decir, a pesar de que con git podemos rastrear todo lo que suceda en nuestra carpeta y por ejemplo, restaurarla a una versión antigua, si lo que queríamos en un inicio es que git se convirtiera en nuestra herramienta de respaldo, sincronización y colaboración, aún estamos muy lejos. La manera de lograr este objetivo es a través de los repositorios web.

A grandes razgos un repositorio web es un repositorio que existe en algún servidor en internet. Entre los más populares figuran GitHub, BitBucket y GitLab. Cada uno ofrece cosas distintas cosas pero todos funcionan más o menos igual: creas una cuenta y esto te da derecho a tener cierto número de repositorios (públicos o privados) con cierto número de colaboradores. Todos tienen una versión gratis y una versión de pago que usualmente mejoran lo que ofrecen. Los dejo que ustedes decidan, pero yo en lo personal uso la versión gratis de BitBucket. Algo importante es que usualmente el espacio en servidor no es un asunto, a diferencia de Dropbox. Estos servidores están pensados para guardar repositorios de git y a veces tienen restricciones en el tamaño de estos, pero hasta la fecha este no ha sido un problema para mí.

A partir de este momento supondré que ya crearon una cuenta en su servidor favorito y que ya saben cómo crear un repositorio en esta cuenta. Usualmente esto es muy fácil y cada uno de los servidores tienen instrucciones muy detalladas al respecto. Una vez que crean un repositorio en el servidor, este automáticamente tiene un link (usualmente encontrarlo no es nada difícil). También supondré que ya saben obtener ese link.

Ahora explicaré la otra forma de hacerse de un repositorio: clonar un repositorio existente. Esto es extremadamente fácil una vez que ya se tiene el link del repositorio web. Basta usar el comando

$ git clone https://linkDelRepositorio.git

Voy a usar como ejemplo un repositorio que tiene el template de mi tesis de doctorado. Para hacer esto simplemente hay que correr.

$ git clone https://amontero90@bitbucket.org/antonio_montero/thesistemplate.git

Y ahora tú tienes una copia de mi repositorio en tu computadora el cual puedes trabajar como a ti te plazca. Este será el resultado cada que se clona un repositorio web.

Vincular un repositorio local y uno web.

Ahora que ya sabes que existen los repositorios web y los locales vamos a explicar un poco lo de la sincronización. El proceso es relativamente sencillo. Lo que hay que hacer es que tu repositorio local rastree un repositorio web. Para ellos hay esencialmente dos maneras. Digamos que vas a empezar un proyecto, entonces el proceso a seguir es bastante sencillo:

1. Crea un repositorio vacío en tu servidor de preferencia. 
2. Clona ese repositorio a tu computadora. 

Como resultado de esto se creo una carpeta "vacía" en tu computadora. En realidad esta carpeta tiene algunos archivos ocultos que precisamente es lo que usa git para funciona. Ahora puedes trabajar en esa carpeta, crear archivos y demás. Luego habrá que decirle a git que rastree esos archivos, pero de eso más después.

Si más bien estás en la situación de que ya tienes un repositorio local con algunos archivos, lo que hay que hacer ahora es vincularlo a un repositorio web. Para ello lo que hay que hacer agregar un remoto a tu repositorio existente. En realidad lo agregas a la rama en la que estás trabajando, pero ignora por un segundo esas cosas técnicas. Para agregar un remoto lo que hay que hacer es lo siguiente.

1. Crear un repositorio vacío en tu servidor de preferencia.
2. Vincularlo a tu repositorio local.

Para hacer lo segundo basta ejecutar

$ git remote add origin https://linkDeTuRepositorioVacio.git

dentro de tu repositorio local. A partir de este momento ya existe el vínculo entre tu repositorio web tu repositorio local. A esta operació le llamaremos vincular un remoto; será útil después.

Git para matemáticos 1: Introducción, configuración inicial.

Esta es la primera de una serie de entradas donde hablo de una herramienta que aprendí a usar hace relativamente poco: git.

1. Introducción y instalación y configuración inicial.
2. Repositorios locales y web.
3. Comandos básicos y el día-a-día.
4. Submódulos (pendiente).
5. Ramas (pendiente).
6. Git y Overleaf (pendiente).

Disclaimer: Esto no pretende ser un tutorial completo de cómo usar git y no solo eso, es muy probable que los conceptos no sean exactamente como los platico en estas entradas. Yo no soy un experto en git y más bien me enfocaré en cómo lo uso en la práctica. Si crees que algo de lo que digo puede mejorar, déjalo en un comentario. Por otro lado, la mayoría de lo que diga llevará referencias, pero si algo no queda claro, por favor, házmelo saber.

Me enfocaré en los usos prácticos para alguien que jamás ha usado git. Si tú ya lo usas con frecuencia pero te enfrentas a algunos de mis problemas, las referencias en los enlaces deberían ayudarte.

Introducción y el cómo acabé en esto.

Voy a tratar de ser lo más concreto posible. Git es un controlador de versiones super popular entre la gente que se dedica a hacer programación. De hecho, me atrevería a decir que prácticamente cualquier proyecto de software suficientemente serio usa git para su desarrollo. Incluso muchos que no son suficientemente serios.

La idea detrás de git es que funciona local y no es centralizado. ¿Qué quiere decir esto? Que en general, no es necesario tener una "copia principal" del proyecto. Cada colaborador puede (y debería) tener una versión del proyecto en su propia computadora sobre la cual puede trabajar y después usar git para que las cosas se mezclen sin hacer un desastre.

La mayoría de los matemáticos no tenemos grandes proyectos de software a nuestro cargo. Muchos de nosotros apenas y sabemos programar. Sin embargo, sí hay algo que casi todos nosotros hacemos: escribir artículos/tesis/tareas/reportes, etc. Además, muchas veces estos incluyen colaboración con más de una persona. Así que una vez que averigüé de qué iba Git, me pareció que escribir un artículo con varias personas debería ser pan comido. Así que me surgió la pregunta natural ¿por qué no la usa todo mundo? Creo que la respuesta más natural que se me ocurre es que Git parece ser muy complicado.

Y no me malinterpreten, no es complicado pero sí es un poco más complicado que usar Dropbox o Overleaf, dos de las herramientas que entre mis conocidos son las populares pare realizar la tarea de compartir y administrar archivos (). Del primero puedo hablar bastante, hasta hace poco era mi plataforma favorita para administrar mi trabajo. Del segundo, no sé mucho, pero pienso de hablar de él en una entrada futura. Permítanme contarles el problema particular que me animó a echarme un clavado a git:

Uso Bibtex para administrar la bilbiografía que uso (si no saben qué es, den click en el nombre al inicio de la linea, no se arrepentirán). Durante años, en mi carpeta de Dropbox hubo un archivo bib.bib que servía de base de datos para los artículos que usualmente uso como referencia. Dado que ya es una base de datos bastante grande, cada que iniciaba un nuevo proyecto simplemente copiaba este archivo a la carpeta de Dropbox asociada al proyecto. Sin embargo, hacer esto hace que haya un problema de inconsistencia.

Para fines del ejemplo suponga que tengo una carpeta que se llama tesis y una carpeta que se llama artículo. Suponga además que artículo está compartida con Coautor Pérez. Entonces al iniciar el proyecto en artículo copio el archivo bib.bib a artículo. Luego Coautor agrega algunas entradas a este archivo. Unos días después inicio el proyecto tesis y copio mi archivo bib.bib en este nuevo proyecto. Nota que ahora tengo dos archivos bib.bib en mi sistema: el original y el modificado por Coautor que es ligeramente más grande. Digamos que a medio proyecto tesis decido usar algunas de las entradas añadidas por Coautor. Si tengo suerte, copie el archivo más grande dentro de tesis si no, entonces las añado a mi archivo y ahora tengo probablemente tres archivos bib.bib distintos. Supongan ahora que en lugar de solo dos proyectos, tengo 5 que van cambiando con el tiempo y eso ¿ven el potencial desastre que viene?. Esto se resolvería fácilmente si pudiéramos usar algo como enlaces, de tal forma que cuando modificamos alguno de los archivos bib, todos los demás se actualizan a ese, pero resulta que en Dropbox los enlaces no funcionan bien.

Resulta que este problema se resuelve muy bien a través de submodulos, de los cuales también hablaré en alguna entrada futura. Por ahora voy a dejar la motivación por aquí y me voy a enfocar en el primer uso de git para alguien que jamás lo ha usado.

Instalación de git y configuración incial.

Para detalles finos acerca de lo que voy a decir, sugiero consultar la documentación de git. En particular, para fines de la instalación sugiero consultar este enlace.

Quizás este sea un buen momento para mencionar que yo encuentro mucho más fácil usar git en la linea de comandos. Sé que hay herramientas gráficas pero no las conozco lo suficiente como para escribir estas entradas con ellas. Tal vez luego las explore y escriba de ellas, pero luego. No voy a suponer que sabes hacer muchísimo en la línea de comandos (a la que llamaré más de una vez consola), pero sí que sabes qué es, cómo abrirla en tu computadora y como copiar código de aquí y pegarlo en la consola.

Instalación en Linux

Si tu sistema es ubuntu o algo similar, simplemente basta usar los comandos usuales:

$ sudo apt-get install git-all

Aunque lo más probable es que ya esté instalado en tu sistema.

Instalación en Windows y Mac

Resulta que tanto para Windows y para Mac existen paqueterías completas que instalan Git. Parece ser que la de windows incluso tiene interfaz gráfica. Yo no uso ninguno de estos dos sistemas, así que me disculpo por no conocer ninguno de los usos en ellos, pero de cualquier manera, estoy seguro que lo que voy a decir en lo que resta de esta entrada y en las potenciales siguientes servirán una vez que git esté instalado.

• Paquetería para Mac aquí.
• Paquetería para Windows aquí.

Configuración inicial.

Asumiré ahora que ya tienes git instalado en tu computadora. Hay que hacer una configuración básica para proceder. Para ello introduciremos nuestros primeros comandos en git. En general, la estructura de un comando de git es la siguiente

$ git comando [opciones]

Por esta ocasión exploraremos el comando config el cual tiene esencialmente tres maneras de actuar: global, local y system, las cuales se explicarán con ejemplos. Para más detalles acerca de este comando ver este enlace.

La opción system determina las opciones del sistema a usarse, global las del usuario y local las del repositorio específico. Tal vez ahorita esas palabras no hagan mucho sentido, pero es bueno mantener esto en mente. Si las opciones entran en conflicto, local sobre escribe global y ésta a su vez sobre escribe system.

Por ejemplo, los siguientes comandos configuran el nombre de usuario a nivel global, el correo electrónico que quedará en el registro a nivel local y el editor de texto por defaul a nivel sistema. Las primeras dos configuraciones son útiles para llevar el registro de quién hace cambios en los archivos y la última para que git ejecute el comando adecuado cuando necesita abrir un editor de texto. Note que podría valer la pena configurar el email a nivel global también.

$ git config --global user.name "Pito Perez"
$ git config --local user.email "pito@perez.mx"
$ git config --system core.editor "kate"

Živi življenje...

Hace mucho tiempo decidí abrir mi blog personal, simplemente por que me gusta escribir y guardar registro de las cosas que suceden en mi vida. La verdad, es que a pesar de este gusto, me cuesta mucho trabajo sentarme a escribir una entrada completa.

Hoy es domingo en la noche, y se cumplen cuatro semanas de que llegue a Eslovenia. Creo que es un buen pretexto para escribir la primera entrada.

Eslovenia es un país chiquitito al este de Italia, sur de Austria y oeste de Croacia. Hace un poco más de 25 años era parte de Yugoslavia. Tiene algo así como 2 millones de habitantes. Yo vivo en Ljubljana, la capital y ciudad más grande, con un poco menos de 300 mil y algo más de medio millón en su cerradura.

Durante estas semanas he aprendido muchísimas cosas, tanto de la ciudad y el país, como de mí mismo. Trataré de compartir las que vengan a mi memoria mientras escribo esto.

La gente en general es amable. Son fríos y el contacto personal casi no existe, pero tienden a ser amigables. Los eslovenos te saludan cuando te encuentran en la calle aunque no te conozcan. Una buena parte de la población habla inglés; sobre todo los jóvenes, pero ya llegaremos al asunto de los idiomas después.

Una de las cosas más difíciles fue llegar por primera vez en mi vida a un país que tiene invierno de verdad en medio de (según uno de mis roomies y mi casero) el invierno más frío en un par de décadas. El frío fue difícil, pero la verdad creo que esperaba más. Tuve dos semanas con nieve y temperaturas bajo cero. Durante las últimas semanas ha sido lluvia mayormente y temperaturas alrededor de cero. Afortunadamente el frío y yo nos llevamos bien. Lo que sí comienza a molestarme, incluso anímicamente, es la falta de sol. Ljubljana está en un valle que, combinado con el invierno, produce niebla todos los días. Esto hace que sea difícil cachar algunos rayos de sol. Solamente ha habido sol "de verdad" un día en las últimas cuatro semanas.

Vivo en un segundo piso de una casa en las orillas de la ciudad. Aún así, el centro me queda a 10 minutos en camión y a unos 25 caminando. El departamento está habitado además por dos mexicanos, estudiantes de doctorado en matemáticas, con quienes he hecho una muy buena amistad. Ya nos conocíamos antes de vivir juntos, pero sin duda alguna ha sido una de las mejores experiencias. Tal vez les dedique una entrada futura.

El anfitrión de mi tutor (y por lo tanto nosotros dos) está en la Facultad de Educación (Pedagoška Fakulteta, PeF, en cortito) de la Universidad de Ljubljana. La universidad está regada por toda la ciudad, en particular la facultad de Física y Matemáticas está del otro lado de Ljubljana. En la PeF tengo una oficina que comparto con la chica con la que vivo y con dos empleadas de la Universidad. En la PeF no hay muchos estudiantes de posgrado y por lo tanto no es común que los estudiantes tengan oficina. De ahí que nuestras compañeras sean empleadas de la Universidad.

Eslovenia es barato, para estar en Europa. La cerveza, el pan y la leche cuestan más o menos lo mismo que en México. El autobús cuesta 1.20 Eur. cada viaje, pero se pueden comprar bonos mensuales por 37 Eur. para ciudadanos usuales, por 20 Eur. para estudiantes. Hablando de los beneficios de ser estudiante, existe un programa de comidas baratas para estudiantes. Alrededor de la ciudad hay muchos (de verdad, muchos) restaurantes afiliados al programa. Los requisitos para el beneficio son mínimos y puedes obtener comidas casi a mitad de precio. Entonces por 2 o 3 euros tienes una comida bastante completa en estos restaurantes.

El esloveno es toda una plática y creo que le dedicaré una entrada después, pues esta ya se está haciendo muy larga. Por ahora ya puedo saludar a las personas y preguntarles si hablan inglés. Por supuesto, sé decir que no entiendo y que no hablo esloveno. También puedo ya comprar algunas cosas en el super sin andar con el traductor a la mano. El título de la entrada quiere decir "viviendo la vida" de acuerdo al traductor de google. Termino la entrada con una foto de un cacho de Ljubljana y los Alpes.