Occasionalmente ho lasciato cadere un DVD-rip in un progetto di un sito Web, poi con noncuranza git commit -a -m ...e, zap, il repository è stato gonfiato da 2,2 concerti. La prossima volta ho apportato alcune modifiche, cancellato il file video e eseguito il commit di tutto, ma il file compresso è ancora presente nel repository, nella cronologia.

So che posso iniziare i rami da quei commit e rifare un ramo su un altro. Ma cosa devo fare per unire i 2 commit in modo che il file di grandi dimensioni non sia stato visualizzato nella cronologia e sia stato pulito nella procedura di garbage collection?

Usa BFG Repo-Cleaner , un'alternativa più semplice e veloce a quella git-filter-branchappositamente progettata per rimuovere file indesiderati dalla cronologia di Git.

Seguire attentamente le istruzioni per l' uso , la parte fondamentale è proprio questa:

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

Qualsiasi file di dimensioni superiori a 100 MB (che non sono nel tuo ultimo commit) verrà rimosso dalla cronologia del tuo repository Git. È quindi possibile utilizzare git gcper pulire i dati morti:

$ git gc --prune=now --aggressive

Il GGG è in genere almeno 10-50 volte più veloce della corsa git-filter-branche generalmente più facile da usare.

Informativa completa: sono l'autore del Repo-Cleaner di BFG.

Quello che vuoi fare è altamente distruttivo se hai pubblicato la cronologia per altri sviluppatori. Consulta la sezione "Ripristino dal rebase upstream" nella git rebasedocumentazione per i passaggi necessari dopo aver riparato la cronologia.

Hai almeno due opzioni: git filter-branche un rebase interattivo, entrambi spiegati di seguito.

utilizzando git filter-branch

Ho avuto un problema simile con ingombranti dati di test binari da un'importazione Subversion e ho scritto sulla rimozione di dati da un repository git .

Dì che la tua cronologia git è:

$ 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

Si noti che git lolaè un alias non standard ma molto utile. Con lo --name-statusswitch, possiamo vedere le modifiche dell'albero associate ad ogni commit.

