Le immagini devono essere archiviate in un repository git?

Per un team distribuito che utilizza Git e Github come controllo di versione, le immagini devono essere archiviate anche nel repository git?

Per la maggior parte, le immagini non verranno modificate. La cartella che li contiene aumenterà di dimensioni solo con l'aggiunta delle immagini. Una preoccupazione è che la cartella delle immagini può aumentare nel tempo di dimensioni maggiori combinando immagini di grandi dimensioni o solo molte di esse.

Questa è considerata una buona pratica? Quali altre alternative ci sono per condividere i file binari necessari nei progetti a cui un team distribuito può accedere facilmente?

Le tue immagini sono originali o possono essere recuperate (garantite?) Da altrove? Sono necessari per spedire un'unità software costruita dalla fonte? Se sono originali, devono essere sottoposti a backup. Mettili nel tuo controllo di revisione, se non cambiano mai, la penalità di spazio è la stessa di un backup e sono dove ne hai bisogno.

Possono essere modificati per modificare l'aspetto del software, accidentalmente o intenzionalmente? Sì, allora DEVONO essere controllati in qualche modo dalla revisione, perché usare un altro modo quando hai già una soluzione perfetta. Perché introdurre il controllo della versione "copia e rinomina" dai secoli bui?

Ho visto l'opera d'arte di un intero progetto diventare "poof" quando il disco rigido del MacBook del progettista grafico è morto, tutto perché qualcuno, con infinita saggezza, ha deciso che "i binari non appartengono al controllo dei giri", e i grafici (almeno questo ) non tendono ad essere bravi con i backup.

Lo stesso vale per tutti i file binari che soddisfano i criteri di cui sopra.

L'unico motivo per non farlo è lo spazio su disco. Ho paura di $ 100 / terabyte, che la scusa sta indossando un po 'sottile.

Perché diavolo no? :)

La memorizzazione di file binari è considerata una cattiva pratica, sì, ma non mi sono mai preoccupato troppo delle immagini.

Nel peggiore dei casi, se ne hai tonnellate, conservale altrove o usa gli esterni o un'estensione per il supporto binario. E se le immagini non verranno cambiate così spesso, allora dov'è il problema? Non otterrai un grande delta grasso. E se vengono rimossi nel tempo, è solo il tuo server a soffrire un po 'di memorizzazione della cronologia, ma i client non vedranno nulla.

Secondo me, non dovresti preoccupartene - ammesso che non ne memorizzi GB.

Quello che potresti fare, però, è solo memorizzare immagini "sorgente": SVG, macro LaTeX, ecc ... e avere le immagini finali generate dal tuo sistema di compilazione. Probabilmente è ancora meglio, se puoi. Altrimenti, non preoccuparti.

(Detto questo, Git brilla per i file di testo, ma non è il miglior VCS per le immagini. Se possibile, dacci più contesto e metriche)

Per ulteriori informazioni, ti consigliamo di dare un'occhiata a queste domande e risposte:

• Memorizzazione dei file di immagine in SubVersion / Git
• Git vs SVN con file non di testo
• Gestire file binari di grandi dimensioni con Git e Git-submodule

Questa domanda è piuttosto vecchia ma questa è una domanda comune che emerge quando si ha a che fare con Git e ci sono alcuni progressi sulle soluzioni moderne per l'archiviazione di file di grandi dimensioni in un repository Git dall'ultima risposta.

Per archiviare file di grandi dimensioni in Git ci sono i seguenti progetti:

