Todos los desarrolladores han enviado a la vez archivos con información confidencial al repositorio público por error. ¿Cómo lidiar con tal problema? ¿Cómo asegurarse de que nada como esto vuelva a suceder?
En este artículo, le diré qué hacer si un archivo ingresa accidentalmente al repositorio que no tiene absolutamente nada que hacer allí. Aquí proporcionaré comandos de Git que le permitirán corregir el historial y compartir algunas recomendaciones para organizar el trabajo seguro con información confidencial.
Eliminar archivos confidenciales del repositorio de Git ( imagen grande )
Minimizar el daño
Entonces, accidentalmente cometió un archivo con información confidencial. Llamemos a este archivo
.env. Inmediatamente después de que esto sucedió, debe hacerse un par de preguntas:
- ¿Se ha enviado la confirmación al repositorio remoto?
- ¿El repositorio remoto es de acceso público?
▍Commit aún no se ha enviado al repositorio remoto
Si aún no ha enviado una confirmación al repositorio, entonces, en general, la situación que ha surgido no representa ninguna amenaza. Para arreglar todo, solo necesita volver a la confirmación anterior:
git reset HEAD^ --soft
Los archivos permanecerán en la copia de trabajo del repositorio, puede realizar los cambios necesarios en el proyecto.
Si desea mantener la confirmación y solo necesita eliminar ciertos archivos, haga esto:
git rm .env --cached
git commit --amend
Este parámetro
--amendsolo se puede utilizar para trabajar con la confirmación más reciente. Si agregó algunos más después de una confirmación fallida, use este comando:
git rebase -i HEAD~{ ?}
Esto solucionará la confirmación incorrecta y le ayudará a no perder los cambios realizados en el proyecto por otras confirmaciones.
▍Commit se ha enviado al repositorio remoto
Si ya ha enviado una confirmación a un repositorio remoto, entonces, en primer lugar, debe conocer la diferencia entre repositorios públicos y privados.
Si su repositorio es privado y no es accesible para bots o personas en las que no confía, simplemente puede modificar la última confirmación usando un par de los comandos anteriores.
Si ha enviado otras confirmaciones al repositorio después de una confirmación problemática, esto no le impedirá eliminar archivos confidenciales de su historial de Git utilizando el comando git filter-branch o la herramienta BFG Repo-Cleaner .
Aquí tienes un ejemplo de uso
git filter-branch:
git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all
Pero al hacer esto, tenga en cuenta dos aspectos importantes de dichos cambios realizados en el repositorio:
- Git. , - , , PR, . .
- . , , . , , , , . , ID, , .
¿Necesito crear nuevas claves secretas si sus versiones actuales están en el repositorio público?
Si responde brevemente a la pregunta en el título, entonces - es necesario. Si su repositorio está disponible públicamente, o si, por cualquier motivo, cree que no es un lugar para almacenar datos confidenciales, deberá considerar los datos confidenciales que ingresaron en él como comprometidos.
Incluso si eliminó estos datos del repositorio, no puede hacer nada con los bots y las bifurcaciones del repositorio. ¿Cómo proceder?
- Desactive todas las claves o contraseñas. Esto debe hacerse primero. Después de desactivar las claves, la información confidencial que se ha hecho pública se vuelve inútil.
- Personaliza el archivo
.gitignore. Tomar los.gitignoreregistros de archivos con información confidencial para que Git no monitoreara el estado de esos archivos. - Prepare una confirmación que no contenga archivos confidenciales.
- Envíe los cambios al repositorio, proporcione a la confirmación explicaciones sobre la situación. No intente ocultar el error. Todos los programadores que trabajan en el proyecto, incluido usted, apreciarán la presencia en el repositorio de una confirmación con una explicación de la situación y una descripción de lo que se solucionó exactamente con esta confirmación.
Mejores prácticas para mantener archivos confidenciales en proyectos que usan Git para el control de versiones
Para evitar fugas de información confidencial, debe seguir las siguientes recomendaciones.
▍ Almacene los datos confidenciales en un archivo .env (u otro archivo similar)
Mantenga las claves de API e información similar en un solo archivo
.env. Con este enfoque, si Git no realiza un seguimiento del estado del archivo .env, al agregar una nueva clave a este archivo, no lo enviará accidentalmente al repositorio.
Otra ventaja de este enfoque es que de esta manera tendrá acceso a todas las claves a través de una variable global
process.
▍Utilice claves API si es posible
Las claves de API comprometidas son fáciles de desactivar y volver a crear. Si es posible, utilícelos y no algo como inicios de sesión y contraseñas.
▍Almacena las claves de la API con tu herramienta de compilación
Las claves de API suelen ser necesarias al crear aplicaciones. Las herramientas de compilación como Netlify le permiten mantener las claves en bóvedas seguras. Dichas claves se inyectan automáticamente en la aplicación mediante una variable global
process.
Gestión de variables de entorno
▍Añadir la entrada del archivo .env al archivo .gitignore
Evite que Git rastree archivos confidenciales.
▍Prepare un archivo .env.template de plantilla
Tener un archivo de plantilla de este tipo ayuda a quienes trabajan en el proyecto a agregar claves API al proyecto, eliminando la necesidad de leer la documentación.
▍No cambie el historial de Git en repositorios remotos
Trate de ceñirse estrictamente a esta regla. Si ha seguido las pautas anteriores, no necesitará cambiar su historial de Git.
Salir
Espero que mi material le ayude a trabajar de forma segura con datos confidenciales.
¿Alguna vez ha enviado algo a un repositorio público que no debería ir allí?
