Comment faire pour supprimer/supprimer un fichier volumineux à partir de commettre l'histoire dans le dépôt Git?

Ce que vous voulez faire est très perturbatrice si vous avez publié l'histoire à d'autres développeurs. Voir “La récupération De l'Amont Rebase” dans le git rebase de la documentation pour les mesures nécessaires après la réparation de votre histoire.

Vous avez au moins deux options: git filter-branch et un rebase interactif, à la fois expliqués ci-dessous.

À l'aide de git filter-branch

J'ai eu un problème similaire avec les encombrants binaire des données de test à partir d'un import de Subversion et écrit à propos de suppression des données d'un dépôt git.

Dire que votre historique de git est:

$ 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

Noter que git lola est un non-standard, mais très utile alias. Avec le --name-status interrupteur, on peut voir l'arbre des modifications associées à chaque commit.

Dans le “Négligent” commit (dont SHA1 nom de l'objet est ce36c98) le fichier oops.iso est le DVD-rip ajouté par accident et retiré dans le prochain commit, cb14efd. À l'aide de la technique décrite dans le blog précité, 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-empty supprime s'engage à ce que deviennent vides (c'est à dire, ne modifiez pas l'arbre) comme résultat de l'opération de filtrage. Dans le cas typique, cette option produit un nettoyeur de l'histoire.
• -d noms un répertoire temporaire qui n'existe pas encore à utiliser pour la construction de l'filtré de l'histoire. Si vous êtes en cours d'exécution sur une distribution Linux moderne, la spécification d'un arbre dans /dev/shm sera plus rapide d'exécution.
• --index-filter est le principal événement et va à l'encontre de l'index à chaque étape de l'histoire. Vous souhaitez supprimer oops.iso partout où il se trouve, mais il n'est pas présent dans tous les commits. La commande git rm --cached -f --ignore-unmatch oops.iso supprime le DVD-rip quand il est présent et ne manque pas autrement.
• --tag-name-filter décrit comment réécrire les noms de balise. Un filtre de cat est l'identité de l'opération. Votre référentiel, comme l'exemple ci-dessus, peuvent ne pas avoir toutes les étiquettes, mais j'ai inclus cette option pour tous les cas.
• -- spécifie la fin des options de git filter-branch
• --all suivantes -- est un raccourci pour toutes les refs. Votre référentiel, comme l'exemple ci-dessus, ne peut avoir qu'un ref (master), mais j'ai inclus cette option pour tous les cas.

Après quelques barattage, 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

Avis que la nouvelle “Négligent” commettre ajoute seulement other.html et que le “Supprimer DVD-rip” commit n'est plus sur la branche master. La direction de la étiquetés refs/original/refs/heads/master contient votre original s'engage, dans le cas où vous faites une erreur. Pour l'enlever, suivez les étapes décrites dans “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 solution plus simple, cloner le dépôt débarrasser de l'indésirable bits.

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

À l'aide d'un file:///... clone URL copies des objets plutôt que de créer des liens physiques uniquement.

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

Le SHA1 les noms d'objet pour les deux premiers commits (“Index” et “page d'administration”) est resté le même, parce que l'opération de filtrage ne modifiez pas ces validations. “Négligent” perdu oops.iso et “page de Connexion” vous avez un nouveau parent, de sorte que leur SHA1s ne changement.

Rebase interactif

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 souhaitez supprimer oops.iso de “Négligent” comme si vous n'avez jamais ajouté, puis “Supprimer DVD-rip” est inutile pour vous. Ainsi, notre plan est d'entrer dans un rebase interactif est de garder “l'Admin de la page, puis” modifier “Négligents”, et jeter “Supprimer DVD-rip.”

De course $ git rebase -i 5af4522 commence un éditeur de texte 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.
#

L'exécution de notre plan, nous le modifier à

edit ce36c98 Careless
pick f772d66 Login page

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

Qui est, nous supprimer la ligne avec “Supprimer DVD-rip” et de modifier l'opération sur le “Négligent” pour être edit plutôt que pick.

