Penso che questo varia da progetto a progetto. Generalmente il consiglio di
Bart è valido. Se queste risorse sono direttamente collegate al codice sorgente e gestite dallo sviluppatore (il miglior esempio sono le immagini linkate / incorporate staticamente in un modello) è una buona pratica averle all'interno del repository.
Se questo non è il caso, dobbiamo fare qualche altra domanda. Le domande chiave qui sono IMHO:
- Trovi vantaggio da questo asset gestito dal controllo di versione?
- Questi asset sono gestiti da te o da qualcuno o da qualcosa di esterno (uploader interno dell'applicazione)?
- Se le risorse sono gestite all'interno della tua applicazione, questo non ha un qualche tipo di controllo di versione per le risorse da solo?
- Esiste anche la necessità di sincronizzare attivamente le risorse da un ambiente a un altro? Non è più facile separarli in ogni ambiente e rsync da live a staging / local quando veramente necessario? (Dipende da come le risorse sono collegate alla tua applicazione.)
- Ci sono degli svantaggi dall'avere le risorse nel controllo della versione (ad esempio, avere costantemente conflitti nei diversi ambienti locali vs. fase vs live)?
Come si sta affermando una dimensione di 15-20G nella tua domanda, assumerei personalmente che non ha senso mantenere tali asset nel controllo della versione. Mantenerlo all'interno del backup dovrebbe essere sufficiente in quasi tutti i casi che posso immaginare, purché non ci siano requisiti speciali nel tuo progetto di cui non siamo a conoscenza.
Ricorda inoltre che sarai costretto a scaricare l'intera cronologia (leggi: qualsiasi file che sia mai esistito) al checkout iniziale di quel repository. Se assumiamo che in qualche modo riuscirai ad aggiungere il 15-20G a quel repository adesso e avrai un fatturato di 500 MB al mese, il repo sarà 27-32G in due anni, il che sarà un grosso problema per tutti coloro che devono lavorare con e alla fine ti costringerà comunque a sbarazzarti di una parte della storia dei pronti contro termine. ; -)