Después del incidente de haber perdido parte de el codigo en el que estaba trabajando, me di cuenta que me haría bien tener un repo con el historial de cambios bien establecido para poder revisar lo que he hecho antes en caso de tomar un camino equivocado.

Introducción

Pues verás, no me gusta git. Por pura flojera la verdad. Eso de andarme aprendiendo códigos me parecía tedioso y tener que hacer commits y push a cada rato era un fastidio. Aparte, ¿para mas de subir a un repo publico? para eso solo copio el código a una carpeta y la comparto por samba, nextcloud, syncthing, etc. Es obvio que estaba malinterpretando git.

Para comenzar, git no es una bodega. Malinterpreté esto por culpa de github. La mayoría de la gente solo usa git para publicar en github y ahí queda todo. Normal que piense que solo es una bodega publica. (Antes de que me linches, me refiero a la mayoría de noobs). A veces incluso como consejo los pro suelen decir que publiquen en github a modo de hoja de vida, lo que refuerza esa impresión entre los noobs como yo.)

Por supuesto, tampoco podía apreciar el aspecto colaborativo de git (de hecho no lo aprecio todavía) porque pues, no colaboro con nadie. Así que en cuanto a mi respecta, git era una herramienta muy popular, pero irrelevante para mi.

Aquí te dejo la explicación de la IA que se la habrá sacado de las partes mas oscuras de sus circuitos (o sea, es una mezcla de varias fuentes que me da pereza citar, pero son muy comunes). Pero parece que lo que dice es cierto.

Git es un sistema de control de versiones distribuido (VCS, por sus siglas en inglés) que va mucho más allá de ser solo una «bodega de código». Su propósito principal es rastrear y administrar los cambios realizados en archivos (comúnmente código fuente) a lo largo del tiempo, permitiendo a los desarrolladores colaborar eficientemente y gestionar el historial del proyecto

Git funciona registrando «instantáneas» (llamadas commits) del estado de tus archivos en momentos específicos. Esto te permite navegar por el historial del proyecto y, si es necesario, restaurar versiones anteriores.

¿Es solo una bodega de código?

No. Aunque almacena código, es mucho más que un simple servicio de almacenamiento de archivos. Es el sistema que permite todas las operaciones de control y gestión mencionadas anteriormente.

Plataformas como GitHub, GitLab, o Bitbucket son servicios de alojamiento web que proporcionan una interfaz gráfica y herramientas adicionales (como gestión de proyectos y seguimiento de problemas) que utilizan Git como su tecnología subyacente. El software Git en sí mismo es una herramienta local que gestiona el control de versiones en tu propio ordenador.

El Problema

Soy flojo. Eso de base. Y es fácil sorprenderse que no quiera aprenderme algunos comandos de git o siquiera entenderlos porque bueno, soy programador. Pero es que no le cojo gusto. Especialmente por el lado que malinterpretaba a git como una bodega de archivos, que es justo la razón por la que estoy escribiendo esto. GitHub permite (o permitía, creo que eso cambio con la compra por parte de microsoft) que solo sea gratis los repos públicos. Y escribo tantas tonterías que me daba vergüenza dejar en publico mis desgracias. ¿Podría haber usado bitbucket que si permite cuentas privadas gratuitas? Si. De hecho tengo una cuenta allí, pero ¿pa’ que? mis prejuicios estaban sembrados y mucho de lo que escribo, lo abandono.

Bueno, Necesitaba una excusa para aprender y al mismo tiempo, no quería dejar en público mis vergüenzas. Tras mucho investigar, encontré CGit, que no logré hacer funcionar y por accidente «descubrí» que Git se usaba originalmente por correo electrónico. Podría agregar esta función a mi articulo sobre «cosas que puedes hacer con tu viejo correo electronico». Por supuesto, esto será con fines didácticos. Todo apunta a que es un fastidio mayor de lo que ya era git naturalmente, pero bueh, detallitos. Luego creo que investigare Gogs, porque me interesa tener un repo público para dejar en publico los códigos que mas me interesan.

Gastando pólvora en Gallinazos

Como estoy muy lejos del mundo de git, ni sabia que aun ahora el kernel de linux trabaja mediante el uso de envío de parches por correo electrónico, sin depender de plataformas de github. Parece que el proceso se realiza de esta manera y ya el resultado final es lo que se publica en el perfil de GitHub.

Aun no comprendo del todo el flujo de trabajo, pero por el momento, lo importante es empezar. Si esto se hace muy extenso y no he perdido el interés, podría publicar después otra parte explicando el flujo de trabajo.

Esto es lo que tienes que tener en cuenta para seguir este flujo de trabajo:

Preparar los cambios

En lugar de usar git push, utilizas el comando git format-patch para empaquetar tus commits locales en archivos de texto con formato de «parche» (archivos .patch). Estos archivos contienen todas las diferencias de código y metadatos del commit (autor, fecha, mensaje).

Ejemplo:

git format-patch master