Nel commit "Careless" (il cui nome dell'oggetto SHA1 è ce36c98) il file oops.isoè il DVD-rip aggiunto per errore e rimosso nel commit successivo, cb14efd. Utilizzando la tecnica descritta nel suddetto post di blog, il comando da eseguire è:

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

Opzioni:

• --prune-emptyrimuove i commit che diventano vuoti ( cioè non cambiano l'albero) come risultato dell'operazione di filtro. Nel caso tipico, questa opzione produce una cronologia più pulita.
• -dnomina una directory temporanea che non esiste ancora da utilizzare per creare la cronologia filtrata. Se si esegue su una moderna distribuzione Linux, la specifica di un albero /dev/shmcomporterà un'esecuzione più rapida .
• --index-filterè l'evento principale e viene eseguito contro l'indice in ogni passaggio della cronologia. Si desidera rimuovere oops.isoovunque si trovi, ma non è presente in tutti i commit. Il comando git rm --cached -f --ignore-unmatch oops.isocancella il DVD-rip quando è presente e non fallisce altrimenti.
• --tag-name-filterdescrive come riscrivere i nomi dei tag. Un filtro di catè l'operazione di identità. Il tuo repository, come nell'esempio sopra, potrebbe non avere alcun tag, ma ho incluso questa opzione per la massima generalità.
• -- specifica la fine delle opzioni a git filter-branch
• --alldi seguito --è una scorciatoia per tutti i riferimenti. Il tuo repository, come l'esempio sopra, può avere solo un ref (master), ma ho incluso questa opzione per la generalità completa.

Dopo un po 'di agitazione, la storia è ora:

$ 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

Si noti che il nuovo commit "Careless" aggiunge solo other.htmle che il commit "Remove DVD-rip" non si trova più nel ramo master. La filiale etichettata refs/original/refs/heads/mastercontiene i tuoi commit originali nel caso in cui tu abbia commesso un errore. Per rimuoverlo, seguire i passaggi in "Elenco di controllo per la riduzione di un repository".

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

Per un'alternativa più semplice, clonare il repository per scartare i bit indesiderati.

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

L'uso di un file:///...URL clone copia gli oggetti anziché solo la creazione di hardlink.

Ora la tua storia è:

$ 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

I nomi degli oggetti SHA1 per i primi due commit ("Indice" e "Pagina di amministrazione") sono rimasti invariati perché l'operazione di filtro non ha modificato tali commit. "Careless" ha perso oops.isoe "Login page" ha ottenuto un nuovo genitore, quindi i suoi SHA1 sono cambiati.

Rebase interattivo

Con una storia di:

$ 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

vuoi rimuovere oops.isoda “Careless” come se non lo avessi mai aggiunto, e quindi “Remove DVD-rip” è inutile per te. Pertanto, il nostro piano per entrare in un rebase interattivo è quello di mantenere la "Pagina di amministrazione", modificare "Careless" e scartare "Rimuovi DVD-rip".

L'esecuzione $ git rebase -i 5af4522avvia un editor con i seguenti contenuti.

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.
#

In esecuzione del nostro piano, lo modifichiamo in

edit ce36c98 Careless
pick f772d66 Login page

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

Cioè, eliminiamo la riga con "Rimuovi DVD-rip" e cambiamo l'operazione su "Careless" per essere editpiuttosto che pick.

Salvare l'uscita dall'editor ci lascia al prompt dei comandi con il seguente messaggio.

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

Come ci dice il messaggio, siamo impegnati nel commit "Careless" che vogliamo modificare, quindi eseguiamo due comandi.

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

Il primo rimuove il file offensivo dall'indice. Il secondo modifica o modifica "Careless" come indice aggiornato e -C HEADindica a git di riutilizzare il vecchio messaggio di commit. Infine, git rebase --continueprocede con il resto dell'operazione rebase.

Questo dà una storia di:

$ 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

che è quello che vuoi

Perché non usare questo comando semplice ma potente?

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

L' --tree-filteropzione esegue il comando specificato dopo ogni checkout del progetto e quindi raccomanda i risultati. In questo caso, rimuovi un file chiamato DVD-rip da ogni istantanea, che esista o meno.

Se sai quale commit ha introdotto l'enorme file (diciamo 35dsa2), puoi sostituire HEAD con 35dsa2..HEAD per evitare di riscrivere troppa cronologia, evitando così commit divergenti se non l'hai ancora fatto. Questo commento per gentile concessione di @ alpha_989 sembra troppo importante per lasciarlo qui.

Vedere questo link .

(La migliore risposta che ho visto a questo problema è: https://stackoverflow.com/a/42544963/714112 , copiata qui poiché questa discussione appare alta nelle classifiche di ricerca di Google ma l'altra no)

🚀 Una fodera incredibilmente veloce conchiglia 🚀

Questo script di shell visualizza tutti gli oggetti BLOB nel repository, ordinati dal più piccolo al più grande.

Per il mio repository di esempio, ha funzionato circa 100 volte più velocemente degli altri trovati qui.
Sul mio fidato sistema Athlon II X4, gestisce il repository del kernel Linux con i suoi 5.622.155 oggetti in poco più di un minuto .

Lo script di 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

Quando esegui il codice sopra, otterrai un output leggibile come questo:

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

🚀 Rimozione rapida dei file 🚀

Supponiamo che tu voglia rimuovere i file ae bda ogni commit raggiungibile da HEAD, puoi usare questo comando:

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

Dopo aver provato praticamente ogni risposta in SO, ho finalmente trovato questo gioiello che ha rimosso e cancellato rapidamente i file di grandi dimensioni nel mio repository e mi ha permesso di sincronizzare di nuovo: http://www.zyxware.com/articles/4027/how-to-delete lime-permanente-da-remote-git-repository-your-local-e

CD nella cartella di lavoro locale ed eseguire il comando seguente:

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

sostituire FOLDERNAME con il file o la cartella che si desidera rimuovere dal repository git specificato.

Al termine, eseguire i seguenti comandi per ripulire il repository locale:

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

Ora invia tutte le modifiche al repository remoto:

git push --all --force

Questo pulirà il repository remoto.

Questi comandi hanno funzionato nel mio caso:

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

È leggermente diverso dalle versioni precedenti.

Per coloro che hanno bisogno di spingerlo su github / bitbucket (l'ho provato solo con 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

Basta notare che questo comando può essere molto distruttivo. Se più persone stanno lavorando al repository, dovranno tirare il nuovo albero. I tre comandi centrali non sono necessari se il tuo obiettivo NON è ridurre le dimensioni. Perché il ramo del filtro crea un backup del file rimosso e può rimanere lì per molto tempo.

$ 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 ha funzionato abbastanza bene per me, anche se ho riscontrato lo stesso problema descritto qui , che ho risolto seguendo questo suggerimento .

Il libro pro-git ha un intero capitolo sulla storia della riscrittura : dai un'occhiata alla sezione filter-branch/ Rimozione di un file da ogni commit .

Se sai che il commit è stato recente invece di passare attraverso l'intero albero, procedi come segue: git filter-branch --tree-filter 'rm LARGE_FILE.zip' HEAD~10..HEAD

Mi sono imbattuto in questo con un account bitbucket, dove avevo accidentalmente archiviato enormi backup * .jpa del mio sito.

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-DIRECTORYcon la cartella in questione per riscrivere completamente la cronologia ( compresi i tag ).

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

Questo lo rimuoverà dalla tua cronologia

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

Fondamentalmente ho fatto quello che era su questa risposta: https://stackoverflow.com/a/11032521/1286423

(per la cronologia, lo copierò e incollerò qui)

$ 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

Non ha funzionato, perché mi piace rinominare e spostare molto le cose. Quindi alcuni file di grandi dimensioni si trovavano in cartelle che sono state rinominate e penso che gc non sia riuscito a eliminare il riferimento a quei file a causa del riferimento negli treeoggetti che puntano a quel file. La mia soluzione definitiva per ucciderlo davvero era:

# 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

Il mio repository (il .git) è cambiato da 32 MB a 388 KB, che nemmeno il ramo filtro poteva pulire.

git filter-branchè un potente comando che puoi usare per eliminare un grosso file dalla cronologia dei commit. Il file rimarrà per un po 'e Git lo rimuoverà nella prossima garbage collection. Di seguito è riportato il processo completo dall'eliminazione dei file dalla cronologia di commit . Per motivi di sicurezza, il processo seguente esegue prima i comandi su un nuovo ramo. Se il risultato è quello che ti serviva, ripristinalo sul ramo che desideri effettivamente modificare.

# 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

Usa Git Extensions , è uno strumento UI. Ha un plugin chiamato "Trova file di grandi dimensioni" che trova i file lage nei repository e consente di rimuoverli in modo permanente.

Non usare 'git filter-branch' prima di usare questo strumento, poiché non sarà in grado di trovare i file rimossi da 'filter-branch' (Anche se 'filter-branch' non rimuove completamente i file dai file del pacchetto repository) .

Puoi farlo usando il branch filtercomando:

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

Ci sono risposte molto buone in questo thread, ma nel frattempo molti di loro sono obsoleti. L'uso git-filter-branchnon è più raccomandato, perché è difficile da usare e terribilmente lento su grandi repository.

git-filter-repo è molto più veloce e più semplice da usare.

git-filter-repoè uno script Python, disponibile su github: https://github.com/newren/git-filter-repo .

È necessario solo un file: lo script Python3 git-filter-repo. Copiarlo in un percorso incluso nella variabile PATH. Su Windows potrebbe essere necessario modificare la prima riga dello script (consultare INSTALL.md). È necessario che Python3 sia installato sul tuo sistema, ma questo non è un grosso problema.

Per prima cosa puoi correre

git filter-repo --analyze

Questo ti aiuta a determinare cosa fare dopo.

Puoi eliminare il tuo file DVD-rip ovunque:

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

Il filtro repository è veramente veloce. Un'attività che ha impiegato circa 9 ore sul mio computer per filtro-ramo, è stata completata in 4 minuti con filtro-repo. Puoi fare molte altre cose carine con filter-repo. Fare riferimento alla documentazione per questo.

Avviso: eseguire questa operazione su una copia del repository. Molte azioni di filtro repository non possono essere annullate. filter-repo cambierà gli hash di commit di tutti i commit modificati (ovviamente) e tutti i loro discendenti fino all'ultimo commit!

Quando si verifica questo problema, git rmnon sarà sufficiente, poiché git ricorda che il file esisteva una volta nella nostra storia e quindi manterrà un riferimento ad esso.

A peggiorare le cose, neanche il rifacimento non è facile, perché qualsiasi riferimento al BLOB impedirà a Git Garbage Collector di ripulire lo spazio. Ciò include riferimenti remoti e riferimenti di reflog.

Ho messo insieme git forget-blobun piccolo script che tenta di rimuovere tutti questi riferimenti e quindi utilizza git filter-branch per riscrivere ogni commit nel ramo.

Una volta che il tuo BLOB è completamente privo di riferimenti, git gcti libererai di esso

L'utilizzo è piuttosto semplice git forget-blob file-to-forget. Puoi ottenere maggiori informazioni qui

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

L'ho messo insieme grazie alle risposte di Stack Overflow e ad alcuni post di blog. Crediti a loro!

Oltre a git filter-branch(soluzione git lenta ma pura) e BFG (più facile e molto performante), c'è anche un altro strumento per filtrare con buone prestazioni:

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

Dalla sua descrizione:

Lo scopo di git-rocket-filter è simile al comando git-filter-branchmentre fornisce le seguenti caratteristiche uniche:

• Riscrittura rapida di commit e alberi (per un ordine da x10 a x100).
• Supporto incorporato sia per la lista bianca con --keep (mantiene file o directory) sia per la lista nera con opzioni --remove.
• Uso di .gitignore come modello per il filtraggio degli alberi
• Scripting C # rapido e semplice sia per il filtro di commit che per il filtro ad albero
• Supporto per gli script nel filtro degli alberi per modello di file / directory
• Elimina automaticamente i commit vuoti / invariati, inclusi i commit di unione