¿Cómo eliminar archivos que se enumeran en .gitignore pero que aún están en el repositorio?

Tengo algunos archivos en mi repositorio que deben ignorarse, los agregué a .gitignore pero, por supuesto, no se eliminan de mi repositorio.

Así que mi pregunta es, ¿hay algún comando mágico o secuencia de comandos que use una rama de filtro que pueda reescribir mi historial y eliminar todos estos archivos fácilmente? ¿O simplemente un comando que creará una confirmación que los eliminará?

Puede eliminarlos del repositorio manualmente:

git rm --cached file1 file2 dir/file3

O, si tiene muchos archivos:

git rm --cached `git ls-files -i -c --exclude-from=.gitignore`

Pero esto no parece funcionar en Git Bash en Windows. Produce un mensaje de error. Lo siguiente funciona mejor:

git ls-files -i -c --exclude-from=.gitignore | xargs git rm --cached  

En PowerShell en Windows, esto funciona incluso mejor (maneja espacios en la ruta y los nombres de archivo):

git ls-files -i -c --exclude-from=.gitignore | %{git rm --cached $_}

Con respecto a reescribir toda la historia sin estos archivos, dudo mucho que haya una automático manera de hacerlo
Y todos sabemos que reescribir la historia es malo, ¿no? 🙂

Una forma más fácil que funciona independientemente del sistema operativo es hacer

git rm -r --cached .
git add .
git commit -m "Drop files from .gitignore"

Básicamente elimina y vuelve a agregar todos los archivos, pero git add ignorará a los que están en .gitignore.

Utilizando el --cached La opción mantendrá los archivos en su sistema de archivos, por lo que no eliminará archivos de su disco.

Nota: Algunos señalaron en los comentarios que perderá el historial de todos sus archivos. Probé esto con git 2.27.0 en MacOS y es no el caso. Si desea comprobar lo que está sucediendo, compruebe su git diff HEAD~1 antes de empujar su compromiso.

Como los archivos en .gitignore no están siendo rastreados, puede usar el limpiar Comando para eliminar recursivamente archivos que no están bajo control de versiones.

Utilizar git clean -xdn para realizar un ensayo y ver qué se eliminará.
Entonces usa git clean -xdf para ejecutarlo.

Básicamente, git clean -h o man git-clean(en Unix) le dará ayuda.

Tenga en cuenta que este comando también eliminará archivos nuevos que no están en el área de preparación.

Espero eso ayude.

Hice una solución muy sencilla al manipular la salida de la declaración .gitignore con sed:

cat .gitignore | sed '/^#.*/ d' | sed '/^\s*$/ d' | sed 's/^/git rm -r /' | bash

Explicación:

1. imprima el archivo .gitignore
2. eliminar todos los comentarios de la impresión
3. eliminar todas las líneas vacías
4. agregue ‘git rm -r’ al comienzo de la línea
5. ejecutar cada línea.

“git clean“^(hombre) y git ls-files -i^(hombre) tenía confusión sobre trabajar o mostrar rutas ignoradas dentro de un directorio ignorado, que se ha corregido con Git 2.32 (Q2 2021).

Eso significa que la versión 2021 de la respuesta aceptada sería:

git ls-files -i -c --exclude-from=.gitignore | xargs git rm --cached  
                ^^

Ver cometer b548f0f, cometer dd55fc0, cometer aa6e1b2, cometer a97c7a8, cometer 2e4e43a, cometer b338e9f, confirmar 7fe1ffd, cometer 7f9dd87 (12 de mayo de 2021) por Elías Newren (newren).
Ver cometer 4e689d8 (12 de mayo de 2021) por Derrick Stolee (derrickstolee).
^{(Combinado por Junio ​​C Hamano — gitster — en cometer 33be43120 de mayo de 2021)}

ls-files: error en -i a menos que se especifiquen -o o -c

^{Firmado por: Elijah Newren}

ls-files --ignored^(hombre) se puede usar junto con cualquiera --others o --cached.

Después de estar un poco perplejo y profundizar en el código, asumí que ls-files -i simplemente estaba roto y no imprimía nada y tenía un buen parche listo para enviar cuando finalmente me di cuenta de que -i se puede usar con --cached para encontrar ignorados rastreados.

Si bien eso fue un error de mi parte, y una lectura cuidadosa de la documentación podría haber aclarado esto, sospecho que es probable que otros también cometan este error.
De hecho, de dos usos en nuestro conjunto de pruebas, creo que uno de los dos cometió este error.
En t1306.13, NO hay archivos rastreados, y todas las exclusiones creadas y utilizadas en esa prueba y en pruebas anteriores, por lo tanto, tienen que ser sobre archivos sin rastrear.
Sin embargo, dado que estaban buscando un resultado vacío, el error pasó desapercibido ya que su comando erróneo también dio una respuesta vacía.

-i se usará la mayor parte del tiempo con -olo que sugeriría que simplemente podríamos hacer -i implicar -o en ausencia de un -o o -cpero eso sería una ruptura incompatible con versiones anteriores.
En su lugar, marquemos -i sin tampoco un -o o -c como un error, y actualice los dos casos de prueba relevantes para especificar su intención.

Eso significa sin -cobtendría (a partir de Git 2.32, segundo trimestre de 2021):

fatal: ls-files -i must be used with either -o or -c

Nota: esto todavía es un trabajo en progreso, ya que fue revertido en Git 2.32-rc2 pero arreglado con cometer 2c9f1bf, cometer 1df046b (27 de mayo de 2021) por Junio ​​C Hamano (gitster).
Ver cometer 906fc55 (27 de mayo de 2021) por Elías Newren (newren).
Ver cometer eef8148 (27 de mayo de 2021) por Derrick Stolee (derrickstolee).
^{(Combinado por Junio ​​C Hamano — gitster — en cometer 329d63e28 de mayo de 2021)}

dir: presentar readdir_skip_dot_and_dotdot() ayudante

^{Firmado por: Elijah Newren}

Si realmente quiere podar su historial de .gitignored archivos, primero guardar .gitignore fuera del repositorio, por ejemplo, como /tmp/.gitignoreentonces corre

git filter-branch --force --index-filter \
    "git ls-files -i -X /tmp/.gitignore | xargs -r git rm --cached --ignore-unmatch -rf" \
    --prune-empty --tag-name-filter cat -- --all

Notas:

• git filter-branch --index-filter corre en el .git directorio, creo, es decir, si desea usar una ruta relativa, debe anteponer una más ../ primero. Y aparentemente no puedes usar ../.gitignoreel actual .gitignore archivo, que produce un “fatal: no se puede usar ../.gitignore como un archivo de exclusión” por alguna razón (tal vez durante un git filter-branch --index-filter el directorio de trabajo está (considerado) vacío?)
• Esperaba usar algo como git ls-files -iX <(git show $(git hash-object -w .gitignore)) en lugar de evitar copiar .gitignore en otro lugar, pero eso solo ya devuelve una cadena vacía (mientras que cat <(git show $(git hash-object -w .gitignore)) de hecho huellas .gitignoreel contenido de como se esperaba), por lo que no puedo usar <(git show $GITIGNORE_HASH) en git filter-branch…
• Si en realidad solo quieres .gitignore-limpiar una rama específica, reemplazar --all en la última línea con su nombre. los --tag-name-filter cat entonces podría no funcionar correctamente, es decir, probablemente no podrá transferir directamente las etiquetas de una sola sucursal correctamente

En Linux puedes usar este comando:

por ejemplo quiero borrar *.py~ entonces mi comando debería ser ==>

find . -name "*.py~" -exec rm -f {} \;