Eliminación de datos confidenciales de un repositorio

La herramienta git filter-repo y BFG Repo-Cleaner reescriben el historial del repositorio, lo que cambia los SHA para las confirmaciones existentes que se modifican y las confirmaciones dependientes. Los SHA de confirmación modificados pueden afectar a las solicitudes de incorporación de cambios abiertas en el repositorio. Se recomienda combinar o cerrar todas las solicitudes de incorporación de cambios abiertas antes de quitar archivos del repositorio.

Puede quitar el archivo de la confirmación más reciente con git rm. Para información sobre cómo quitar un archivo que se agregó con la confirmación más reciente, consulta "Acerca de los archivos grandes en GitHub".

Advertencia: En este artículo, se indica cómo realizar confirmaciones con datos confidenciales inaccesibles desde cualquier rama o etiqueta del repositorio en tu instancia de GitHub Enterprise Server. Sin embargo, esas confirmaciones pueden seguir siendo accesibles en los clones o bifurcaciones del repositorio, directamente a través de sus hash SHA-1 en vistas almacenadas en caché en las vistas almacenadas en caché en GitHub Enterprise Server, y a través de las solicitudes de incorporación de cambios que hagan referencia a ellas. No puedes eliminar los datos sensibles desde los clones de tu repositorio que tengan otros usuarios, pero puedes eliminar las vistas almacenadas en caché permanentemente, así como las referencias a los datos confidenciales de las solicitudes de cambios en GitHub Enterprise Server poniéndote en contacto con el administrador del sitio.

Una vez que hayas insertado una confirmación en GitHub Enterprise Server, debes considerar cualquier dato confidencial en la confirmación comprometida. Si has confirmado una contraseña, debes cambiarla. Si has confirmado una clave, genera una nueva. El eliminar los datos puestos en riesgo no resuelve su exposición inicial, especialmente en clones o bifurcaciones de tu repositorio existentes.

Si la confirmación que introdujo los datos confidenciales existe en cualquier bifurcación del repositorio, seguirá siendo accesible, a menos que el propietario de la bifurcación también quite los datos confidenciales de su bifurcación o elimine completamente la bifurcación. Deberás coordinarte con los propietarios de cualquier bifurcación del repositorio y pedirles que realicen las acciones adecuadas.

Considera estas limitaciones y dificultades a la hora de tomar la decisión de reescribir el historial de tu repositorio.

Purgar un archivo del historial de tu repositorio

Puede purgar un archivo del historial del repositorio mediante la herramienta git filter-repo o la herramienta de código abierto BFG Repo-Cleaner.

Nota: Si los datos confidenciales se encuentran en un archivo identificado como un archivo binario, deberás quitar el archivo del historial, ya que no puedes modificarlo para quitar o reemplazar los datos.

Usar el BFG

BFG Repo-Cleaner es una herramienta creada y mantenida por la comunidad de código abierto. Proporciona una alternativa más rápida y sencilla a git filter-repo para la eliminación de datos no deseados.

Por ejemplo, para eliminar tu archivo con datos confidenciales y dejar intacta tu última confirmación, ejecuta lo siguiente:

bfg --delete-files YOUR-FILE-WITH-SENSITIVE-DATA

Para reemplazar todo el texto que aparece en passwords.txt dondequiera que se pueda encontrar en el historial del repositorio, ejecute lo siguiente:

bfg --replace-text passwords.txt

Después de que se eliminan los datos sensibles, debes subir forzadamente tus cambios a GitHub Enterprise Server. El forzar las subidas reescribirá el historial de los repositorios, lo cual eliminará los datos sensibles del historial de confirmaciones. Si haces subidas forzadas, esto podría sobreescribir las confirmaciones en las cuales otros hayan basado su trabajo.

git push --force

Vea la documentación de BFG Repo-Cleaner para obtener instrucciones completas de uso y descarga.

Utilizar git filter-repo