Este comando crea archivos como 0001-Mi-primer-parche.patch, listos para ser enviados por correo.

Enviar el parche

Git incluye una herramienta de línea de comandos llamada git send-email que formatea y envía estos archivos de parche como correos electrónicos correctamente estructurados a una lista de correo o a un mantenedor específico del proyecto. Déjame advertirte que si usas Linux, es muy probable que la herramienta de git send-email es muy probable de que no este instalada. Recuerda instalarla con tus comandos preferidos.

Configuras Git con los detalles de tu servidor SMTP (el servidor de correo saliente), y luego ejecutas:

git send-email --to="mantenedor@ejemplo.com" 0001-Mi-primer-parche.patch

Aplicar los cambios: git am

El receptor del correo electrónico (el mantenedor del proyecto) recibe el parche. En lugar de fusionar una «pull request» en una interfaz web, utiliza el comando git am (de «apply mbox») para aplicar el parche directamente a su repositorio local.

git am 0001-Mi-primer-parche.patch

Este comando aplica el parche, recreando el commit original exactamente como tú lo creaste en tu máquina.

¿Por qué se usa este método?

Aunque el flujo de trabajo con GitHub/GitLab es más popular hoy en día porque es más visual y fácil para principiantes, el flujo de correo electrónico tiene ventajas:

• Descentralización real: No dependes de ningún servicio web de terceros. Solo necesitas acceso a un servidor de correo SMTP estándar.
• Revisión de código integrada en el correo: Las revisiones y comentarios se hacen respondiendo al correo electrónico, y esas respuestas pueden ser leídas e importadas por Git.
• Simplicidad del formato: El formato de parche es un estándar abierto y duradero.

Es interesante como este método se considera como poco amigable con el principiante, mientras que el tradicional y «facil» me resulta aun mas complicado todavia XD.

Inicializando un repo git listo para enviar por email

En realidad, es una tarea bastante sencilla si ya has usado esta herramienta. Solo cambian unas cuantas cosas como las que cité anteriormente. Pero hay detalles que hay que tener en cuenta al hacerlo de esta manera.

Recuerda que para esto, necesitas tener instalado Git y tener acceso a un servidor SMTP de correo. Funciona con gmail y hotmail, claro.

Por cierto, no te preocupes. Estas configuraciones no alteraran tu uso normal de git. Solo le permiten acceder a las funciones que necesitamos para este articulo.

Configura git para correo electrónico

En tu consola ejecuta lo siguiente, configurando los campos con tus necesidades particulares:

# Tu nombre y correo electronico que apareceran en los commits 
git config --global user.name "Tu Nombre" 
git config --global user.email "tu-correo@ejemplo.com" 
# Detalles del servidor SMTP 
git config --global sendemail.smtpuser tu-correo@ejemplo.com 
git config --global sendemail.smtpserver smtp.ejemplo.com 
git config --global sendemail.smtpserverport 587 
git config --global sendemail.smtpencryption tls 
git config --global sendemail.smtpauth true 
# Opcional: para que pida la contraseña interactivamente 
git config --global sendemail.smtppass "TU_CONTRASEÑA_DE_APP"

Recuerda que servicios como gmail pueden necesitar una clave de autenticación en lugar de la contraseña. Asegúrate de investigar como se configura en esos casos. Yo me lo ahorro porque uso mi propio servidor XD.

Crea un proyecto local

Vamos a crear un proyecto para probar el funcionamiento de esto.

mkdir proyecto-correo-git 
cd proyecto-correo-git 
git init 
echo "Hola mundo" > README.md 
git add README.md 
git commit -m "Commit inicial" 
echo "Nueva linea" >> README.md 
git add README.md 
git commit -m "Segundo commit con cambios"

Empaqueta los cambios como parches

Recuerda estar atento a que nombre de rama tienes. En mi caso, me ha salido una advertencia indicando que la rama que ha inicializado es la de master, pero que en proximas versiones será llamada main.

Usa git format-patch para convertir los commits en archivos de parche. Le diremos que empaquete todos los commits desde el inicio (master) hasta ahora:

git format-patch master

Esto creará archivos con nombres como 0001-Commit-inicial.patch y 0002-Segundo-commit-con-cambios.patch.

Bueno, así debería ser, pero en mi caso no funcionó.

Intenté saltarme estos pasos para saber si funcionaba lo demás, pero gracias a este articulo, supe que el formato patch incluye todos los datos que se necesitan para enviar por el correo, razón por la cual se debe enviar mediante el comando apropiado y descargar, no el adjunto, sino todo el archivo original del correo.

Pues veras. Esto depende de que ya estes trabajando activamente en tu proyecto, pero temporalmente, lo que haremos es usar el comando git format-patch -3, donde 3 es el numero de los últimos commits que desees enviar.

Esto generará 3 archivos .patch que te permitirán continuar con el tutorial.

Como curiosidad, te muestro como se ve uno de los archivos de patch:

