Cómo Deshacer Commits a Archivos Confidenciales de Git

Preparó los archivos, agrego un mensaje de commit, y push. No... ¡Espera! Ese archivo NO. Y ahora tenemos que empezar a buscar en Google.

Todos los desarrolladores han realizado algún commit a archivos confidenciales o sensibles en el pasado. Entonces, ¿cómo arreglamos la situación y nos aseguramos de que no nos vuelva a suceder?

En este artículo, te explicaré qué hacer cuando se realiza un commit accidentalmente a un archivo confidencial e incluyo los comandos de Git necesarios para ajustar el historial.

Control de Daños

Así que accidentalmente realizaste un commit a un archivo confidencial. Vamos a llamarlo .env. Hay dos preguntas importantes que responder:

• ¿Subiste el commit a un repositorio remoto?
• ¿Es público el repositorio remoto?

No ha sido subido

Si aún no se ha subido, la situación no es para nada crítica. Puedes volver a un commit anterior:

git reset HEAD^ --soft

Tus archivos se quedarán en la copia de trabajo para que puedas arreglar el archivo/información confidencial. Si quieres mantener el commit y simplemente eliminar el archivo confidencial, realiza:

git rm .env --cached
git commit --amend

Puedes usar --amend solo en el último commit. Si logras añadir un montón de commits encima de eso, usa:

git rebase -i HEAD~{¿cuántos commits a volver?}

Esto te permitirá arreglar el commit defectuoso y reproducirá todos los commits restantes después de la corrección para que no se pierdan.

Ya se ha subido

Si subiste, hay una importante diferencia entre los repositorios públicos y privados.

Si tu repositorio es privado y no hay bots o gente en la que no confíes con acceso a él, puedes modificar fácilmente el último commit usando los dos comandos anteriores.

Si subiste un montón de commits encima del problemático, puedes seguir usando filter-branch o el limpiador de repositorios BFG para eliminar el archivo confidencial del historial de git:

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all

Pero ten en cuenta dos aspectos importantes de estos cambios:

• En realidad estás cambiando el historial
  hay otras personas, otras ramas, otros forks, o solicitudes abiertas de pull requests que dependen del estado actual del repositorio, las romperás. En esos casos, trata el repositorio como si fuera pública y evita cambiar el historial.
• Necesitas limpiar el caché
  Siempre tienes que contactar con el apoyo de tu proveedor de almacenamiento de Git y pedirles que limpien el caché de tu repositorio. Aunque hayas arreglado el commit problemático o reescrito el historial, el viejo commit con el archivo confidencial permanece en el caché. Necesitarías saber su ID para acceder a él, pero sigue siendo accesible hasta que limpies el caché.

¿Necesito regenerar las claves si se suben a un repositorio público?

En resumen, sí. Si tu repositorio es público o no piensas que es un lugar seguro por cualquier otro razón, debes considerar que la información confidencial ha sido comprometida.

Incluso si eliminas los datos de tu repositorio, no puedes hacer cualquier cosa sobre los bots y otros forks del repositorio. Entonces, ¿cuáles son los siguientes pasos?

• Desactiva todas las claves y/o contraseñas
  Haz esto como el primer paso. Una vez que desactives las claves, la información confidencial se vuelve inútil.
• Ajusta gitignore
  Agrega todos los archivos confidenciales a .gitignore para asegurarte de que git no los rastreará.
• Elimina el archivo confidencial
• Realiza un commit del arreglo con una explicación significativa
  No trates de ocultar el error. Otros colaboradores y tú en un mes apreciarán la explicación de lo que pasó y lo que este commit arregla.

Mejores prácticas para el almacenamiento de datos confidenciales en Git

Para evitar una situación como está en el futuro, aquí hay algunos consejos sobre el almacenamiento de datos confidenciales:

Mantén los datos confidenciales en un archivo .env (o un archivo similar en otras plataformas)

Mantén las claves del API y otros datos confidenciales en un solo archivo .env. De esa manera, no realizarás un commit accidentalmente con la nueva clave cuando el archivo .env ya está excluido de git.

Otro gran beneficio es que tienes acceso a todas las claves usando una variable de proceso global.

Usa claves API si es posible

Las claves API son fáciles de generar y desactivar si se ven comprometidas. Si es posible, úsalas y evita el uso de credenciales/contraseñas.

Agrega las claves API a tu herramienta de construcción

Las claves API suelen ser necesarias durante la construcción de aplicaciones. Las herramientas de construcción como Netlify permiten agregar estas claves en las áreas seguras de su administración. Estas claves se inyectan automáticamente en tu aplicación a través de la variable de proceso global.

Agrega el archivo .env a gitignore

Asegúrate de que Git no rastree los archivos que contengan información confidencial.

Proporciona un archivo .env.template

El archivo de plantilla (template) instruye a otros colaboradores para que añadan las claves API necesarias sin necesidad de leer largos documentos.

No cambies el historial en remoto

Usa esto como una regla general. Si has seguido las reglas anteriores, no necesitarás cambiar el historial.

Espero que esta información te haya ayudado a mantenerte en el lado seguro. ¿Tienes una experiencia personal al deshacer commits o quizás una buena lección aprendida? Háblame en Twitter :-)

Traducido del artículo de Ondrej Polesny - How to Uncommit Sensitive Files from Git