Ir al contenido principal

Escribir con Git I: Commit, log y revert

Mantener nuestros documentos controlados es fundamental a la hora de acometer cualquier trabajo. Da igual si se trata de escribir cuentos, novelas, tesis doctorales... En algún momento, nuestros documentos empezarán a bifurcarse, ya sea en diferentes versiones de borrador, ya sea en experimentos para avanzar en la historia.

La forma más simple de acometer esta labor es generando diferentes versiones de nuestros documentos. Sin embargo, esto requiere de un proceso manual. Es más, es posible que no recordemos en qué versión hicimos cierto cambio si sólo las diferenciamos de forma numérica. Por ese motivo, he estado investigando cómo aplicar Git, un sistema de control de versiones muy utilizado en desarrollo software, para escribir. En este tutorial os enseñaré las facilidades que nos ofrece y os compartiré un trabajo que he realizado para facilitarnos la vida.

¿Qué es Git?


Git es un sistema de control de versiones muy utilizado para el desarrollo de software. Sin embargo, puede aplicarse a muchos más ámbitos. Está basado en repositorios. Podemos crear uno de estos repositorios en cualquier carpeta de nuestro equipo. Dentro de estos repositorios, tendremos diferentes ramas para nuestro proyecto. A su vez, cada rama está compuesta por versiones o commits.

Además, git es capaz de trabajar con repositorios remotos. Estos repositorios pueden estar en nuestro área local, como otra carpeta de nuestro equipo o un disco duro externo, o en la nube. Esto nos permite mantener sincronizado y a salvo nuestro trabajo.

¿Por qué usar Git?


Vale, pero, ¿qué ventajas me ofrece realmente? Digamos que ya estoy trabajando en la nube, utilizando Dropbox, OneDrive o similar. Mi trabajo está a salvo. Además, puedo aprovechar las características de estos servicios para recuperar versiones antiguas de mis documentos. ¿Qué me aporta entonces?

La ventaja de usar Git es que podemos cambiar de rama o recuperar una versión de nuestros archivos específica de forma sencilla. ¿Por qué? Bueno, Git asigna un identificador único para cada commit. Se trata de una cadena de caracteres cifrada, así que eso no nos aporta mucha información. En cambio, lo que sí que nos es útil es el mensaje que podemos introducir para explicar cada commit, tan largo como queramos que sea. De esta forma, es fácil localizar cualquier cambio que hayamos realizado. Incluso podemos anotar los motivos que nos han llevado a ello.

Más aún, podemos marcar ciertos commits como más relevantes (tags). De esta forma, le daremos un identificador específico a esa versión de nuestro proyecto. Esto nos permite consolidar nuestro trabajo mediante commits sin preocuparnos de que no sean una versión definitiva, y luego asignar ciertos marcadores a los diferentes borradores, por ejemplo.

Incluso podemos combinar las características de ambos sistemas para mejorar nuestra experiencia. Una de las razones por las que no suelo usar el autoguardado en la nube de Word, por ejemplo, es que en un momento dado puedo arrepentirme de lo que he escrito. Cerrar el documento y olvidarme de ello es mucho más cómodo que borrar algo que, posiblemente, puede estar desperdigado por todas partes.. Pues bien, con Git eso se acaba. Podemos disfrutar de la comodidad del autoguardado sin preocuparnos, ya que, si no nos convence, simplemente daremos marcha atrás hasta nuestro último punto consolidado.

Por último, Git también nos ofrece la posibilidad de utilizar distintas ramas para un mismo proyecto. Pensad en el repositorio como una historia de commits. Estos commits pueden ser lineales o bifurcarse en diferentes ramas. Cada rama puede tener una evolución totalmente diferente. Pero, lo mejor de todo, es que si el trabajo que hemos hecho en una de estas ramas nos satisface, podemos incluirlo en la rama principal, que habitualmente se llama master o main. Y, lo mejor de todo, ¡de forma automática! Sí, puede que aparezcan algunos conflictos que debamos resolver de forma manual. Pero, sin duda, será más rápido que trasladarlos a mano.

Pensad que estamos escribiendo una novela. Llevamos 10 capítulos escritos. De repente, se nos ocurre algo que puede funcionar o tal vez no. Para ello, debemos hacer algunas modificaciones en lo que tenemos escrito, además de añadir algún que otro capítulo intermedio. No lo tenemos muy claro, así que abrimos una rama específica para este experimento. Mientras tanto, como tenemos que madurar la idea, seguimos trabajando de forma simultánea en nuestra rama master. Finalmente, decidimos que el experimento es exitoso. Sólo tenemos que mezclar (merge) nuestra rama experimento en master y... ¡voilá!

Preparar el entorno


Una de las cosas que me propuse cuando me lancé a investigar este asunto es que todo fuera lo más simple posible. No quería que se limitase a algo propio de gente con conocimientos técnicos. Lo mejor era que se pudiera beneficiar el máximo número de gente posible. Así pues, vamos al lío. Para poder seguir este tutorial será necesario disponer del siguiente software:


Si disponéis de las últimas versiones de Windows 10 o Windows 11, podréis usar el script de instalación que he introducido en el proyecto. Aunque, como mínimo, necesitaréis Git para poder clonar el repositorio del proyecto.

Clonar el repositorio de Story Seed


Story Seed es un proyecto que he confeccionado con el fin de facilitar el trabajo a la gente, sobre todo aquella que carece de conocimientos técnicos informáticos. Utiliza licencia Creative Commons, así que sois libres de utilizarlo como mejor os plazca. Podéis encontrarlo de forma pública en el     repositorio de GitHub (se abre en una ventana nueva).

