Розгалуження мало залежить від підтримки VCS для функції (тобто: чи робить це VCS легким чи складним).
Але як мінімум, ви хочете відділення для кожного незалежно підтримуваного випуску вашого проекту. Тобто, якщо у вас є "Гра 2" та "Гра 2 + розширення", які є окремими продуктами, побудованими з тієї ж кодової бази, і які вам потрібно мати можливість виправити і виправити оновлення, то ви хочете мати кожне з цих існують у власному відділенні основної кодової бази, так що виправлення до основної кодової бази можуть бути об'єднані у кожен із цих продуктів незалежно. (Зазвичай ці гілки створюються після випуску кожного продукту або, можливо, за кілька днів / тижнів до цього, якщо в кодовій базі є люди, які працюють над речами, які ви не бажаєте виходити з початкового випуску)
Під час роботи з VCS, який робить гілки складними або болючими (SourceSafe, svn тощо), ви, ймовірно, будете найщасливішим, підтримуючи гілку "випуску" кожного випущеного продукту і роблячи свою основну розробку в "стовбурі", об'єднання змін від "trunk" до гілок "release", якщо і коли потрібно випустити виправлення для цих випусків.
Якщо, з іншого боку, ви працюєте з однією з новіших систем VCS, які побудовані навколо розгалуження та злиття (git, Bazaar, Mercurial тощо), то, ймовірно, ви будете найщасливішими, роблячи свою розробку за короткий час -живі гілки "функції". Наприклад, якщо ви працюєте над AI pathfinding, ви можете зробити гілку "pathfinding" і реалізувати код там. Закінчивши, ви з’єднуєте цю гілку назад у свій основний стовбур розвитку та (необов'язково) видаляєте гілку, в якій працювали. Перевага такого підходу полягає в тому, що він дозволяє одночасно працювати над кількома завданнями, замість того, щоб виконувати одну завдання перед початком наступного.
У моєму поточному домашньому проекті (за допомогою git) у мене зараз є п'ять різних галузей функцій, які працюють над різними різними функціями. Два з них - це альтернативні підходи робити те саме (для профілювання), два - експериментальні ідеї механіки ігор, а один - великий рефактор моїх AI-систем, і насправді розбивається таким чином, що код не складе правильно зараз. Але це зроблено у своїй галузі функцій для довідки та резервного копіювання, і її розбиття не заважає мені працювати над іншими функціями; Ці інші гілки функцій (і головний магістраль розробки) як і раніше збираються та запускаються правильно.
З мого досвіду розробки професійних ігор для великих команд, ми все ще в основному дотримуємося старих (і комерційно підтримуваних) систем управління версіями. Перфорсе, мабуть, найчастіше використовується, за ним слідує Subversion. Скрізь, де я працював, у нас була гілка «магістраль», а потім окрема гілка «випуску» для кожного результату (важливий етап / демонстрація / реліз / тощо). Інколи хтось зробить особисту гілку за якісь величезні зміни, які вони вносять або тестують, але це вкрай рідко, і зазвичай це стосується таких речей, як "перетворення гри для запуску з цією різною бібліотекою фізики", яка насправді може не перейти до випущений продукт.