La ramification dépend un peu du support VCS pour la fonctionnalité (c'est-à-dire: si le VCS le rend facile ou difficile).
Mais au minimum, vous voulez une branche pour chaque version de votre projet prise en charge de manière indépendante. Autrement dit, si vous avez "Game 2" et "Game 2 + Expansion" qui sont des produits distincts construits à partir de la même base de code, et que vous devez pouvoir corriger et publier des mises à jour, alors vous voulez avoir chacun de ces existent dans leur propre branche hors de la base de code principale, de sorte que les correctifs de la base de code principale peuvent être fusionnés dans chacun de ces produits indépendamment. (En règle générale, ces branches sont créées lorsque chaque produit est publié, ou peut-être quelques jours / semaines avant, si vous avez des personnes travaillant sur des choses dans la base de code que vous ne souhaitez pas sortir avec la version initiale)
Lorsque vous travaillez avec un VCS qui rend l'utilisation des branches délicate ou pénible (SourceSafe, svn, etc.), vous serez probablement plus heureux de maintenir une branche "release" pour chaque produit publié et de faire votre développement principal dans "trunk", fusionner les modifications de "trunk" dans les branches "release" si et quand vous avez besoin de publier des correctifs pour ces versions.
Si, d'autre part, vous travaillez avec l'un des nouveaux systèmes VCS qui sont construits autour de la ramification et de la fusion (git, Bazaar, Mercurial, etc.), alors vous serez probablement le plus heureux de faire votre développement en peu de temps -des branches "fonctionnelles" vivantes. Par exemple, si vous travaillez sur l'IA pathfinding, vous pouvez créer une branche "pathfinding" et y implémenter le code. Lorsque vous avez terminé, vous fusionnez cette branche dans votre tronc de développement principal et supprimez (éventuellement) la branche dans laquelle vous travailliez. L'avantage de cette approche est qu'elle vous permet de travailler sur plusieurs tâches simultanément, au lieu de devoir en terminer une. avant de commencer la suivante.
Dans mon projet actuel (utilisant git), j'ai cinq branches de fonctionnalités différentes actives en ce moment, travaillant sur différentes fonctionnalités. Deux d'entre eux sont des approches alternatives pour faire la même chose (pour le profilage), deux sont des idées expérimentales de mécanique de jeu, et l'un est un grand refactoriseur de mes systèmes d'IA, et est en fait cassé de telle manière que le code ne se compile pas correctement à présent. Mais il est engagé dans sa branche de fonctionnalités pour référence et pour la sauvegarde, et le fait qu'il soit cassé ne m'empêche pas de travailler sur les autres fonctionnalités; Ces autres branches de fonctionnalités (et le tronc de développement principal également) continuent de se compiler et de fonctionner correctement.
D'après mon expérience dans le développement de jeux professionnels en grande équipe, nous sommes toujours principalement coincés avec des systèmes de contrôle de version plus anciens (et pris en charge commercialement). Perforce est probablement le plus utilisé, suivi de Subversion. Partout où j'ai travaillé, nous avons eu une branche «tronc», puis une branche «version» distincte pour chaque livrable (jalon / démo / version / etc). Parfois, quelqu'un crée une branche personnelle pour certains changements énormes qu'il effectue ou teste, mais cela est extrêmement rare et concerne généralement des choses comme "convertir le jeu pour qu'il fonctionne avec cette bibliothèque de physique différente", qui peut ne pas réellement passer par le produit libéré.