Enregistrez-la fermeture de l'éditeur de nous dépose à une invite de commandes 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

Que le message nous dit, nous sommes sur la “Négligent” engageons nous voulons modifier, afin de nous exécuter deux commandes.

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

La première supprime le fichier avi à partir de l'index. Le second modifie ou modifie “Négligent” à la mise à jour de l'index et -C HEAD indique à git pour réutiliser les vieux message de commit. Enfin, git rebase --continue va de l'avant avec le reste de la rebase opération.

Cela donne une histoire 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

qui est ce que vous voulez.

(La meilleure réponse que j'ai vu à ce problème est: https://stackoverflow.com/a/42544963/714112 , copié ici depuis ce fil semble élevé dans les classements de recherche de Google, mais que d'autres n'en ont pas),

Extrêmement rapides shell one-liner

Ce script shell affiche tous les objets blob dans le référentiel, triées de la plus petite à la plus grande.

Pour mon exemple, repo, il a couru sur 100 fois plus rapide que les autres qui se trouvent ici.

Sur mon fidèle Athlon II X4 système, il gère le Noyau Linux référentiel avec ses 5,622,155 objets dans peu plus d'une minute.

La Base De Script

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 de nice lisible par l'homme de sortie comme ceci:

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

Rapide De Suppression De Fichiers

Supposons que vous souhaitez supprimer les fichiers a et b de chaque livraison accessible à partir de 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 l'affirmative, j'ai enfin trouvé ce petit bijou qui permet d'éliminer rapidement et supprimé les fichiers de grande taille dans mon référentiel et m'a permis de synchroniser à nouveau: http://www.zyxware.com/articles/4027/how-to-delete-files-permanently-from-your-local-and-remote-git-repositories

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

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

remplacer le nom du DOSSIER avec le fichier ou le dossier que vous souhaitez supprimer à partir de la donnée du répertoire git.

Une fois cela fait, lancez les commandes suivantes pour nettoyer le dépôt local:

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

Maintenant pousser toutes les modifications sur le dépôt distant:

git push --all --force

Ce sera de nettoyer le dépôt distant.

git filter-branch --tree-filter 'rm -f path/to/file' HEAD
a fonctionné assez bien pour moi, même si je suis dans la même situation que décrit ici, que j'ai résolu en suivant cette suggestion.

La pro-git livre a un chapitre entier sur les réécriture de l'histoire - avoir un regard sur le filter-branch/la Suppression d'un Fichier à partir de Chaque livraison section.

J'ai couru ce avec un compte bitbucket, où j'avais accidentellement stockées ginormous *.jpa sauvegardes 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

Relpace MY-BIG-DIRECTORY avec le dossier en question de réécrire complètement votre histoire (y compris les balises).

source: http://naleid.com/blog/2012/01/17/finding-and-purging-big-files-from-git-history

En gros, j'ai 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

Il n'a pas de travail, parce que je tiens à renommer et déplacer des choses beaucoup. De sorte que certains gros dossiers dans des dossiers qui ont été renommés, et je pense que le gc ne pouvais pas supprimer la référence à ces fichiers car de référence dans tree objets pointant vers ces fichiers.
Mon ultime solution pour vraiment tuer c'était:

# 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 repo (le .git) a changé de 32 MO à 388KB, que même filter-branch ne pouvais pas la nettoyer.

Quand vous avez ce problème, git rm ne suffira pas, comme git se souvient que le fichier existait autrefois dans notre histoire, et donc de conserver une référence à elle.

Pour aggraver les choses, la relocalisation n'est pas facile, parce que de toute référence à la goutte permettra d'éviter git garbage collector de nettoyage de l'espace. Cela comprend les références à distance et reflog références.

J'ai mis en place git forget-blob, un petit script qui tente de retirer toutes ces références, puis utilise git filter-branch à réécrire chaque commit de la branche.

Une fois votre blob est complètement non référencées, git gc va se débarrasser de cela

L'utilisation est assez simple git forget-blob file-to-forget. Vous pouvez obtenir plus d'info 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 Débordement de Pile et certains entrées de blog. Des crédits afin de!