Aggiornare un team di sviluppo con riscritto la storia repo Git, la rimozione di file di grandi dimensioni

Question

Ho un repository git con alcune molto grandi binari in esso. Non ho più bisogno di loro, e non mi importa di essere in grado di checkout i file dal commit precedenti. Quindi, per ridurre le dimensioni dei pronti contro termine, voglio eliminare i binari della storia del tutto.

Dopo una ricerca sul web, ho concluso che il mio migliore (solo?) Opzione è quella di utilizzare git-filter-branch:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch big_1.zip big_2.zip etc.zip' HEAD

Questo sembra un approccio bene finora?

Supponendo che la risposta è sì, ho un altro problema da affrontare. Il git manuale ha questo avvertimento:

  

ATTENZIONE! La storia riscritta avrà nomi di oggetti diversi per tutti gli oggetti e non convergere con il ramo originale. Non sarà in grado di spingere facilmente e distribuire il ramo riscritto sulla parte superiore del ramo di originale. Si prega di non utilizzare questo comando se non si conoscono tutte le implicazioni, ed evitare di utilizzare in ogni caso, se un semplice singolo commit sarebbe sufficiente a risolvere il problema. (Vedere la sezione "Ripristino da monte REBASE" in git-rebase (1) per ulteriori informazioni su riscrivere la storia pubblicata.)

Abbiamo un repo remoto sul nostro server. Ogni sviluppatore spinge da e tira da esso. Sulla base l'avviso di cui sopra (e la mia comprensione di come funziona git-filter-branch), non credo che sarò in grado di eseguire git-filter-branch sulla mia copia locale e quindi spingere le modifiche.

Quindi, sto provvisoriamente in programma di passare attraverso le seguenti fasi:

1. Dillo a tutti i miei sviluppatori di impegnare, spingere, e smettere di lavorare per un po '.
2. Accedere al server ed eseguire il filtro sul repo centrale.
3. avere tutti a cancellare i suoi vecchi copie e clone di nuovo dal server.

Fa questo suono giusto? E 'questa la soluzione migliore?

Answer 1

Sì, la soluzione funzionerà. Hai anche un'altra opzione: invece di fare questo sul repo centrale, eseguire il filtro sul clone e spingerlo indietro con git push --force --all. Questo costringerà il server per accettare le nuove filiali dal repository. Questo sostituisce passaggio 2 solo; gli altri passi saranno gli stessi.

Se gli sviluppatori sono piuttosto Git-savvy, allora potrebbe non essere necessario eliminare le loro vecchie copie; per esempio, potrebbero andare a prendere i nuovi telecomandi e rebase loro rami argomento a seconda dei casi.

Answer 2

Il vostro piano è buono (anche se sarebbe meglio eseguire il filtraggio su un clone nuda del repository, piuttosto che sul server centrale), ma a preferenza di git-filter-branch si dovrebbe usare la mia BFG Repo-Cleaner , una più veloce, più semplice alternativa al git-filter-branch progettato specificamente per la rimozione di file di grandi dimensioni dal repo Git.

il vaso Java (richiede Java 6 o superiore) ed eseguire questo comando:

$ java -jar bfg.jar  --strip-blobs-bigger-than 1MB  my-repo.git

Qualsiasi blob oltre 1 MB di dimensione (che non è nel tuo ultima commit) sarà totalmente rimosso dalla cronologia del vostro repository. È quindi possibile utilizzare git gc per pulire via i dati di morti:

$ git gc --prune=now --aggressive

Il BFG è tipicamente 10-50x più veloce di esecuzione git-filter-branch e le opzioni sono su misura attorno a questi due casi d'uso comune:

• Rimozione di Crazy Big Files
• La rimozione delle password, le credenziali e altri dati privati ??

Answer 3

Se non si fanno gli sviluppatori ri-clone è probabile che riusciranno a trascinare i file di grandi dimensioni indietro. Ad esempio, se attentamente Unire la nuova storia che si creerà e poi capita di git merge da un locale ramo del progetto che non è stato calcolato su base, i genitori della fusione impegnano comprenderà il ramo del progetto che alla fine i punti in tutta la storia si cancellati con git filter-branch.

Answer 4

La soluzione non è completa. È necessario includere --tag-name-filter cat come argomento al ramo filtro in modo che i tag che contengono i file di grandi dimensioni sono cambiati pure. Si dovrebbe anche modificare tutti arbitri invece di HEAD in quanto il commit potrebbe essere in più rami.

Ecco il codice meglio:

git filter-branch --index-filter 'git rm --cached --ignore-unmatch big_1.zip big_2.zip etc.zip' --tag-name-filter cat -- --all

Github ha una buona guida: https://help.github.com/articles/remove-sensitive-data