From 6fb0dc7e5eea4bb7e221a3450137a2bdadefa2f5 Mon Sep 17 00:00:00 2001
From: Drk0027 <drk0027@interlan.ec>
Date: Thu, 4 Dec 2025 10:52:43 -0500
Subject: [PATCH 1/3] primer commit

---
 README.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 README.md

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..c41d5e0
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+"hola mundo" 
-- 
2.52.0.windows.1

Si te das cuenta, tiene el aspecto de un archivo de correo. Indica el archivo inicial, cuantos archivos de patch son y que ha cambiado en cada archivo.

Envía el parche por correo electrónico

Ahora usa git send-email para enviar estos archivos a la dirección de correo del «mantenedor» (que puede ser tu otra dirección de correo para probar):

git send-email --to="receptor-del-parche@ejemplo.com" *.patch

Git usará la configuración SMTP del Paso 1 para enviar los correos. Recibirás mensajes de confirmación en la terminal.

Para mal de mis males, este comando no funcionó para mi. Tras investigar un poco, lo que funcionó para mi fue enviarlos uno por uno con esta variación:

git send-email 0001-primer-commit.patch --to tu@correo.com

Recibir y Aplicar los Parches (Lado del Receptor)

En el ordenador del receptor (o en tu bandeja de entrada de prueba):

• Recibir el correo: Abre el cliente de correo donde recibiste los mensajes.
• Guardar el correo como archivo de texto: Es crucial guardar el correo en su formato original, generalmente como un archivo .eml o mbox, asegurándote de que no se corrompa el formato del parche.
• Usar git am: El receptor navega a su propio repositorio Git local (o crea uno si no existe) y usa git am (apply mbox) para aplicar el archivo de correo:

cd mi-repo-receptor 
git init 
# Guarda el correo recibido como 'parche.eml' en esta carpeta 
git am parche.eml

Con esto ya el receptor tiene su repo listo para ser trabajado. Por supuesto, Puedes transferir los archivos patch de la forma que quieras, siempre que apliques los parches en orden.

Enviando el repo entero por correo

Para enviar un repositorio de Git por correo electrónico, la mejor manera es usar el comando git bundle para empaquetar el repositorio completo en un solo archivo y luego adjuntar ese archivo al correo electrónico.

Pasos para enviar el repositorio por correo electrónico

Crea un archivo bundle del repositorio.

Navega hasta la raíz de tu repositorio local usando la terminal o línea de comandos y ejecuta el siguiente comando:

git bundle create repo_proyecto.bundle HEAD

Este comando crea un archivo llamado repo_proyecto.bundle que contiene todo el historial de commits y ramas, desde el HEAD actual (la última versión).

Adjunta y enviar el archivo bundle por correo

Utiliza tu cliente de correo electrónico habitual (Gmail, Outlook, etc.):

1. Redacta un nuevo correo electrónico.
2. Adjunta el archivo repo_proyecto.bundle que acabas de crear.
3. Envía el correo al destinatario deseado.

El destinatario recupera el repositorio

La persona que recibe el correo debe guardar el archivo repo_proyecto.bundle en su máquina y luego puede clonar el repositorio a partir de este archivo, en lugar de una URL remota.

En su terminal, debe ejecutar:

git clone repo_proyecto.bundle

Esto creará una copia local completa del repositorio original con todo su historial. Recuerda que el resultado es binario y solo incluye los archivos que hayas hecho commit. Esto significa que no se enviaran los archivos .patch que creaste anteriormente. (tampoco los necesitas para el bundle)

Conclusión

Te voy a ser sincero. Sigo sin entender para que sirve Git XD

O sea, me hago una idea, pero ahora voy a tener una excusa para tratar de entender y trabajar mejor con esta tecnología. Ya desde ahora recién comprendo que no se hace un commit cada edición de los archivos, sino que se lo hace cada que te sientas satisfecho con lo que has hecho decidas que es la fase mas estable de tu trabajo.

Otra cosa que entendí con esta practica, es que Git no es una bodega. Esto significa que no es un sistema para organizar tus archivos ni tampoco un lugar de almacenaje (github lo es, mas o menos)

Por ultimo, también entendí que no es una herramienta de sincronización. Es cierto que permite sincronizar los cambios entre todos los usuarios que participen en el proyecto, pero si tu intención es desplegarlo, no es apropiado que uses git para actualizar en el destino los cambios que hagas en local. Si bien se puede, no es nada recomendable.

Conforme vayas aprendiendo a dominar git, también te darás cuenta de que hay cosas que es mejor ignorar. por ejemplo, las monstruosas carpetas de node_modules, los archivos .env, la carpeta Vendor, etc. Esto es especialmente sensible si publicas en github.

Enlaces adicionales

Tutorial de como enviar un parche por correo electrónico.

https://petereisentraut.blogspot.com/2009/09/how-to-submit-patch-by-email.html

Tutorial de como se usa git send-email

https://blog.bisect.de/2012/01/how-to-send-patches-via-git-send-email.html