• git-annex - È in circolazione da un po ', ma francamente la sua complessità si frappone.
• git-media - Nessuna esperienza personale con questo. Sembra anche abbastanza complesso.
• git-fit - Un tentativo di creare un plugin più semplice. Richiede memoria S3. Anche se apprezzo la semplicità, la mia principale preoccupazione con il plugin è che è abbastanza sconosciuto e gestito da 1 individuo (divulgazione completa, sono l'unico altro committer in questo momento ed è stato per un problema banale).
• git-lfs - Anche se non l'ho usato ampiamente, sembra essere il Santo Graal. È supportato da Github ed è disponibile su tutti i loro repository a partire da ottobre 2015 e mette la complessità della gestione dei file sul sito di archiviazione dei repository. L'unico aspetto negativo è che questo è abbastanza nuovo, quindi oltre a Github non c'è molto supporto, anche se Gitlab ha anche il supporto , così come Gitea , e Bitbucket ha accennato al supporto in futuro .

TLDR: se puoi, usa git-lfs per archiviare immagini o altri file binari in git.

L'intero "non archiviare i binari nel controllo del codice sorgente" è indicato per un motivo specifico: se si dispone di codice sorgente che viene compilato, non archiviare la compilazione effettiva, ma solo il codice sorgente. Le immagini e le risorse visive non hanno una "fonte", quindi devono essere monitorate nel controllo versione.

Credo che il modo raccomandato con Git sia usare un sottomodulo (introdotto in Git 1.5.3) che è sostanzialmente un repository separato associato a quello principale. Memorizzi le tue immagini (e altre risorse binarie) nel sottomodulo. Questo può quindi essere verificato con il repository principale o lasciato, a seconda di ciò che è richiesto.

Da http://book.git-scm.com/5_submodules.html

"Il supporto del sottomodulo di Git consente a un repository di contenere, come sottodirectory, un checkout di un progetto esterno. I sottomoduli mantengono la propria identità; il supporto del sottomodulo memorizza semplicemente la posizione del repository del sottomodulo e l'ID del commit, quindi altri sviluppatori che clonano il progetto contenente (" superproject ") può facilmente clonare tutti i sottomoduli con la stessa revisione. Sono possibili checkout parziali del superprogetto: puoi dire a Git di clonare nessuno, alcuni o tutti i sottomoduli."

Inoltre, le dimensioni non dovrebbero essere un problema significativo se le immagini non cambiano spesso. Puoi anche eseguire comandi per potare / ridurre le dimensioni, ad esempio:

git gc
git gc-aggressive
git prune

Sì .

Diciamo che rilasci la versione 1.0 del software. Per la versione 2.0 decidi di rifare tutte le immagini con le ombre. Quindi fai questo e rilascia la 2.0. Quindi alcuni clienti che utilizzano 1.0 e non possono eseguire l'aggiornamento a 2.0 decidono di volere il programma in un'altra lingua. Ti danno $ 1G per farlo, quindi dici sicuro. Ma in una cultura diversa, alcune delle tue foto non hanno senso, quindi devi cambiarle ...

Se mantieni le tue immagini nel controllo del codice sorgente, questo è facile, in base alla 1.0 apporti modifiche alle immagini (tra le altre cose), costruisci, rilascia. Se non li avessi nel controllo del codice sorgente, avresti un tempo molto più difficile, dal momento che dovresti trovare le vecchie immagini, modificarle e quindi costruirle.

Se fa parte del Progetto, deve essere nel VCS . Come ottenere questo risultato può dipendere dal VCS o da come organizzi un progetto. Forse un repository per i progettisti, e solo i risultati nel repository del programmatore, o solo le "fonti di immagini" (una volta avevo un progetto con un solo file .svg e le immagini venivano generate tramite make / inscape cli).

Ma, se un VCS non è in grado di gestirlo o diventa inutilizzabile, direi che non è lo strumento giusto per il tuo lavoro.

Finora, non ho avuto problemi con l'inserimento di "solite" quantità di grafica (modelli, concetti e grafica di pagina) per progetti web in git.

Dovresti archiviare le tue immagini in SCM: sì. Senza dubbio.

Dovresti archiviare le tue immagini in git: questo diventa più complicato.

git è molto buono con i file di testo, ma per sua natura non è troppo caldo con i binari. Avrai problemi con la dimensione dei dati trasferiti quando clonerai o spingerai, le tue directory .git cresceranno e potresti confonderti nel giusto modo (cioè come unire 2 immagini!)

Una risposta è utilizzare i sottomoduli, in quanto ciò significa che il collegamento tra il tuo progetto e le immagini sarà più debole - quindi non dovrai gestire le immagini come se fossero parte della tua fonte, pur mantenendole comunque controllate e senza avere si preoccupa di ramificarli - supponendo che il sottoprogetto sia solo un repository "piatto" di dati che non subisce lo stesso churn durante il normale processo di sviluppo.

L'altra risposta è inserirli in un altro progetto, non dirigerlo mai, e assicurarsi che tutti coloro che si impegnano in quel progetto lo spingano immediatamente a monte - non lasciare mai che 2 persone cambino la stessa versione del file - lo troverai il più difficile aspetto come git non è progettato per un flusso di lavoro non distribuito. Dovrai utilizzare metodi di comunicazione vecchio stile per applicare questa regola.

Una terza risposta è inserirli in un altro SCM completamente più adatto a lavorare con le immagini.

Aggiungendo alla risposta di @ haylem, nota che le dimensioni giocano un ruolo importante in questo. A seconda del VCS, potrebbe non funzionare bene con tonnellate di immagini. Quando i cloni o le grandi spinte iniziano a prendere tutta la notte, è davvero troppo tardi perché tutte le immagini sono già nel tuo repository.

Pianificare immagini di grandi dimensioni e crescita futura. Non vuoi entrare in questo progetto per due anni e avere un "oh merda, forse il repository è un po ' troppo grande".

Sono assolutamente d'accordo sul fatto che è possibile memorizzarli tecnicamente ed economicamente. Domanda: "Queste immagini fanno parte del prodotto di spedizione o del contenuto di un prodotto di spedizione?" Non che non sia possibile archiviare contenuti in GIT (o in qualsiasi altro VCS) ma che si tratti di un problema separato per un VCS separato.