Eliminar un correo del historial de Git antes de que los brokers lo raspen

Por qué un correo antiguo permanece público

Un commit de Git es más que un cambio de código guardado. También almacena datos del autor, y eso a menudo incluye una dirección de correo. Si usaste un correo personal, de la universidad o de un antiguo trabajo hace años, esa dirección puede quedar adjunta al commit mientras exista el historial.

Esto sorprende a mucha gente porque cambiar el perfil generalmente no lo arregla. La configuración actual de la cuenta puede ser privada, pero los commits antiguos siguen manteniendo los metadatos originales a menos que reescribas el historial.

Los repositorios públicos empeoran el problema. Una vez que un repo es visible, otras personas pueden bifurcarlo, clonarlo, espejarlo, archivarlo o copiar parte en otro proyecto. Incluso si borras el repo después o actualizas tu perfil, esas copias pueden mantener el correo antiguo vivo en sitios que no controlas.

Esto aparece todo el tiempo en proyectos secundarios. Un estudiante sube código con la dirección de la universidad, se gradúa y pierde acceso a ese buzón. Alguien usa una cuenta Gmail personal para un proyecto de fin de semana, se olvida y deja el repo público durante años. El código envejece, pero los datos de contacto no.

Los raspadores y brokers de datos no necesitan enviarte mensajes para recopilar esa dirección. Pueden sacarla directamente del historial de commits público, la actividad del perfil, archivos exportados y repos copiados. Tu correo puede acabar en sitios de búsqueda de personas o listas de marketing sin que recibas ningún aviso en tu bandeja.

Por eso la gente intenta limpiar los correos antiguos de los commits después. El problema real no es un commit malo; es que el historial público de código es fácil de copiar, fácil de indexar y difícil de retirar por completo una vez que ha estado expuesto.

Dónde puede seguir apareciendo tu dato de contacto

Si quieres limpiar esto, no mires solo la página principal del repositorio. Tu dirección puede aparecer en varias capas del mismo proyecto, y algunas son fáciles de pasar por alto.

El primer lugar es el propio dato del commit. Cada commit puede almacenar identidad de author y de committer, y cada una puede incluir nombre y correo. Si usaste una dirección personal en un portátil antiguo y luego cambiaste a una dirección noreply, los commits anteriores pueden seguir manteniendo la original.

En los sitios de hosting de código, esa información suele ser fácil de explorar. Una página de commit puede mostrar el correo directamente o conectarlo a una cuenta, avatar o perfil verificado. En algunos casos, un correo verificado ayuda a vincular la actividad del repositorio con una página de perfil, lo que facilita que los raspadores lo capturen y lo emparejen con otros registros.

El rastro también se extiende más allá del repo principal. Las bifurcaciones pueden conservar los mismos commits antiguos. Los espejos pueden copiar todo el historial a otro host. Quien haya clonado el repo ya tiene una copia local. Los archivos de parches pueden incluir la línea del autor en texto plano, y los archivos exportados o copias de seguridad pueden preservar metadatos antiguos durante años.

Por eso una limpieza puede parecer incompleta incluso después de una reescritura. Puedes arreglar la rama principal, pero un parche antiguo compartido en un informe de errores o un espejo en otro servicio puede seguir exponiendo la misma dirección.

Un ejemplo pequeño es común: subes un proyecto secundario con tu correo personal, haces público el repo y años después páginas de commits antiguas, descargas de parches y señales de perfil siguen apuntando al mismo buzón. Eso da a los raspadores un lugar más donde recogerlo.

Revisa cada sitio donde se muestre, copie o exporte metadatos de commits. La página del repositorio es solo la parte obvia.

Cómo ver qué está expuesto

Antes de empezar a reescribir el historial, localiza cada lugar público donde siga apareciendo la dirección antigua. Si te saltas ese paso, puedes limpiar un repo y olvidar tres más.

Comienza con las páginas obvias. Abre commits recientes en la interfaz web de cada repo público y revisa la línea del autor en varios commits de distintas fechas. A veces el perfil parece limpio, pero los commits antiguos aún muestran el correo sin formato cuando abres la página completa del commit o la vista de parche.

Una búsqueda directa también ayuda. Busca en el historial del repo la cadena exacta del correo, incluyendo direcciones antiguas de trabajo, escuela o dominios personalizados que ya no uses. Si cambiaste de correos más de una vez, busca cada versión. Un proyecto secundario olvidado es suficiente para que un raspador lo capture.