Advertencia: Si ejecuta git filter-repo después del guardado provisional de los cambios, no podrá recuperarlos con otros comandos de guardado provisional. Antes de ejecutar git filter-repo, se recomienda no modificar los cambios realizados. Para deshacer el último conjunto de cambios que ha guardado de forma provisional, ejecute git stash show -p | git apply -R. Para más información, vea Herramientas de Git: Almacenamiento provisional y limpieza.

Para ilustrar cómo funciona git filter-repo, le mostraremos cómo quitar el archivo con datos confidenciales del historial del repositorio y cómo agregarlo a .gitignore para asegurarse de que no se vuelva a confirmar accidentalmente.

Instale la versión más reciente de la herramienta git filter-repo. Puede instalar git-filter-repo manualmente o mediante un administrador de paquetes. Por ejemplo, para instalar la herramienta con HomeBrew, use el comando brew install.
```
brew install git-filter-repo
```
Para más información, vea INSTALL.md en el repositorio newren/git-filter-repo.

Si aún no tiene una copia local del repositorio con datos confidenciales en su historial, clone el repositorio en el equipo local.

$ git clone https://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY
> Initialized empty Git repository in /Users/YOUR-FILE-PATH/YOUR-REPOSITORY/.git/
> remote: Counting objects: 1301, done.
> remote: Compressing objects: 100% (769/769), done.
> remote: Total 1301 (delta 724), reused 910 (delta 522)
> Receiving objects: 100% (1301/1301), 164.39 KiB, done.
> Resolving deltas: 100% (724/724), done.

Vaya al directorio de trabajo del repositorio.
```
cd YOUR-REPOSITORY
```
Ejecute el comando siguiente y reemplace PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA por la ruta al archivo que quiere quitar, no solo su nombre de archivo. Estos argumentos harán lo siguiente:
- Forzar a Git a procesar, sin extraer del repositorio, todo el historial de cada rama y etiqueta.
- Quitar el archivo especificado, así como las confirmaciones vacías generadas como resultado.
- Quite algunas configuraciones, como la dirección URL remota, almacenadas en el archivo .git/config. Es posible que quiera hacer una copia de seguridad de este archivo de antemano para una posterior restauración.
- Sobrescribir las etiquetas existentes.
```
  $ git filter-repo --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA
  Parsed 197 commits
  New history written in 0.11 seconds; now repacking/cleaning...
  Repacking your repo and cleaning out old unneeded objects
  Enumerating objects: 210, done.
  Counting objects: 100% (210/210), done.
  Delta compression using up to 12 threads
  Compressing objects: 100% (127/127), done.
  Writing objects: 100% (210/210), done.
  Building bitmaps: 100% (48/48), done.
  Total 210 (delta 98), reused 144 (delta 75), pack-reused 0
  Completely finished after 0.64 seconds.
```
Nota: Si el archivo con datos confidenciales ha existido en cualquier otra ruta (porque se ha movido o cambiado de nombre), también debe ejecutar este comando en esas rutas.

Agregue el archivo con datos confidenciales a .gitignore para asegurarse de que no vuelva a confirmarlo por accidente.

$ echo "YOUR-FILE-WITH-SENSITIVE-DATA" >> .gitignore
$ git add .gitignore
$ git commit -m "Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore"
> [main 051452f] Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore
>  1 files changed, 1 insertions(+), 0 deletions(-)

