Borrar un secreto de Git no lo invalida: rota la clave antes de reescribir

Si una contraseña, un token o una clave llegó a un repositorio remoto, revoca la credencial y sustitúyela antes de modificar los commits. Borrar su valor del historial de Git no impide que alguien use una copia obtenida mientras seguía activa. El tutorial de GitLab sobre secretos publicados recomienda revocarlos de inmediato y reemplazarlos incluso cuando parezca que pocas personas tuvieron acceso.

Para retirar el secreto del historial, determina primero dónde quedó expuesto y si la revocación resuelve el riesgo. Si también necesitas purgar los commits, trabaja en un clon nuevo, revisa todas las referencias afectadas y coordina la actualización del servidor, los clones y las bifurcaciones. La reescritura cambia la historia compartida, pero no borra por sí sola las copias anteriores.

Revoca la credencial y delimita la exposición

Identifica qué credencial se publicó, quién la administra y a qué servicios permite acceder. Revócala en el proveedor correspondiente, crea una sustituta y actualiza las aplicaciones o procesos que dependían de ella. Retira el valor antiguo de la versión actual del proyecto y guarda el nuevo fuera del repositorio; sustituirlo por otra clave dentro de un commit repetiría la exposición.

Reconstruye el recorrido del commit: comprueba si quedó solo en una rama local o si alcanzó el remoto, otras ramas, etiquetas, solicitudes de cambio o bifurcaciones. Revisa los registros de uso que ofrezca el proveedor de la credencial para valorar posibles accesos durante el período de exposición. Esa investigación puede continuar mientras preparas la limpieza; la revocación es la medida que corta el uso futuro de la clave comprometida.

Decide si la reescritura compensa sus efectos

Si el secreto era únicamente una credencial ya invalidada, evalúa si conservar sus antiguos caracteres en commits justifica alterar un repositorio compartido. Reescribir cambia los identificadores del commit afectado y de sus descendientes; las automatizaciones que dependen de esos identificadores pueden necesitar ajustes. Las firmas de commits y etiquetas pueden perderse, y las diferencias de solicitudes de cambio abiertas pueden cambiar o dejar de estar disponibles.

La decisión cambia cuando el contenido debe retirarse aunque la credencial ya no funcione, por ejemplo, porque el mismo archivo contiene otros datos confidenciales. En ese caso, incluye en el plan las copias que controla el equipo y las que mantienen terceros. Si el commit todavía no se ha enviado ni compartido por otra vía, corregir la historia local antes del primer envío evita la coordinación de una purga remota; verifica ese alcance antes de actuar.

Prepara una copia nueva sin perder trabajo pendiente

Acuerda una pausa de envíos al remoto y avisa a quienes mantienen ramas o bifurcaciones. Registra las referencias que contienen el dato y localiza cambios aún no publicados para trasladarlos después a la historia limpia. Si el archivo cambió de nombre o ubicación, anota cada ruta histórica: un filtro aplicado solo a la ruta actual dejaría intactas las versiones anteriores.

Obtén un clon nuevo del remoto para la operación y conserva aparte el trabajo que exista en directorios locales. No uses como punto de partida una copia de trabajo con cambios sin enviar: la reescritura es destructiva y el clon nuevo permite desechar un resultado incorrecto antes de publicarlo. Revisa también qué solicitudes de cambio y procesos automáticos dependen de los commits que recibirán identificadores distintos.

Filtra el historial y verifica el resultado

El manual de git-filter-repo describe la reescritura como destructiva, documenta la comprobación de clon reciente y recomienda --sensitive-data-removal para obtener información útil durante la limpieza de otras copias. Si esa comprobación falla, averigua la causa antes de forzar la ejecución: puede indicar que el directorio contiene trabajo que no está respaldado.

El tipo de dato determina el filtro. Si debe desaparecer un archivo completo de todas sus versiones, ejecuta git-filter-repo con --sensitive-data-removal, --invert-paths y un argumento --path por cada ruta histórica. Si necesitas conservar el archivo y quitar una cadena de los archivos no binarios, usa --replace-text con los patrones guardados fuera del repositorio. Comprueba aparte los mensajes de commits y etiquetas: --replace-text actúa sobre el contenido de los archivos, mientras que --replace-message sirve para sustituir texto en esos mensajes.

Antes de enviar la historia nueva, inspecciona las rutas afectadas y busca el valor revocado en todas las referencias incluidas. El historial de cambios y el archivo .git/filter-repo/changed-refs ayudan a detectar referencias modificadas y solicitudes de cambio alcanzadas por el filtro. Si queda algún rastro o la operación afecta más trabajo del previsto, descarta el clon y repite la limpieza desde una copia nueva; el remoto todavía conserva su estado anterior.

Publica de forma coordinada y limpia las demás copias

Publica la historia reescrita solo después de acordar qué ramas y etiquetas se sustituirán. Un envío forzado de todas las referencias puede sobrescribir aportaciones hechas durante la limpieza; comprueba que la pausa de envíos sigue vigente y verifica el destino, porque git-filter-repo puede retirar la configuración del remoto. Si el alojamiento rechaza referencias internas de solicitudes de cambio, no interpretes ese fallo como una limpieza completa.

Si el repositorio está en GitHub, la guía de eliminación de datos confidenciales advierte que el secreto puede permanecer en clones, bifurcaciones, vistas almacenadas en caché y solicitudes de cambio tras el envío forzado. Las referencias internas de las solicitudes de cambio son de solo lectura y pueden requerir asistencia del alojamiento. Esa asistencia se limita a casos en los que el riesgo de los datos confidenciales no pueda mitigarse mediante la rotación; si hubo objetos de Git LFS afectados, también hay que revisar su eliminación en el servidor.

Pide a los colaboradores que descarten los clones anteriores y obtengan copias nuevas. Quien necesite conservar trabajo local debe trasladarlo sobre la historia limpia sin fusionar una rama que arrastre los commits antiguos; los responsables de bifurcaciones tendrán que limpiar o retirar sus propias copias. Antes de reanudar los envíos, confirma que ramas y etiquetas parten de la historia reescrita: actualizar un clon antiguo y volver a publicarlo puede introducir otra vez el secreto.

Lee también:

• Una sola clave abrió todas las bases de datos de un servicio cloud
• Borrar el historial de Chrome no elimina Mi Actividad de Google
• Borrar Mi Actividad no limpia el navegador: hacen falta dos pasos