Le immagini dovrebbero essere archiviate in un repository git?

Le tue immagini sono originali o possono essere recuperate (garantite?) da dove? Sono necessari per spedire un'unità software costruita dalla fonte? Se sono originali, hanno bisogno di backup. Mettili in tuo controllo, se non cambi mai, la penalità dello spazio è la stessa di un backup, e sono dove ti servono.

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

Ho visto un'intera opera d'arte originale come "puff" quando il disco rigido dei macbook dei progettisti grafici è morto, tutto perché qualcuno, con infinita saggezza, ha deciso che "i binari non appartengono al controllo di rotazione" e ai grafici (a almeno questo) non tendono ad essere buoni con i backup.

Lo stesso vale per tutti i file binari che soddisfano i criteri precedenti.

L'unica ragione per cui non è lo spazio su disco, temo a $ 100 / terabyte, quella scusa è un po 'sottile.

Perché diavolo no? :)

L'archiviazione dei binari è considerata una cattiva pratica, sì, ma non mi sono mai preoccupato troppo delle immagini.

Nel peggiore dei casi, se ne hai tonnellate, memorizzale da qualche altra parte o utilizza le estensioni esterne o un'estensione per il supporto binario. E se le immagini non saranno cambiate così spesso, allora dov'è il problema? Non otterrai un grande delta grasso. E se vengono rimossi nel tempo, è solo il tuo server che soffre un po 'della memorizzazione della cronologia, ma i client non vedranno nulla.

A mio parere, non dovresti preoccuparti di questo: ti abbiamo concesso di non archiviare GB di questi.

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

(Tutto ciò che viene detto, Git risplende per i file di testo, ma non è il miglior VCS per le immagini. Forniscici più contesto e metrica se puoi)

Per ulteriori informazioni, ti consigliamo di esaminare questi Q & Come:

• Archiviazione di file di immagine in SubVersion / Git
• Git vs SVN con file non di testo
• Gestione di file binari di grandi dimensioni con Git e Git-submodule

L'intero "non memorizzare i binari nel controllo del codice sorgente" è impostato per un motivo specifico: se il codice sorgente è compilato, non memorizzare la compilazione attuale, ma solo il codice sorgente. Immagini e risorse visive non hanno una "fonte", quindi dovrebbero essere tracciati nel controllo di versione.

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

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

• git-annex - Questo è stato in giro per un po 'ma francamente la complessità si intromette.
• git-media - Nessuna esperienza personale con questo. Sembra abbastanza complesso.
• git-fit - Un tentativo di creare un plugin più semplice. Richiede l'archiviazione S3. Anche se apprezzo la semplicità, la mia preoccupazione principale per i plugin è che è abbastanza sconosciuto e mantenuto da 1 individuo (completa divulgazione, sono l'unico altro committer in questo momento ed è stato per un problema banale).
• git-lfs - Anche se non l'ho usato estensivamente 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 tuoi repository. L'unico svantaggio è che questo è abbastanza nuovo, quindi oltre Github non c'è molto supporto, anche se Gitlab ha anche il supporto , così come Gitea , e Bitbucket ha alluso al supporto in futuro .

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

Credo che il modo consigliato con Git sia quello di utilizzare un sottomodulo (introdotto in Git 1.5.3) che è fondamentalmente un repository separato associato a quello principale. Memorizzate le vostre immagini (e altre risorse binarie) nel sottomodulo. Questo può quindi essere estratto con il repository principale o lasciato a seconda di cosa è richiesto.

Da link

"Git's submodule support allows a repository to contain, as a subdirectory, a checkout of an external project. Submodules maintain their own identity; the submodule support just stores the submodule repository location and commit ID, so other developers who clone the containing project ("superproject") can easily clone all the submodules at the same revision. Partial checkouts of the superproject are possible: you can tell Git to clone none, some or all of the submodules."

Inoltre, le dimensioni non dovrebbero essere un problema significativo se le immagini non cambiano spesso. Puoi anche eseguire i comandi per ridurre / 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 foto con le ombre. Quindi lo fai e rilascia 2.0. Quindi alcuni clienti che utilizzano 1.0 e non possono effettuare l'aggiornamento a 2.0 decidono di volere il programma in un'altra lingua. Ti danno $ 1G per farlo, quindi dici di sicuro. Ma in una cultura diversa, alcune delle tue immagini non hanno senso, quindi devi cambiarle ...

Se manterrai le tue immagini nel controllo del codice sorgente, questo è facile, basato su 1.0 apporti modifiche alle immagini (tra le altre cose), compilazione, rilascio. Se non avessi questi nel controllo del codice sorgente, avresti un tempo molto più difficile, dato che dovresti trovare le vecchie immagini, cambiarle e poi costruirle.

Se fa parte del Progetto, deve essere nel VCS . Come ottenere questo meglio può dipendere dal VCS o da come si organizza un progetto. Forse un repo per i designer, e solo i risultati nel repository del coder, o solo le "fonti di immagini" (una volta avevo un progetto con un solo file .svg e le immagini generate da 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 a inserire "solite" quantità di elementi grafici (prototipi, concetti e grafica di pagina) per i progetti web in git.

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

Dovresti memorizzare 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 durante la clonazione o il push, le tue directory .git aumenteranno e potresti ottenere un bel problema con la fusione (ovvero come unire 2 immagini!)

Una risposta è usare i sottomoduli, poiché 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 continuando a tenerle controllate, e senza preoccuparsi di diramarli, supponendo che il sottoprogetto sia solo un repository "piatto" di dati che non passa attraverso lo stesso churn durante il solito processo di sviluppo.

L'altra risposta è metterli in un progetto diverso, non diramarlo mai e accertarsi che chiunque si impegni su quel progetto lo spinga immediatamente a monte - mai lasciare che 2 persone cambino la stessa versione del file - lo troverai l'aspetto più difficile dato che git non è progettato per un flusso di lavoro così non distribuito. Dovrai utilizzare metodi di comunicazione obsoleti per rispettare questa regola.

Una terza risposta è metterli in un SCM completamente diverso che sia 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 grosse spinte iniziano a scattare tutta la notte, è davvero troppo tardi perché tutte le immagini sono già nel tuo repository.

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

Sono assolutamente d'accordo sul fatto che archiviarli tecnicamente ed economicamente sia fattibile. Domanda Vorrei come è "queste immagini sono parte del prodotto di spedizione o parte del contenuto di un prodotto di spedizione?" Non è possibile archiviare contenuti in GIT (o qualsiasi altro VCS) ma si tratta di un problema separato per un VCS separato.