Comment puis-je supprimer un gros fichier de l'historique des commits dans le dépôt Git?

Question

J'ai accidentellement déposé un DVD-rip dans un projet de site web, négligemment git commit -a -m ..., et, zut, le dépôt était gonflé de 2,2 Go. La prochaine fois, j'ai apporté quelques modifications, supprimé le fichier vidéo, et tout commité, mais le fichier compressé était toujours présent dans le dépôt, dans l'historique.

Je sais que je peux démarrer des branches à partir de ces commits et rebaser une branche sur une autre. Mais que dois-je faire pour fusionner les deux commits, afin que le gros fichier ne soit pas visible dans l'historique et soit nettoyé lors de la procédure de collecte des déchets?

Answer 1

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

Suivez attentivement les instructions d'utilisation. La partie essentielle est simplement la suivante:

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

Tous les fichiers de plus de 100 Mo (qui ne sont pas présents dans votre dernier commit) seront supprimés de l'historique de votre dépôt Git. Vous pouvez ensuite utiliser git gc pour nettoyer les données inutilisées:

git reflog expire --expire=now --all && git gc --prune=now --aggressive

Après la taille, nous pouvons pousser de force vers le dépôt distant*

git push --force

Remarque: impossible de forcer le push sur une branche protégée sur GitHub

Le BFG est généralement au moins 10-50 fois plus rapide que d'exécuter git-filter-branch, et généralement plus facile à utiliser.

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

Answer 2

Ce que vous voulez faire est très perturbant si vous avez publié l'historique à d'autres développeurs. Voir "Récupération des rebasements en amont" dans le cadre du git rebase documentation pour les étapes nécessaires après la réparation de votre histoire.

Vous avez au moins deux options : git filter-branch et un rebasement interactif qui sont expliqués ci-dessous.

Utilisation de git filter-branch

J'ai rencontré un problème similaire avec des données de test binaires volumineuses provenant d'une importation Subversion et j'ai écrit sur le sujet suivant suppression des données d'un dépôt git .

Disons que votre histoire 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

Notez que git lola est un alias non standard mais très utile. Avec le --name-status nous pouvons voir les modifications de l'arbre associées à chaque commit.

Dans le commit "Careless" (dont le nom d'objet SHA1 est ce36c98) le fichier oops.iso est le DVD-rip ajouté par accident et supprimé dans le commit suivant, cb14efd. En utilisant la technique décrite dans l'article de blog mentionné ci-dessus, 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 les commits qui deviennent vides ( c'est-à-dire ne modifie pas l'arbre) à la suite de l'opération de filtrage. Dans le cas typique, cette option produit un historique plus propre.
• -d nomme un répertoire temporaire qui n'existe pas encore, à utiliser pour construire l'historique filtré. Si vous travaillez sur une distribution Linux moderne, le fait de spécifier un fichier arbre dans /dev/shm permettra une exécution plus rapide .
• --index-filter est l'événement principal et s'exécute contre l'index à chaque étape de l'historique. Vous voulez supprimer oops.iso partout où il est trouvé, 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 lorsqu'il est présent et n'échoue pas dans le cas contraire.
• --tag-name-filter décrit comment réécrire les noms de balises. Un filtre de cat est 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é totale.
• -- spécifie la fin des options pour git filter-branch
• --all suivant -- est un raccourci pour toutes les références. Votre référentiel, comme l'exemple ci-dessus, peut n'avoir qu'une seule référence (master), mais j'ai inclus cette option pour une généralité complète.

Après un certain remue-ménage, 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.html et que le commit "Remove DVD-rip" n'est plus sur la branche master. La branche nommée refs/original/refs/heads/master contient vos commits originaux au cas où vous auriez fait une erreur. Pour le supprimer, suivez les étapes 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 alternative plus simple, clonez le référentiel pour éliminer les éléments indésirables.

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

Utilisation d'un file:///... clone URL copie les objets plutôt que de créer uniquement des liens en dur.

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'objets SHA1 pour les deux premiers commits ("Index" et "Admin page") sont restés les mêmes car l'opération de filtrage n'a pas modifié ces commits. "Careless" a perdu oops.iso et "Page de connexion" ont un nouveau parent, donc leurs SHA1s a fait changement.

Rebasement 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

que vous voulez supprimer oops.iso de "Careless" comme si vous ne l'aviez jamais ajouté, et ensuite "Remove DVD-rip" est inutile pour vous. Ainsi, notre plan pour une refonte interactive est de garder "Admin page", éditer "Careless", et jeter "Remove DVD-rip".

Running $ git rebase -i 5af4522 lance 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
# ...

C'est-à-dire que nous supprimons la ligne avec "Retirer DVD-rip" et changeons l'opération sur "Careless" pour être edit plutôt que pick .

En quittant l'éditeur, nous nous retrouvons à 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 modifier, donc nous lançons deux commandes.

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

La première supprime le fichier incriminé de l'index. La deuxième modifie ou amende "Careless" pour qu'il devienne l'index mis à jour, et -C HEAD indique à git de réutiliser l'ancien message de livraison. Enfin, git rebase --continue va de l'avant avec le reste de l'opération de rebasement.

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

ce qui est ce que vous voulez.

Answer 3

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 un peu différent des versions précédentes.

Pour ceux qui ont besoin de pousser ceci vers GitHub/Bitbucket (j'ai seulement testé cela avec Bitbucket) :

# ATTENTION!!!
# Cela va réécrire complètement vos références Bitbucket
# va supprimer toutes les branches que vous n'aviez pas en local

git push --all --prune --force

# Une fois que vous avez poussé, tous vos coéquipiers doivent cloner le dépôt à nouveau
# git pull ne fonctionnera pas

Answer 4

Juste notez que ces commandes peuvent être très destructrices. Si plusieurs personnes travaillent sur le référentiel, elles devront toutes tirer le nouvel arbre. Les trois commandes intermédiaires ne sont pas nécessaires si votre objectif est de ne pas réduire la taille. Car la branche de filtrage crée une sauvegarde du fichier supprimé et peut y rester pendant longtemps.

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

Answer 5

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

Le livre pro-git a un chapitre entier sur la réécriture de l'historique - jetez un œil à la section filter-branch/Removing a File from Every Commit.