Parfois, je laissais tomber un DVD-rip dans un projet de site Web, puis négligemment git commit -a -m ..., et, zap, le dépôt était gonflé de 2,2 concerts. La prochaine fois, j'ai fait quelques modifications, supprimé le fichier vidéo et tout validé, mais le fichier compressé est toujours là dans le référentiel, dans l'historique.

Je sais que je peux démarrer des branches à partir de ces validations et rebaser une branche sur une autre. Mais que dois-je faire pour fusionner les 2 validations afin que le gros fichier ne s'affiche pas dans l'historique et soit nettoyé lors de la procédure de récupération de place?

Utilisez le BFG Repo-Cleaner , une alternative plus simple et plus rapide à git-filter-branchspécifiquement conçue pour supprimer les fichiers indésirables de l'historique Git.

Suivez attentivement les instructions d'utilisation , la partie principale est la suivante:

$ java -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.git

Tous les fichiers de plus de 100 Mo (qui ne figurent pas dans votre dernière validation) seront supprimés de l'historique de votre référentiel Git. Vous pouvez ensuite utiliser git gcpour nettoyer les données mortes:

$ git gc --prune=now --aggressive

Le BFG est généralement au moins 10 à 50 fois plus rapide que son fonctionnement git-filter-branchet généralement plus facile à utiliser.

Divulgation complète: je suis l'auteur du BFG Repo-Cleaner.

Ce que vous voulez faire est très perturbant si vous avez publié l'historique à d'autres développeurs. Voir «Récupération à partir d'une rebase en amont» dans la git rebasedocumentation pour les étapes nécessaires après la réparation de votre historique.

Vous avez au moins deux options: git filter-branchet un rebase interactif, tous deux expliqués ci-dessous.

En utilisant git filter-branch

J'ai eu un problème similaire avec les données de test binaires volumineuses d'une importation Subversion et j'ai écrit sur la suppression des données d'un référentiel git .

Supposons que votre historique Git soit:

$ git lola --name-status
* f772d66 (HEAD, master) Login page
| A     login.html
* cb14efd Remove DVD-rip
| D     oops.iso
* ce36c98 Careless
| A     oops.iso
| A     other.html
* 5af4522 Admin page
| A     admin.html
* e738b63 Index
  A     index.html

Notez qu'il git lolas'agit d'un alias non standard mais très utile. Avec le --name-statuscommutateur, nous pouvons voir les modifications d'arborescence associées à chaque commit.