Luego amplía la revisión. Examina repos archivados que hayas dejado de mirar, forks bajo tu cuenta y forks que otras personas hayan hecho desde tu repo. Abre tags, páginas de releases, vistas de parches, detalles de commits y cualquier snapshot descargable del código ligado a commits antiguos.

Las bifurcaciones importan más de lo que la gente espera. Si tu correo antiguo sigue en un fork que apunta a tus commits, reescribir solo el repo principal puede no cubrir todo el rastro público. Los repos archivados pueden sentirse escondidos, pero a menudo siguen siendo públicos y buscables.

Mantén una nota sencilla mientras avanzas. Apunta cada nombre de repo, dónde aparece la dirección y si aparece en un commit, tag, release o fork. Es aburrido, pero te ahorra tiempo cuando empieces la limpieza.

Una comprobación simple ayuda: abre el repo desconectado de la cuenta, haz clic en unos commits antiguos y mira qué salta primero. Si puedes ver la dirección en menos de un minuto, un raspador también puede.

Cómo evitar que nuevos commits la filtren

Reescribir commits antiguos ayuda, pero no arregla el siguiente commit que hagas. Si Git aún tiene tu dirección personal antigua en su configuración, la filtración vuelve en cuanto hagas push.

Empieza con el repo que usas ahora. Comprueba qué correo asociará Git a un commit nuevo. Si es incorrecto, cámbialo a nivel de repo primero.

git config user.email "[email protected]"
git config user.name "Your Name"

Eso cubre un proyecto. Ahora revisa tu configuración global de Git también. Las configuraciones globales antiguas son una razón común por la que la gente piensa que arregló el problema cuando no fue así. Esto importa aún más en máquinas compartidas, portátiles viejos y equipos de trabajo que hayas usado durante años.

git config --global user.email
git config --global user.name

Si esos valores aún apuntan a un buzón personal, actualízalos. Si usas una máquina tanto para trabajo como para código personal, las configuraciones a nivel de repo suelen ser más seguras que un valor global único.

Una dirección noreply de tu host de código suele ser la opción más limpia. Mantiene tu buzón real fuera de los metadatos del commit y aun así permite que el host conecte los commits con tu cuenta. Para la privacidad del correo de commits en GitHub, esta es una de las soluciones más sencillas.

También ayuda separar las identidades a propósito. Usa un correo para repos de trabajo y otro para proyectos personales, o mantén el trabajo personal en una cuenta separada. Mezclar todo bajo una misma dirección es cómodo por una semana y molesto por años.

Antes de hacer push de trabajo real, haz un commit de prueba pequeño. Cambia una línea en un archivo descartable, haz commit e inspecciona el correo del autor localmente:

git log -1 --format='%an \\u003c%ae\\u003e'

Si la dirección se ve bien, estás listo. Si no, arréglalo antes de subir nada público. Esa comprobación rápida tarda menos de un minuto y es mucho más fácil que limpiar correos antiguos de commits después.

Cómo reescribir commits antiguos paso a paso

Si necesitas eliminar un correo antiguo del historial de Git, hazlo en una copia del repo primero, no en tu única carpeta de trabajo. Haz una copia de seguridad completa antes de tocar nada. Un clone mirror es la opción más segura, y una segunda copia local es mejor que nada. Pausa los pushes del equipo un rato también, porque reescribir el historial cambia los IDs de commit.

Después, elige el correo que quieres conservar en todas partes. Usa la misma dirección de reemplazo tanto para author como para committer, o la limpieza puede quedar a medias.

Una forma sencilla de reescribir commits antiguos es usar git filter-repo con un archivo mailmap:

echo "Your Name \[email protected]\u003e \[email protected]\u003e" > mailmap.txt
git filter-repo --mailmap mailmap.txt

Si tenías más de una dirección antigua, añade una línea por cada una. Luego sigue el proceso en este orden:

1. Ejecuta la reescritura en tu copia de respaldo, no en el repo que usas a diario.
2. Sustituye todas las direcciones antiguas que quieras eliminar, no solo la primera que recuerdes.
3. Revisa el resultado localmente antes de hacer push.

git log --all --format='%an \\u003c%ae\\u003e | %cn \\u003c%ce\\u003e' | sort -u

4. Si el correo antiguo desapareció, haz push forzado con cuidado usando lease protection.

git push --force-with-lease --all
git push --force-with-lease --tags

