Git repo con un sacco di immagini di medie dimensioni?

Question

Git repo con un sacco di immagini di medie dimensioni?

#1 da (1 voti)
#2 da (0 voti)
#3 da (-1 voti)

1

Ho appena usato git-tfs per pagare un repository TFS in un repository Git. La directory .git arriva a 2.33GiB, e la ragione principale per questo è un paio di grandi directory che arrivano a circa 650MiB ciascuna. Ogni directory è piena zeppa di (circa 1500) file di immagini JPEG che vanno da 50KiB a 5MiB di dimensioni.

Questo ovviamente rende il repository Git spiacevolmente grande, eppure le immagini si adattano logicamente alla soluzione mentre vengono convertite in immagini più piccole e distribuite al client. Alcuni di loro andrebbero bene, ma il loro numero elevato rende il repository troppo grande. Né Github né Bitbucket ti permetteranno nemmeno di spingere un repository Git più grande di 2 GB (Github non lo dichiara esplicitamente, ma ho provato a spingerlo e non è riuscito). Quale sarebbe il modo migliore per gestirlo? Questa domanda su questo stesso sito ha le risposte migliori che suggeriscono che è fondamentalmente OK controllare le immagini nel controllo del codice sorgente.

git version-control github bitbucket image

posta Jez 03.09.2015 - 11:15

fonte

3 risposte

Leggi altre domande sui tag git version-control github bitbucket image

Quando utilizzare i componenti, gli oggetti, gli oggetti pacchetto in Scala Metriche per quando utilizzare un valore di hash?

score 1 · Answer 1

Se queste immagini non cambieranno spesso, penso che sia possibile archiviarle in un repository di risorse come Nexus. Usandolo hai qualche controllo di versione perché puoi avere versioni diverse dello stesso artefatto, è ben integrato con gli strumenti di costruzione (come Maven) e gestisce i file binari meglio di git. D'altra parte perdi qualcosa come un 'git log' per le tue immagini e una singola relazione diretta (versione) tra il tuo codice sorgente (su Git) e queste immagini (su Nexus).

score 0 · Answer 2

Se sono i dati con cui l'applicazione funziona e non le risorse che l'applicazione deve essere utilizzabile, allora prenderei in considerazione la possibilità di rimuoverle completamente dal repository.

Non sono sicuro di quale sia la tua applicazione, ma considera un lettore musicale. È possibile che le immagini rappresentino vari controlli dell'interfaccia utente: pulsanti, icone, il logo dell'applicazione e così via. Tuttavia, potresti anche visualizzare copertine degli album. Dovresti distribuire pulsanti e icone con la tua applicazione in modo che gli altri sviluppatori li abbiano e siano inclusi quando gli utenti installano l'applicazione, ma non è necessario includere file musicali o copertine degli album nelle tue versioni - i tuoi utenti dovranno fornire questi. Tuttavia, potresti volerne acquisire alcuni come casi di test. Dovresti gestire questi file e controllarli, ma non è necessario che siano nello stesso repository del codice sorgente.

score -1 · Answer 3

Sono sempre stato un grande fan dei campi BLOB. Quindi li memorizzerei in un database. Hai anche il vantaggio di archiviare i metadati delle immagini (se ne hai bisogno) con l'immagine. Ho provato questo approccio con Mssql Server e Oracle ed entrambi sono stati all'altezza del compito. Con mysql non potrei dire.