Ветвление в некоторой степени зависит от поддержки этой функции VCS (т. Е. Упрощает ли VCS ее или затрудняет).
Но, как минимум, вам нужна ветка для каждого независимо поддерживаемого релиза вашего проекта. То есть, если у вас есть «Игра 2» и «Игра 2 + Расширение», которые являются отдельными продуктами, созданными из одной и той же кодовой базы и к которым нужно иметь возможность устанавливать патчи и выпускать обновления, то вы хотите иметь каждый из этих существуют в своей собственной ветке вне основной кодовой базы, так что исправления базовой кодовой базы могут быть объединены в каждый из этих продуктов независимо. (Как правило, эти ветки создаются, когда выпускается каждый продукт, или, может быть, за несколько дней / недель до этого, если у вас есть люди, работающие над тем в базе кода, которую вы не хотите выпускать с первоначальным выпуском)
При работе с VCS, которая делает использование веток сложным или болезненным (SourceSafe, svn и т. Д.), Вы, вероятно, будете счастливы, поддерживая ветку «release» для каждого выпущенного продукта и занимаясь основной разработкой в «trunk», объединение изменений из "trunk" в ветки "release", если и когда вам нужно выпустить исправления для этих выпусков.
Если, с другой стороны, вы работаете с одной из более новых систем VCS, которые построены на ветвлении и слиянии (git, Bazaar, Mercurial и т. Д.), То вы, вероятно, будете счастливы, выполняя разработку в короткие сроки. "особенные" ветки. Например, если вы работаете над AI pathfinding, вы можете создать ветку «pathfinding» и реализовать там код. Когда вы закончите, вы сливаете эту ветку обратно в основной ствол разработки и (необязательно) удаляете ветку, в которой работали. Преимущество этого подхода заключается в том, что он позволяет вам работать над несколькими задачами одновременно, вместо того, чтобы выполнять одну из них. задание, прежде чем приступить к следующему.
В моем текущем домашнем проекте (с использованием git) у меня сейчас пять активных веток функций, работающих над различными функциями. Два из них - альтернативные подходы к выполнению одного и того же (для профилирования), два - экспериментальные идеи игровой механики, и один - большой рефакторинг моих систем ИИ, и на самом деле он сломан таким образом, что код не будет компилироваться в настоящее время. Но он передается в своей ветке функций для справки и для резервного копирования, и его поломка не мешает мне работать над другими функциями; Эти другие ветви функций (и основная ветка разработки) по-прежнему компилируются и работают правильно.
По моему опыту разработки профессиональных игр для большой команды, мы все еще в основном придерживаемся старых (и поддерживаемых в коммерческих целях) систем контроля версий. Perforce, вероятно, наиболее часто используемый, сопровождаемый Subversion. Везде, где я работал, у нас была ветка 'trunk', а затем отдельная ветка 'release' для каждого результата (milestone / demo / release / etc). Иногда кто-то делает персональную ветвь для каких-то огромных изменений, которые он делает или тестирует, но это крайне редко, и обычно для таких вещей, как «преобразование игры для запуска с этой другой библиотекой физики», которая на самом деле может и не пройти к выпущенный продукт.