5. Abre de nuevo el repositorio público tras el push y confirma que la dirección antigua ya no aparece en el historial visible.

Esto suele causar confusión: tus compañeros aún tienen el historial antiguo en sus máquinas. Diles que no mezclen ramas antiguas en el repo reescrito. La solución limpia es volver a clonar, o resetear la copia local al nuevo historial remoto si saben exactamente lo que hacen.

Una reescritura cuidadosa lleva algo de tiempo, pero es mucho mejor que dejar un correo personal en commits públicos para que los raspadores lo recojan.

Qué puede quedar después de la reescritura

Incluso tras limpiar el historial que controlas, pueden permanecer copias antiguas. Un repo reescrito cambia el rastro público de tu lado, pero no borra cada copia hecha antes de la corrección.

El problema más común son los forks. Si alguien bifurcó tu repo antes de que cambiases el autor, ese fork puede seguir conteniendo los commits y la dirección antigua. Lo mismo ocurre con espejos en otros hosts y copias de seguridad personales que fueron subidas y luego olvidadas.

Copias fuera de tu repo

Los motores de búsqueda pueden quedarse atrás. Un resultado en caché o un fragmento antiguo puede seguir mostrando tu correo durante días o semanas, incluso después de que la página del commit haya desaparecido o actualizado. Normalmente eso se desvanece con el tiempo, pero es una brecha real si intentas detener el raspado rápido.

Los archivos descargados tampoco se actualizan solos. Si alguien clonó el repo, bajó un ZIP o exportó datos de commits antes de la reescritura, esa copia permanece como estaba. Conjuntos de datos públicos, índices de código y archivos de investigación pueden conservar metadatos antiguos durante mucho tiempo.

Otro que es fácil de pasar por alto es el repo que olvidaste. Un proyecto secundario, un repo de un antiguo empleador, un repo de estudiante o un duplicado bajo otra cuenta pueden seguir siendo públicos en algún lugar. Limpiar un repo no ayuda mucho si la misma dirección está expuesta en tres repos antiguos.

Y los sitios de brokers son un problema aparte. Si un broker raspó tu correo de los commits antes de la limpieza, reescribir el historial no lo eliminará de esa base de datos. Tendrás que tratar esos listados por separado.

Qué revisar después

Tras la reescritura, haz una pasada rápida:

• Busca forks y espejos que aún contengan los commits antiguos.
• Busca el correo antiguo junto con tu usuario y nombres de repos.
• Revisa repos inactivos o archivados en cada cuenta que hayas usado.
• Comprueba si sitios de búsqueda de personas ya listan esa dirección.

Una limpieza no está realmente hecha cuando el repo principal parece arreglado. Lo está cuando el correo antiguo deja de aparecer en búsquedas públicas.

Errores que dificultan la limpieza

La parte técnica es solo la mitad del trabajo. La limpieza suele fallar por razones simples. La gente arregla el repo principal y luego olvida el repo de pruebas antiguo, un fork o un proyecto secundario que aún muestra la misma dirección.

Eso importa porque a los raspadores no les importa qué repo está activo. Si tu correo antiguo es público en cualquier sitio, aún puede copiarse, emparejarse con tu nombre y difundirse.

Algunos errores se repiten: alguien reescribe un repositorio y olvida proyectos personales antiguos, repos archivados o espejos en otro host. Otra persona limpia las ramas principales pero deja tags intactos, de modo que el correo antiguo sigue en snapshots públicos. Alguien reescribe meses de historial y luego hace un nuevo commit con la misma dirección porque la configuración global de Git aún la tenía.

Los force pushes generan sus propios problemas si los colaboradores no fueron avisados. Un compañero puede después empujar refs obsoletas al remoto y traer de vuelta los commits antiguos. Los hosts también pueden tardar en actualizar páginas de commits en caché, resultados de búsqueda y asociaciones de perfil, así que la primera página que parece limpia no siempre es el fin de la historia.

Los tags son fáciles de pasar por alto. La gente se centra en las ramas porque ahí sucede el trabajo diario, pero los tags suelen marcar releases, y esas releases se copian, descargan e indexan. Un tag olvidado puede deshacer gran parte de una limpieza cuidadosa.

El error de la configuración global es aún más común. Reescribes meses de historial, piensas que terminaste y luego el siguiente commit desde tu nuevo portátil vuelve a usar el correo antiguo. Ese único commit puede reconectar la dirección con tu perfil público.

