Pour beaucoup d'entre nous - en particulier pour les petits jeux - vous devez absolument avoir des actifs dans le même référentiel que votre source .
La suggestion que les actifs appartiennent à un référentiel séparé n'a de sens que pour de très grands ensembles d'actifs, ou pour des ensembles d'actifs assez grands lorsqu'il existe une frontière moteur / données clairement définie. À moins qu'il y ait une raison technique spécifique à cela - c'est un mauvais conseil!
Vous voulez que votre contrôle de version se comporte comme un contrôle de version . Vous voulez être en mesure de rembobiner et d'avancer rapidement, de créer des branches et de fusionner des révisions et de faire fonctionner votre jeu. Et votre code et actifs seront fonction de l'autre.
Par exemple: votre code peut s'attendre à pouvoir définir un paramètre sur un shader, et ce shader peut dépendre de la présence d'une texture. Ou peut-être que le format de données de vos niveaux peut dépendre d'une version particulière de votre code de jeu.
Cela deviendra presque certainement désordonné. Et vous avez mieux à faire que d'essayer de le ranger.
Maintenant, comme l'a commenté Mike Wagner ( sur cette réponse ) - vous ne voulez pas ou n'avez pas besoin de toutes les versions "en cours" de vos actifs sous contrôle de version! Seule la version finale / de travail, telle qu'utilisée par votre code, fera l'affaire - c'est souvent ce que vous exportez à partir de votre outil.
(Bien que si vous voulez contrôler les versions des versions en cours des actifs - c'est très bien. Et bien adapté à un référentiel séparé. Personnellement, je trouve qu'une bonne organisation des dossiers et un système de sauvegarde approprié suffisent.)
Cela étant dit - il est parfois agréable d'avoir la possibilité de simplement coller les actifs "en cours" sous le contrôle de la version. En règle générale, cela implique d'avoir un pipeline de contenu qui peut gérer toutes les étapes «d'exportation» pour vous - par exemple: aplatir une image multicouche en une seule texture.