Cuando pensamos en trabajar con un amigo en un proyecto pequeño, instintivamente creamos un repositorio en GitHub o GitLab. Esta práctica, o reflejo, es relativamente moderna. Pero aunque parezca extraño, se puede colaborar/trabajar en proyectos sin usar hostings de Git. Aunque parezca impensable, antes no existían este tipo de servicios, y el software se desarrollaba con igual o más calidad.

El flujo de trabajo consiste en conectar git con tu correo electrónico, o en enviar parches a la bandeja de entrada del mantenedor. Git está diseñado para soportar este flujo de trabajo de forma nativa, contiene un conjunto de herramientas para facilitar cada uno de los pasos. De hecho es utilizado a día de hoy por proyectos muy importantes como el kernel de Linux, QEMU, GNU o Git mismo. No pienses ni por un momento que es un método obsoleto o anticuado.

Sus ventajas son varias:

• No dependes de una plataforma específica (GitHub, GitLab, etc).
• Se guarda una copia de las discusiones y parches entre los desarrolladores en listas de correo públicas.
• Puedes revisar código sin conexión (si has descargado los correos).
• Es un flujo de trabajo muy rápido de dominar.

Pero claro, también tiene sus inconvenientes:

• No es tan visual como usar un hosting de Git (GitHub, GitLab, etc).
• Requiere conocer algunas herramientas extra de Git.
• El mantenedor debe gestionar los parches y revisiones por correo.
• Si quieres que sea abierto, necesitas una lista de correo pública.
• No es tan sencillo para principiantes.

Y con lo dicho prepara tu café que vamos a la acción.

Configuración inicial

Antes de lanzarte a enviar parches, necesitas preparar tu entorno.

1. Configura tu identidad

Lo primero es asegurarte de que Git conoce tu nombre y correo. Estos datos aparecerán en tus commits y en las cabeceras de los parches que envíes. Es básico aunque no quieras enviar parches por correo.

git config --global user.name "Tu Nombre"
git config --global user.email "tucorreo@example.com"

2. Instala git-send-email

git-send-email es la herramienta que usarás para enviar parches directamente desde la terminal. Es opcional ya que puedes usar tu cliente de correo, pero es mucho más cómodo y evita errores de formato.

No viene instalada por defecto en todas las distribuciones, así que deberás instalarla manualmente:

# Debian/Ubuntu
sudo apt install git-email

# Fedora
sudo dnf install git-email

# Arch
sudo pacman -S git-send-email

Si usas macOS o Windows, tal vez ya la tengas incluida con Git o no. Dejo que lo investigues.

3. Configura el servidor SMTP

Para enviar correos necesitas conectarte a un servidor SMTP. Aquí te muestro las configuraciones típicas de Gmail, pero deberás adaptarlas a tu proveedor si usas otro.

Gmail:

git config --global sendemail.smtpserver smtp.gmail.com
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpuser tucorreo@gmail.com

Ten en cuenta que Gmail requiere una contraseña de aplicación. No uses tu contraseña normal, genera una específica para esta herramienta.

Con esto ya tienes todo listo para enviar parches por correo. Vamos a enviar nuestro primer parche.

Crear y enviar un parche

Ahora viene la parte interesante: hacer cambios en el código y enviarlos como parche.

1. Prepara tu entorno

Clona el repositorio del proyecto al que quieres contribuir y crea una rama nueva para tu trabajo:

git clone https://example.com/repo.git
cd repo
git switch -c mi-arreglo

2. Haz cambios y crea un commit

Modifica los archivos que necesites.

Usa la bandera -s al hacer el commit: esto añade automáticamente la línea Signed-off-by con tu nombre, que es obligatoria en muchos proyectos como forma de aceptar la licencia.

Signed-off-by no es una firma criptográfica, sino una declaración de que aceptas los términos del proyecto. Irá tu nombre y dirección de correo tal como lo tienes configurado en Git.

git add archivo-modificado.py
git commit -s

Está extendido que los mensajes sigan una estructura determinada, aunque es completamente opcional. La estructura típica es: resumen breve en la primera línea, línea en blanco, explicación detallada en varias líneas, otra línea en blanco y finalmente Signed-off-by (que se añade automáticamente con la bandera -s).