Vuelva a comprobar que ha quitado todo lo que quería del historial del repositorio y que todas las ramas están extraídas del repositorio.
La herramienta git filter-repo quitará automáticamente los remotos configurados. Use el comando git remote set-url para restaurar los remotos al remplazar OWNER y REPO por los detalles del repositorio. Para obtener más información, vea «Administrar repositorios remotos».
```
git remote add origin https://github.com/OWNER/REPOSITORY.git
```
Una vez que estés satisfecho con el estado de tu repositorio y hayas configurado la comunicación remota adecuada, haz un envío forzado de los cambios locales para sobrescribir tu repositorio en tu instancia de GitHub Enterprise Server, así como todas las ramas que insertaste. Se requiere una subida forzada para eliminar los datos sensibles de tu historial de confirmaciones.
```
$ git push origin --force --all
> Counting objects: 1074, done.
> Delta compression using 2 threads.
> Compressing objects: 100% (677/677), done.
> Writing objects: 100% (1058/1058), 148.85 KiB, done.
> Total 1058 (delta 590), reused 602 (delta 378)
> To https://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY.git
>  + 48dc599...051452f main -> main (forced update)
```

Para quitar el archivo confidencial de las versiones etiquetadas, también deberá forzar la inserción en las etiquetas de Git:

$ git push origin --force --tags
> Counting objects: 321, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (166/166), done.
> Writing objects: 100% (321/321), 331.74 KiB | 0 bytes/s, done.
> Total 321 (delta 124), reused 269 (delta 108)
> To https://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY.git
>  + 48dc599...051452f main -> main (forced update)

Eliminar los datos de GitHub

por completo

Después de usar la herramienta de BFG o git filter-repo para quitar los datos confidenciales e insertar los cambios en GitHub Enterprise Server, debe realizar algunos pasos adicionales para eliminar totalmente los datos de GitHub Enterprise Server.

Ponte en contacto con el administrador del sitio para solicitar la eliminación de las vistas almacenadas en caché y referencias a los datos confidenciales en las solicitudes de extracción en GitHub Enterprise Server. Proporciona el nombre del repositorio o un vínculo a la confirmación que necesitas quitar. Para más información sobre cómo los administradores del sitio pueden quitar objetos Git inaccesibles, consulta "Utilidades de la ea de comandos".
Indique a los colaboradores que fusionen mediante cambio de base, no que combinen, las ramas que hayan creado fuera del historial de repositorios antiguos (contaminado). Una confirmación de fusión podría volver a introducir algo o todo el historial contaminado sobre el que acabas de tomarte el trabajo de purgar.
Después de que haya transcurrido un tiempo y esté seguro de que la herramienta BFG o git filter-repo no han provocado efectos secundarios inesperados, puede forzar la desreferenciación de todos los objetos del repositorio local y recolectar los elementos no utilizados con los siguientes comandos (con Git 1.8.5 o una versión posterior):
```
$ git for-each-ref --format="delete %(refname)" refs/original | git update-ref --stdin
$ git reflog expire --expire=now --all
$ git gc --prune=now
> Counting objects: 2437, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (1378/1378), done.
> Writing objects: 100% (2437/2437), done.
> Total 2437 (delta 1461), reused 1802 (delta 1048)
```
Nota: También puede lograr esto si confirma el historial filtrado en un repositorio nuevo o vacío, y después crea un clon de GitHub Enterprise Server.

Evitar confirmaciones accidentales en el futuro

Impedir que los colaboradores realicen confirmaciones accidentales puede ayudarte a evitar que se exponga información confidencial. Para más información, consulta "Procedimientos recomendados para evitar la pérdida de datos en la organización".

Existen algunos trucos sencillos para evitar confirmar cosas que no quieres confirmar:

Use un programa visual como GitHub Desktop o gitk para confirmar los cambios. Los programas visuales suelen hacer que sea más sencillo ver exactamente qué archivos se agregarán, eliminarán y modificarán con cada confirmación.
Evite los comandos generales git add . y git commit -a en la línea de comandos; en su lugar use git add filename y git rm filename para agregar al "stage" los archivos de manera individual.
Use git add --interactive para revisar y agregar al "stage" los cambios en cada archivo.
Use git diff --cached a fin de revisar los cambios que ha agregado al "stage" para la confirmación. Esta es la diferencia exacta que producirá git commit siempre que no use la marca -a.