Haz una segunda pasada después de que todo se asiente. Revisa el repo, tags, vistas de commits y páginas de perfil otra vez. Es un poco tedioso, pero ahorra más tiempo que una pasada apresurada.

Un ejemplo sencillo

Maya usó su correo de la universidad en commits públicos en 2019. En su momento le pareció inofensivo. Subía proyectos de clase, un sitio de portfolio pequeño y algunos repos de práctica. Cada commit llevaba la misma dirección en el campo del autor.

Unos años después, ese repo seguía apareciendo en resultados de búsqueda por su nombre. Los commits eran públicos, el correo seguía allí y la dirección había empezado a aparecer en lugares donde no debería. Un broker podía emparejarlo con un perfil estudiantil antiguo, un currículum publicado en otra parte y un listado en sitios de búsqueda de personas. Un rastro de commits antiguo se convirtió en un enlace de identidad fácil.

Ella arregló el problema en el orden correcto. Primero, cambió el correo usado para todos los commits nuevos para que la filtración dejara de crecer. Luego reescribió el historial antiguo para reemplazar la dirección de la universidad por una más segura, o por una dirección noreply del host de código.

Eso no borró todo rastro de la noche a la mañana. Los resultados de búsqueda y los espejos pueden tardar en actualizar. Pero cortó la fuente pública, que es lo que importa si quieres que menos raspadores lo recopilen.

Tras la reescritura, Maya buscó la dirección antigua directamente. Revisó perfiles en hosts de código, fragmentos en caché y listados de brokers asociados a ese correo. Ese último paso es fácil de saltarse. Si un broker ya copió la dirección, arreglar el repo por sí solo no limpiará el resto.

Lista de verificación práctica para la limpieza

Si lo estás haciendo ahora, mantén el proceso simple.

• Revisa la configuración local de Git y el perfil de tu host de código para que los nuevos commits usen la dirección correcta. Haz un commit de prueba en un repo descartable e inspecciona el correo del autor antes de seguir.
• Revisa todos los repos públicos que controlas, no solo el que usas más. Demos antiguos, repos archivados, forks y repos de organizaciones suelen pasar desapercibidos.
• Mira tags, snapshots de releases, espejos y cualquier cuenta secundaria de hosting. Limpiar la rama principal no arregla un tag antiguo que aún apunta al correo malo.
• Avisa a los colaboradores de que el historial cambió antes de que vuelvan a hacer push. Una persona subiendo una copia antigua puede traer los commits viejos de vuelta.
• Guarda pruebas de la limpieza. Conserva una nota fechada con los repos revisados, los hashes antiguos y nuevos, capturas de pantalla si hace falta y cualquier mensaje de soporte relacionado con la limpieza de cachés o espejos.

Un ejemplo rápido muestra por qué importan las revisiones extras. Imagina que reescribiste un repo en GitHub y tu perfil ahora muestra una dirección noreply. Buen comienzo. Pero si un tag antiguo en un espejo aún expone tu correo personal, un raspador todavía puede captarlo.

Guarda tus notas un tiempo. Si la dirección luego aparece en un broker, tendrás mejor idea de si vino del historial de Git, de otra cuenta pública o de un raspado antiguo.

Qué hacer después

Arreglar la pista de Git es el gran paso, pero no debería ser el último. Una dirección antigua puede seguir apareciendo en perfiles copiados, páginas en caché y listados de brokers mucho después de que limpies el historial del repositorio.

Una rutina de seguimiento simple suele funcionar. Ponte un recordatorio cada pocos meses para revisar repos antiguos, especialmente los que no tocas desde hace años. Busca el correo antiguo en perfiles de hosts de código, registros de paquetes, sitios personales y foros donde puedas haberlo reutilizado. Si aún controlas esas páginas, reemplaza el dato de contacto antiguo allí también. Un detalle reutilizado puede mantener todo el rastro vivo.

Aquí también el lado de los brokers se convierte en una tarea aparte. La limpieza de Git elimina la fuente pública que controlas, pero no saca tu información de las bases de datos de brokers que ya la copiaron. Si eso pasó, Remove.dev gestiona ese paso separado encontrando datos personales en más de 500 brokers, enviando solicitudes de eliminación y monitorizando relistados mientras mantienes la parte de código limpia.

El objetivo no es la perfección en una tarde. Es detener la filtración obvia y luego comprobar con suficiente frecuencia que la dirección antigua siga enterrada. Una revisión de 10 minutos cada pocos meses es mucho más fácil que limpiar años de exposición después.