Lo primero que tenemos que hacer es clonar el repositorio a nuestro equipo. En la página de GitHub, veréis un botón etiquetado como code. Al pulsarlo, se abrirá un panel donde podéis elegir el método de clonado (https será más conveniente para la mayoría de casos) y os da la posibilidad de copiar el enlace en cada caso. También ofrece la alternativa de descargarlo en zip.

Bien, pues una vez con este enlace, debemos clonarlo en nuestro equipo usando Git. O más bien, como hemos dicho que no vamos a requerir conocimientos técnicos, apoyándonos en TortoiseGit. Vamos a la carpeta donde queremos ubicar nuestro nuevo proyecto (no la del propio proyecto, sino la que lo va a contener). Hacemos click derecho con el ratón y elegimos la opción "Git Clone". Se abrirá un diálogo donde introduciremos la URL que hemos copiado de GitHub y elegiremos el directorio del proyecto. Por defecto, se llama igual que el proyecto clonado (story-seed en este caso), pero podemos cambiarlo a nuestro gusto.
    
Diálogo clone de TortoiseGit, donde se muestra la URL ssh del repositorio y el directorio de GitHub en el que vamos a clonarlo.

Una vez clonado, vamos a ver los siguientes elementos:

  • bin: Aquí se ubican diferentes scripts y accesos directos.
  • templates: Aquí se ubica una plantilla de documento con los estilos configurados de la forma habitual para escribir.

Comenzando a trabajar


Para empezar, podemos crear un nuevo documento. Ve a la carpeta bin y abre el acceso directo llamado LibreOffice Writer.bat o Word, si tienes instalado Microsoft Office. Si obtienes un error, es posible que tu ruta de instalación no coincida con la predefinida. Puedes editar este archivo con el bloc de notas y modificarla. Sólo busca en tu equipo el archivo "soffice.exe" y copia la ruta. Puedes hacer esto manteniendo la tecla shift (mayus) pulsada mientras haces clic derecho sobre el archivo. Aparecerá un menú más amplio en el que encontrarás la opción copiar como ruta de acceso. En el caso del acceso directo a Word, puedes editarlo mediante clic derecho en la opción propiedades. En este caso, el archivo que debes buscar es "winword.exe".

Escribe algo. Guárdalo en la carpeta del proyecto como un archivo .docx. Vuelve al explorador de archivos y sal de la carpeta del proyecto. Haz clic derecho en ella y elige la opción Git Commit -> "master" (puede aparecer otro nombre, en función de la rama actual). Aparecerá un diálogo donde puedes rellenar el mensaje. También puedes incluir la fecha del commit. Deberás incluir también tus datos como autor (nombre y email). Recuerda marcar el archivo que acabamos de crear para que el comit lo incluya.

Diálogo commit de TortoiseGit, donde se muestra un mensaje de ejemplo y los datos de autor rellenos.

¡Listo! Ya tenemos la primera versión del proyecto. Si hacemos clic derecho sobre el repositorio, abrimos el menú TortoiseGit y elegimos la opción 
show log, veremos un histórico de los commits realizados. En este caso, como el proyecto ha partido de Story Seed, también aparecen los commits de este, además del que acabamos de hacer.

Revertir cambios


Ahora, sobre nuestro documento, realizamos algún cambio. Por ejemplo, añadimos una línea. Tras ello, guardamos el documento. Supongamos que, después de haberlo hecho, el cambio que hemos hecho no nos convence. Para volver al estado en el que estaba en el último commit, hacemos clic derecho sobre el repositorio, vamos a TortoiseGit y elegimos revert. Nos aparecerán los ficheros que han cambiado y podremos elegir cuáles queremos devolver a su estado anterior. Como esta operación modifica los archivos, es necesario que los hayamos cerrado previamente u obtendremos un error.

Diálogo revert de TortoiseGit, donde aparece seleccionado el archivo que queremos devolver al estado que tenía en el último commit.

Resumen


Hemos visto algunas de las características más básicas de Git. En el siguiente tutorial veremos cómo podemos navegar a través de la historia de nuestro repositorio, recuperar estados antiguos de los archivos y trabajar con un repositorio remoto.

Comentarios

Entradas populares de este blog

Hola, me llamo Javier y soy abstinente

Hola, me llamo Javier, tengo veintinueve años y soy abstinente. Desde que tengo derecho al voto, he vivido tres elecciones generales; cuatro si contamos la repetición de las últimas. En las primeras, 2008, voté a ZP. No parecía que lo hiciera mal. Luego decidí abstenerme como muchos que no veíamos una opción buena. El hartazgo cristalizó en el 15M, nuevas formaciones y soplos de aire fresco para la política. Me decanté por votar a C’s y me sentí defraudado cuando hubo que repetir. ME planteé de verdad no regresar a las urnas, pero al final decidí hacerlo. Hoy, en 2019, vuelvo a la abstención.

Star Wars: El ascenso de Skywalker... ¿y la caída de las estrellas?

¡Muy buenas a todos! Vuelvo al blog para traeros mis reflexiones sobre la franquicia de Star Wars . Ayer vi en el cine la última entrega, que cierra esta tercera trilogía. Salí bastante decepcionado de la sala, aunque seguro que ya lo habíais adivinado por el título de esta entrada. En lugar de una review de la película, he preferido un nuevo formato. Aquí van las cosas que creo que la saga tiene que cambiar si quiere levantar el vuelo de nuevo. Y, de verdad, cuanto antes lo hagan, mejor. Si no, corre serio riesgo de caer en el ostracismo y convertirse en una reliquia de otra galaxia.