Dans le commit «Careless» (dont le nom d'objet SHA1 est ce36c98), le fichier oops.isoest le DVD-rip ajouté par accident et supprimé lors du prochain commit, cb14efd. En utilisant la technique décrite dans le billet de blog susmentionné, la commande à exécuter est:

git filter-branch --prune-empty -d /dev/shm/scratch \
  --index-filter "git rm --cached -f --ignore-unmatch oops.iso" \
  --tag-name-filter cat -- --all

Options:

• --prune-emptysupprime les validations qui deviennent vides ( c'est-à - dire , ne modifient pas l'arborescence) à la suite de l'opération de filtrage. Dans le cas typique, cette option produit un historique plus propre.
• -dnomme un répertoire temporaire qui n'existe pas encore à utiliser pour créer l'historique filtré. Si vous utilisez une distribution Linux moderne, la spécification d'une arborescence /dev/shmentraînera une exécution plus rapide .
• --index-filterest l'événement principal et s'exécute par rapport à l'index à chaque étape de l'historique. Vous souhaitez supprimer oops.isooù qu'il se trouve, mais il n'est pas présent dans toutes les validations. La commande git rm --cached -f --ignore-unmatch oops.isosupprime le DVD-rip lorsqu'il est présent et n'échoue pas autrement.
• --tag-name-filterdécrit comment réécrire les noms de balises. Un filtre de catest l'opération d'identité. Votre référentiel, comme l'exemple ci-dessus, peut ne pas avoir de balises, mais j'ai inclus cette option pour une généralité complète.
• -- spécifie la fin des options git filter-branch
• --allce qui suit --est un raccourci pour toutes les références. Votre référentiel, comme l'exemple ci-dessus, ne peut avoir qu'une seule référence (maître), mais j'ai inclus cette option pour une généralité complète.

Après quelques barattages, l'histoire est maintenant:

$ git lola --name-status
* 8e0a11c (HEAD, master) Login page
| A     login.html
* e45ac59 Careless
| A     other.html
|
| * f772d66 (refs/original/refs/heads/master) Login page
| | A   login.html
| * cb14efd Remove DVD-rip
| | D   oops.iso
| * ce36c98 Careless
|/  A   oops.iso
|   A   other.html
|
* 5af4522 Admin page
| A     admin.html
* e738b63 Index
  A     index.html

Notez que le nouveau commit «Careless» ajoute seulement other.htmlet que le commit «Remove DVD-rip» n'est plus sur la branche master. La branche étiquetée refs/original/refs/heads/mastercontient vos commits originaux au cas où vous auriez fait une erreur. Pour le supprimer, suivez les étapes de la «Liste de contrôle pour la réduction d'un référentiel».

$ git update-ref -d refs/original/refs/heads/master
$ git reflog expire --expire=now --all
$ git gc --prune=now

Pour une alternative plus simple, clonez le référentiel pour éliminer les bits indésirables.

$ cd ~/src
$ mv repo repo.old
$ git clone file:///home/user/src/repo.old repo

L'utilisation d'une file:///...URL de clonage copie des objets plutôt que de créer uniquement des liens physiques.

Maintenant, votre histoire est:

$ git lola --name-status
* 8e0a11c (HEAD, master) Login page
| A     login.html
* e45ac59 Careless
| A     other.html
* 5af4522 Admin page
| A     admin.html
* e738b63 Index
  A     index.html

Les noms d'objet SHA1 pour les deux premières validations («Index» et «Page Admin») sont restés les mêmes car l'opération de filtrage n'a pas modifié ces validations. "Careless" a perdu oops.isoet "Login page" a eu un nouveau parent, donc leurs SHA1 ont changé.

Rebase interactive

Avec une histoire de:

$ git lola --name-status
* f772d66 (HEAD, master) Login page
| A     login.html
* cb14efd Remove DVD-rip
| D     oops.iso
* ce36c98 Careless
| A     oops.iso
| A     other.html
* 5af4522 Admin page
| A     admin.html
* e738b63 Index
  A     index.html

vous voulez supprimer oops.isode "Careless" comme si vous ne l'aviez jamais ajouté, puis "Remove DVD-rip" est inutile pour vous. Ainsi, notre plan d'entrer dans un rebase interactif est de conserver la «page Admin», de modifier «Careless» et de supprimer «Remove DVD-rip».

L'exécution $ git rebase -i 5af4522démarre un éditeur avec le contenu suivant.

pick ce36c98 Careless
pick cb14efd Remove DVD-rip
pick f772d66 Login page

# Rebase 5af4522..f772d66 onto 5af4522
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

En exécutant notre plan, nous le modifions pour

edit ce36c98 Careless
pick f772d66 Login page

# Rebase 5af4522..f772d66 onto 5af4522
# ...

Autrement dit, nous supprimons la ligne avec «Supprimer DVD-rip» et modifions l'opération sur «Careless» editplutôt que pick.

Enregistrer-quitter l'éditeur nous dépose à une invite de commande avec le message suivant.

Stopped at ce36c98... Careless
You can amend the commit now, with

        git commit --amend

Once you are satisfied with your changes, run

        git rebase --continue

Comme le message nous l'indique, nous sommes sur le commit «Careless» que nous voulons éditer, nous exécutons donc deux commandes.

$ git rm --cached oops.iso
$ git commit --amend -C HEAD
$ git rebase --continue

Le premier supprime le fichier incriminé de l'index. Le second modifie ou modifie «Careless» pour être l'index mis à jour et -C HEADdemande à git de réutiliser l'ancien message de validation. Enfin, git rebase --continuecontinue avec le reste de l'opération de rebase.

Cela donne un historique de:

$ git lola --name-status
* 93174be (HEAD, master) Login page
| A     login.html
* a570198 Careless
| A     other.html
* 5af4522 Admin page
| A     admin.html
* e738b63 Index
  A     index.html

c'est ce que tu veux.

Pourquoi ne pas utiliser cette commande simple mais puissante?

git filter-branch --tree-filter 'rm -f DVD-rip' HEAD

L' --tree-filteroption exécute la commande spécifiée après chaque extraction du projet, puis valide à nouveau les résultats. Dans ce cas, vous supprimez un fichier appelé DVD-rip de chaque instantané, qu'il existe ou non.

Si vous savez quel commit a introduit l'énorme fichier (disons 35dsa2), vous pouvez remplacer HEAD par 35dsa2..HEAD pour éviter de réécrire trop d'historique, évitant ainsi des validations divergentes si vous n'avez pas encore poussé. Ce commentaire gracieuseté de @ alpha_989 semble trop important pour être omis ici.

Voir ce lien .

(La meilleure réponse que j'ai vue à ce problème est: https://stackoverflow.com/a/42544963/714112 , copiée ici car ce fil apparaît haut dans les classements de recherche Google mais pas l'autre)

🚀 Une doublure de coque incroyablement rapide 🚀

Ce script shell affiche tous les objets blob dans le référentiel, triés du plus petit au plus grand.

Pour mon échantillon repo, il a fonctionné environ 100 fois plus vite que les autres trouvés ici.
Sur mon fidèle système Athlon II X4, il gère le référentiel du noyau Linux avec ses 5 622 155 objets en un peu plus d'une minute .

Le script de base

git rev-list --objects --all \
| git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
| awk '/^blob/ {print substr($0,6)}' \
| sort --numeric-sort --key=2 \
| cut --complement --characters=13-40 \
| numfmt --field=2 --to=iec-i --suffix=B --padding=7 --round=nearest

Lorsque vous exécutez le code ci-dessus, vous obtiendrez une belle sortie lisible par l'homme comme ceci:

...
0d99bb931299  530KiB path/to/some-image.jpg
2ba44098e28f   12MiB path/to/hires-image.png
bd1741ddce0d   63MiB path/to/some-video-1080p.mp4

🚀 Suppression rapide de fichiers 🚀

Supposons que vous souhaitiez ensuite supprimer les fichiers aet à bpartir de chaque commit accessible HEAD, vous pouvez utiliser cette commande:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch a b' HEAD

Après avoir essayé pratiquement toutes les réponses dans SO, j'ai finalement trouvé ce joyau qui a rapidement supprimé et supprimé les gros fichiers de mon référentiel et m'a permis de synchroniser à nouveau: http://www.zyxware.com/articles/4027/how-to-delete -fichiers-permanents-de-vos-dépôts-git locaux et distants

CD dans votre dossier de travail local et exécutez la commande suivante:

git filter-branch -f --index-filter "git rm -rf --cached --ignore-unmatch FOLDERNAME" -- --all

remplacez FOLDERNAME par le fichier ou le dossier que vous souhaitez supprimer du référentiel git donné.

Une fois cela fait, exécutez les commandes suivantes pour nettoyer le référentiel local:

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now

Poussez maintenant toutes les modifications vers le référentiel distant:

git push --all --force

Cela nettoiera le référentiel distant.

Ces commandes ont fonctionné dans mon cas:

git filter-branch --force --index-filter 'git rm --cached -r --ignore-unmatch oops.iso' --prune-empty --tag-name-filter cat -- --all
rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now

C'est peu différent des versions ci-dessus.

Pour ceux qui ont besoin de pousser cela vers github / bitbucket (je n'ai testé cela qu'avec bitbucket):

# WARNING!!!
# this will rewrite completely your bitbucket refs
# will delete all branches that you didn't have in your local

git push --all --prune --force

# Once you pushed, all your teammates need to clone repository again
# git pull will not work

Notez simplement que ces commandes peuvent être très destructrices. Si plus de gens travaillent sur le dépôt, ils devront tous tirer le nouvel arbre. Les trois commandes du milieu ne sont pas nécessaires si votre objectif n'est PAS de réduire la taille. Parce que la branche de filtre crée une sauvegarde du fichier supprimé et peut y rester longtemps.

$ git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch YOURFILENAME" HEAD
$ rm -rf .git/refs/original/ 
$ git reflog expire --all 
$ git gc --aggressive --prune
$ git push origin master --force

git filter-branch --tree-filter 'rm -f path/to/file' HEAD a bien fonctionné pour moi, même si je suis tombé sur le même problème que celui décrit ici , que j'ai résolu en suivant cette suggestion .

Le livre pro-git contient un chapitre entier sur l' historique de réécriture - jetez un œil à la section filter-branch/ Supprimer un fichier de chaque validation .

Si vous savez que votre commit était récent au lieu de parcourir l'arborescence entière, procédez comme suit: git filter-branch --tree-filter 'rm LARGE_FILE.zip' HEAD~10..HEAD

Je suis tombé sur cela avec un compte bitbucket, où j'avais accidentellement stocké des sauvegardes ginormous * .jpa de mon site.

git filter-branch --prune-empty --index-filter 'git rm -rf --cached --ignore-unmatch MY-BIG-DIRECTORY-OR-FILE' --tag-name-filter cat -- --all

Relacez MY-BIG-DIRECTORYavec le dossier en question pour réécrire complètement votre historique ( y compris les balises ).

source: https://web.archive.org/web/20170727144429/http://naleid.com:80/blog/2012/01/17/finding-and-purging-big-files-from-git-history/

Cela le supprimera de votre historique

git filter-branch --force --index-filter 'git rm -r --cached --ignore-unmatch bigfile.txt' --prune-empty --tag-name-filter cat -- --all

J'ai essentiellement fait ce qui était sur cette réponse: https://stackoverflow.com/a/11032521/1286423

(pour l'histoire, je vais le copier-coller ici)

$ git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch YOURFILENAME" HEAD
$ rm -rf .git/refs/original/ 
$ git reflog expire --all 
$ git gc --aggressive --prune
$ git push origin master --force

Cela n'a pas fonctionné, car j'aime beaucoup renommer et déplacer les choses. Donc, certains gros fichiers se trouvaient dans des dossiers qui ont été renommés, et je pense que le GC n'a pas pu supprimer la référence à ces fichiers en raison de la référence dans les treeobjets pointant vers ce fichier. Ma solution ultime pour vraiment le tuer était de:

# First, apply what's in the answer linked in the front
# and before doing the gc --prune --aggressive, do:

# Go back at the origin of the repository
git checkout -b newinit <sha1 of first commit>
# Create a parallel initial commit
git commit --amend
# go back on the master branch that has big file
# still referenced in history, even though 
# we thought we removed them.
git checkout master
# rebase on the newinit created earlier. By reapply patches,
# it will really forget about the references to hidden big files.
git rebase newinit

# Do the previous part (checkout + rebase) for each branch
# still connected to the original initial commit, 
# so we remove all the references.

# Remove the .git/logs folder, also containing references
# to commits that could make git gc not remove them.
rm -rf .git/logs/

# Then you can do a garbage collection,
# and the hidden files really will get gc'ed
git gc --prune --aggressive

Mon dépôt (le .git) est passé de 32 Mo à 388 Ko, que même la branche de filtre ne pouvait pas nettoyer.

git filter-branchest une commande puissante que vous pouvez utiliser pour supprimer un énorme fichier de l'historique des validations. Le fichier restera pendant un certain temps et Git le supprimera dans la prochaine récupération de place. Vous trouverez ci-dessous le processus complet de suppression des fichiers de l'historique des validations . Pour des raisons de sécurité, le processus ci-dessous exécute d'abord les commandes sur une nouvelle branche. Si le résultat correspond à vos besoins, réinitialisez-le sur la branche que vous souhaitez réellement modifier.

# Do it in a new testing branch
$ git checkout -b test

# Remove file-name from every commit on the new branch
# --index-filter, rewrite index without checking out
# --cached, remove it from index but not include working tree
# --ignore-unmatch, ignore if files to be removed are absent in a commit
# HEAD, execute the specified command for each commit reached from HEAD by parent link
$ git filter-branch --index-filter 'git rm --cached --ignore-unmatch file-name' HEAD

# The output is OK, reset it to the prior branch master
$ git checkout master
$ git reset --soft test

# Remove test branch
$ git branch -d test

# Push it with force
$ git push --force origin master

Utilisez Git Extensions , c'est un outil d'interface utilisateur. Il a un plugin nommé "Find large files" qui trouve les fichiers lage dans les référentiels et permet de les supprimer de manière permanente.

N'utilisez pas 'git filter-branch' avant d'utiliser cet outil, car il ne pourra pas trouver les fichiers supprimés par 'filter-branch' (Altough 'filter-branch' ne supprime pas complètement les fichiers des fichiers du pack de référentiel) .

Vous pouvez le faire en utilisant la branch filtercommande:

git filter-branch --tree-filter 'rm -rf path/to/your/file' HEAD

Il y a de très bonnes réponses dans ce fil, mais en attendant, beaucoup d'entre elles sont obsolètes. En utilisantgit-filter-branch n'est plus recommandée, car elle est difficile à utiliser et extrêmement lente sur les grands référentiels.

git-filter-repo est beaucoup plus rapide et simple à utiliser.

git-filter-repoest un script Python, disponible sur github: https://github.com/newren/git-filter-repo .

Vous n'avez besoin que d'un seul fichier: le script Python3 git-filter-repo. Copiez-le dans un chemin d'accès inclus dans la variable PATH. Sous Windows, vous devrez peut-être modifier la première ligne du script (voir INSTALL.md). Vous devez installer Python3 installé sur votre système, mais ce n'est pas un gros problème.

Vous pouvez d'abord courir

git filter-repo --analyze

Cela vous aide à déterminer quoi faire ensuite.

Vous pouvez supprimer votre fichier DVD-rip partout:

 git filter-repo --invert-paths --path-match DVD-rip

Filter-repo est vraiment rapide. Une tâche qui a pris environ 9 heures sur mon ordinateur par filtre-branche, a été réalisée en 4 minutes par filtre-repo. Vous pouvez faire bien plus de choses sympas avec le filtre-repo. Reportez-vous à la documentation pour cela.

Avertissement: faites-le sur une copie de votre référentiel. De nombreuses actions de filtrage-repo ne peuvent pas être annulées. filter-repo changera les hachages de validation de toutes les validations modifiées (bien sûr) et de tous leurs descendants jusqu'aux dernières validations!

Lorsque vous rencontrez ce problème, git rmcela ne suffira pas, car git se souvient que le fichier a existé une fois dans notre historique, et gardera donc une référence à celui-ci.

Pour aggraver les choses, le rebasage n'est pas facile non plus, car toute référence à l'objet blob empêchera git garbage collector de nettoyer l'espace. Cela inclut les références distantes et les références de reflog.

J'ai mis en place git forget-blobun petit script qui essaie de supprimer toutes ces références, puis utilise git filter-branch pour réécrire chaque commit de la branche.

Une fois que votre blob ne sera plus référencé, git gcsupprimez-le

L'utilisation est assez simple git forget-blob file-to-forget . Vous pouvez obtenir plus d'informations ici

https://ownyourbits.com/2017/01/18/completely-remove-a-file-from-a-git-repository-with-git-forget-blob/

J'ai mis cela ensemble grâce aux réponses de Stack Overflow et à certaines entrées de blog. Des crédits pour eux!

Outre git filter-branch(solution git lente mais pure) et BFG (plus facile et très performant), il existe également un autre outil pour filtrer avec de bonnes performances:

https://github.com/xoofx/git-rocket-filter

De sa description:

Le but de git-rocket-filter est similaire à la commande git-filter-branchtout en fournissant les fonctionnalités uniques suivantes:

• Réécriture rapide des commits et des arbres (par ordre de x10 à x100).
• Prise en charge intégrée de la liste blanche avec --keep (conserve les fichiers ou des répertoires) et de la liste noire avec les options --remove.
• Utilisation du modèle de type .gitignore pour le filtrage des arbres
• Script C # rapide et facile pour le filtrage de validation et le filtrage d'arbre
• Prise en charge des scripts dans le filtrage d'arborescence par modèle de fichier / répertoire
• Élaguer automatiquement la validation vide / inchangée, y compris les validations de fusion