2012-06-15 10 views
43

Ho controllato un carico di file in un ramo e unito e quindi ho dovuto rimuoverli e ora mi rimane un grande file .pack che non so come ottenere liberarsi di.Rimuovere il grande file .pack creato da git

Ho eliminato tutti i file utilizzando git rm -rf xxxxxx e ho anche eseguito l'opzione --cached.

Qualcuno può dirmi come posso rimuovere un file di grandi dimensioni .Pack che è attualmente nella seguente directory:

.git/objects/pack/pack-xxxxxxxxxxxxxxxxx.pack

faccio solo bisogno di rimuovere il ramo che ho ancora, ma non sono più usando? O c'è qualcos'altro che devo correre?

Non sono sicuro di quanta differenza faccia, ma mostra un lucchetto contro il file.

Grazie


EDIT

Ecco alcuni brani del mio Bash_history che dovrebbe dare un'idea di come sono riuscito a entrare in questo stato (assumono a questo punto sto lavorando su un ramo git chiamato 'il mio ramo' e ho una cartella contenente più cartelle/file):

git add . 
git commit -m "Adding my branch changes to master" 
git checkout master 
git merge my-branch 
git rm -rf unwanted_folder/ 
rm -rf unwanted_folder/  (not sure why I ran this as well but I did) 

ho pensato che anche eseguito il seguente, ma non risulta nel Bash_history con t lui gli altri:

git rm -rf --cached unwanted_folder/ 

ho anche pensato Ho eseguito alcuni comandi Git (come git gc) per cercare di riordinare il file pacchetto, ma non compaiono nel file .bash_history sia.

+0

Puoi chiarire come li hai rimossi? Se sono ancora nella cronologia dei commit, sono ancora nei file del pacchetto. – loganfsmyth

+0

Salve @loganfsmyth, ho aggiunto gli script di cronologia di bash che si spera possano essere d'aiuto. – user1116573

risposta

114

Il problema è che, anche se sono stati rimossi i file, sono ancora presenti nelle revisioni precedenti. Questo è il punto chiave di git, è che anche se elimini qualcosa, puoi ancora recuperarlo accedendo alla cronologia.

Quello che si sta cercando di fare è chiamato cronologia riscrittura, e ha coinvolto il comando git filter-branch.

GitHub ha una buona spiegazione del problema sul loro sito. https://help.github.com/articles/remove-sensitive-data

Per rispondere alla tua domanda in modo più diretto, quello che è fondamentalmente necessario eseguire è questo:

git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch unwanted_folder' --prune-empty 

Questo eliminerà tutti i riferimenti ai file dalla storia del pronti contro termine.

Successivamente, si vorrà eseguire questo, per rimuovere effettivamente i file dal file pack.

git gc --aggressive --prune 
+3

Come non è questa la risposta giusta? – Dvir669

+1

Sì, questa dovrebbe essere la risposta accettata. – JaKXz

+0

L'ho contrassegnato come accettato se questo rende più facile per chiunque venga a questa domanda in futuro, anche se in realtà ho risolto il mio problema in quel momento creando un nuovo repository git – user1116573

3

Una possibilità:

corsa git gc manualmente per condensare una serie di file del pacchetto in uno o alcuni file del pacchetto. Questa operazione è persistente (cioè il file pacchetto di grandi dimensioni sarà mantenere il suo comportamento di compressione) in modo che può essere utile per comprimere un repository periodicamente con git gc --aggressive

Un'altra opzione è quella di salvare il codice e .git da qualche parte e quindi eliminare il .git e ricominciare a utilizzare questo codice esistente, creando un nuovo repository git (git init).

+0

Ciao Michael, ho provato a eseguire 'git gc' e ho ottenuto solo un paio di file pack, ma quello grande è ancora uno di questi e vorrei liberarmene così da poter eseguire il backup della cartella esternamente più facilmente (zip prima era 1-2Mb, ora 55Mb). A meno che qualcuno non possa suggerire qualcos'altro, penso che potrei dover creare un nuovo idiota. Presumo questo significa che perderò l'accesso ai rami che attualmente ho ecc ...? – user1116573

+1

Ho rinunciato a provare e ho appena eliminato la cartella .git e ho creato un nuovo repository git come hai detto. Lo considererò una lezione imparata. Grazie Michael. – user1116573

+2

Questo non ha molto senso. Perché non puoi dire a git di consolidare il repository attuale e rimuovere i file del pacchetto nel processo? – jml

4

Scenario A: Se i file di grandi dimensioni sono stati aggiunti solo ad un ramo, non è necessario per l'esecuzione git filter-branch. Hai solo bisogno di eliminare il ramo ed eseguire la raccolta dei rifiuti:

git branch -D mybranch 
git reflog expire --expire-unreachable=all --all 
git gc --prune=all 

Scenario B: Tuttavia, sembra che in base alla cronologia bash, che avete fatto di unire le modifiche nel master. Se non hai condiviso le modifiche con nessuno (no git push). La cosa più semplice sarebbe ripristinare il master prima dell'unione con il ramo che aveva i file grandi. Questo eliminerà tutti i commit dalla tua filiale e tutti i commit effettuati sul master dopo l'unione. Così si potrebbe perdere le modifiche - in aggiunta ai file di grandi dimensioni - che si possono avere in realtà voluto:

git checkout master 
git log # Find the commit hash just before the merge 
git reset --hard <commit hash> 

Quindi eseguire il passi dal scenario A.

Scenario C: Se non ci fossero altri cambiamenti dal ramo o modifiche sul master dopo l'unione che si desidera conservare, sarebbe meglio per rebase master e includere selettivamente impegna che si desidera:

git checkout master 
git log # Find the commit hash just before the merge 
git rebase -i <commit hash> 

Nel tuo editor, rimuovi le righe che corrispondono ai commit che hanno aggiunto i file di grandi dimensioni, ma lascia tutto il resto così com'è. Salva ed esci. Il tuo ramo principale dovrebbe contenere solo ciò che desideri e nessun file di grandi dimensioni. Notare che git rebase senza -p eliminerà i commit di unione, quindi rimarrà una cronologia lineare per il master dopo <commit hash>. Questo è probabilmente ok per te, ma in caso contrario, si potrebbe provare con -p, ma git help rebase dice combining -p with the -i option explicitly is generally not a good idea unless you know what you are doing.

Poi eseguire i comandi da scenario A.

+0

Esiste una variante dello scenario A [qui] (http: // stackoverflow .com/q/33191910/4400585) con, tuttavia, un problema inaspettato in più. –

0

Sono un po 'in ritardo per lo spettacolo, ma nel caso in cui la risposta di cui sopra non ha risolto la query poi ho trovato un altro modo. Basta rimuovere il file di grandi dimensioni specifico da .pack. Ho avuto questo problema in cui ho archiviato accidentalmente un grande file da 2 GB. Ho seguito i passaggi spiegati in questo collegamento: http://www.ducea.com/2012/02/07/howto-completely-remove-a-file-from-git-history/

Problemi correlati