componente: descripción breve (máximo ~50 caracteres)

Explicación detallada del cambio. Aquí puedes extenderte
explicando el motivo, el contexto y cualquier detalle relevante.

Signed-off-by: Tu Nombre <tucorreo@example.com>

3. Genera el parche

Ahora viene la parte técnica: convertir tus commits en archivos de parche. Git incluye el comando format-patch que hace exactamente eso.

git format-patch -1 HEAD          # último commit
git format-patch -3 HEAD          # últimos 3 commits
git format-patch origin/main      # todos los commits desde main

Estos comandos generan archivos .patch en tu directorio actual. Cada uno contiene un commit.

4. Envía tu parche

Tienes 2 opciones, ya dependiendo de tus gustos.

Opción A: git send-email

Si has seguido los pasos anteriores, configurando git con la configuración SMTP de tu proveedor de correo, puedes enviarlos directamente con el comando:

git send-email --to=mantenedor@proyecto.org *.patch

Se encarga de todo. Es la forma más recomendada ya que evitará que tu cliente de correo estropee el formato.

Cuando tu contribución requiere varios commits relacionados, puedes enviarlos como una serie. Git facilita esto con la opción --cover-letter, que genera un correo de introducción donde explicas el conjunto de cambios.

git format-patch --cover-letter origin/main

Esto genera varios archivos: 0000-cover-letter.patch y uno por cada commit. Edita el archivo de la carta de presentación para explicar qué hace tu serie de parches y por qué es necesaria.

Luego envía todo junto:

git send-email --to=mantenedor@proyecto.org *.patch

Los revisores recibirán primero tu carta de presentación y luego cada parche como respuesta a ese hilo. Mantiene la conversación organizada.

Opción B: Cliente de correo

Si por alguna razón no puedes usar send-email, puedes hacerlo manualmente:

1. Genera el parche: git format-patch -1 HEAD --stdout > parche.txt
2. Copia el contenido en un correo nuevo
3. Envíalo en texto plano, nunca en HTML

⚠️ Muchos clientes modifican los espacios en blanco y rompen el formato del parche.

Versiones revisadas

Hay grandes posibilidades de que el mantenedor te pida cambios. ¡Forma parte del proceso!

Cuando necesites enviar una versión corregida, sigue estos pasos:

1. Modifica tu código

Haz los cambios que debas hacer y añádelos a staging.

git add archivo.lisp

2. Modifica el commit anterior

Para modificar el commit anterior lanza:

git commit --amend

Te abrirá el editor para modificar el mensaje.

Si no quieres hacerlo, preservando el mensaje actual:

git commit --amend --no-edit

3. Crea una nueva versión del parche

Crearemos la versión 2 del commit anterior.

git format-patch -v2 -1 HEAD

4. Envía el parche modificado

Ya está todo listo para enviarlo, aunque añadiremos algunas modificaciones.

git send-email \
  --to=mantenedor@proyecto.org \
  --in-reply-to="<id-del-mensaje-original>" \
  v2-*.patch

La bandera -v2 añade un prefijo [PATCH v2] al asunto del correo, dejando claro que es una nueva versión. Y el parámetro --in-reply-to hace que tu correo aparezca como respuesta al hilo original, manteniendo todo el contexto junto.

Ya solo te queda esperar.

Conclusiones

Claro, tiene su curva de aprendizaje. Configurar SMTP, entender format-patch, recordar añadir -s en los commits. Pero una vez que lo dominas, es tan natural como usar git en local. No dependes de ninguna plataforma o capas gratuitas que bailan a los caprichos del viento. El correo electrónico lleva aquí desde los años 70 y seguirá estando cuando las plataformas de moda cambien. Un flujo de trabajo que permite a miles de desarrolladores colaborar sin saturar ningún servidor centralizado. No es casualidad que proyectos tan importantes como el kernel de Linux lo sigan usando.

Espero que este pequeño acercamiento te ayude a colaborar con proyectos Opensource que de otra manera parecerían inalcanzables.