Controle de versão com desenvolvimento de jogos - Quando devo ramificar?

Recentemente, comecei a usar o Controle de versão com meus projetos (mesmo trabalhando sozinho neles). Acho que é uma boa maneira de manter o histórico de todo o processo de desenvolvimento (com rastreamento de problemas) e me permite manter backups dos meus projetos ao longo do caminho.

À medida que descubro lentamente os recursos e as vantagens do uso do controle de versão, fico com a ideia de ramificação. Quando devo fazer isso?

Deveria ser cada vez que desenvolvo um novo recurso ou apenas de vez em quando quando atingisse um determinado marco?

Obviamente, a ramificação é bastante inútil quando se trabalha sozinho, mas eu prefiro pegar bons hábitos agora e me acostumar.

Enquanto lia o livro Game Coding Complete, de Mike McShaffry (que é um ótimo livro por sinal), fiquei totalmente perdido quando o autor recomendou manter três ramos, algo parecido com:

• Principal : Principal ramo de desenvolvimento onde são feitas alterações regulares.
• Ouro : ramo de ouro onde o último marco alcançado é mantido.
• Pesquisa : ramificação para testar coisas que poderiam afetar seriamente a ramificação principal (modificando componentes importantes do mecanismo de jogo etc.).

É assim que deveria ser? Como isso realmente funciona no mundo do desenvolvimento de jogos com grandes equipes de desenvolvedores?

Basicamente: quando é que geralmente se ramificam (e se fundem) no desenvolvimento de jogos?

A ramificação depende um pouco do suporte do VCS para o recurso (ou seja: se o VCS facilita ou dificulta).

Mas, no mínimo, você deseja uma ramificação para cada versão do seu projeto com suporte independente. Ou seja, se você tiver "Jogo 2" e "Jogo 2 + Expansão", que são produtos separados criados a partir da mesma base de código e para os quais você precisa poder corrigir e emitir atualizações, deseja ter cada um deles existem em sua própria ramificação fora da base de código principal, para que as correções na base de código principal possam ser mescladas em cada um desses produtos independentemente. (Normalmente, essas ramificações são criadas quando cada produto é lançado, ou talvez alguns dias / semanas antes, se houver pessoas trabalhando em coisas na base de código que você não deseja publicar com o lançamento inicial)

Ao trabalhar com um VCS que torna o uso de ramificações complicado ou doloroso (SourceSafe, svn, etc), você provavelmente ficará mais feliz ao manter uma ramificação "release" para cada produto lançado e ao desenvolver seu principal desenvolvimento em "trunk", mesclando alterações de "trunk" nos ramos "release" se e quando você precisar liberar hotfixes para esses releases.

Se, por outro lado, você estiver trabalhando com um dos sistemas VCS mais novos, criados em torno de ramificação e fusão (git, Bazaar, Mercurial, etc.), provavelmente será mais feliz desenvolvendo seu desenvolvimento em muito pouco tempo. ramos "feature" de longa duração. Por exemplo, se você estiver trabalhando no pathfinding do AI, poderá criar uma ramificação "pathfinding" e implementar o código nele. Quando você termina, mescla essa ramificação de volta ao seu tronco principal de desenvolvimento e (opcionalmente) exclui a ramificação na qual estava trabalhando. O benefício dessa abordagem é que ela permite que você trabalhe em várias tarefas simultaneamente, em vez de precisar concluir uma. tarefa antes de iniciar a próxima.

No meu projeto inicial atual (usando git), tenho cinco ramos de recursos diferentes ativos no momento, trabalhando em vários recursos diferentes. Duas delas são abordagens alternativas para fazer a mesma coisa (para criação de perfil), duas são idéias experimentais de mecânica de jogo, e uma é um grande refator dos meus sistemas de IA, e é realmente quebrada de tal maneira que o código não será compilado corretamente agora. Mas está comprometido em seu ramo de recursos para referência e backup, e ser quebrado não me impede de trabalhar nos outros recursos; Essas outras ramificações de recursos (e também o principal tronco de desenvolvimento) ainda são compiladas e executadas corretamente.

Na minha experiência no desenvolvimento profissional de grandes equipes, ainda estamos presos aos sistemas de controle de versão mais antigos (e com suporte comercial). O Perforce é provavelmente o mais usado, seguido pelo Subversion. Em todos os lugares em que trabalhei, tivemos uma ramificação 'tronco' e, em seguida, uma ramificação 'release' separada para cada entrega (marco / demo / release / etc). Ocasionalmente, alguém faz uma ramificação pessoal para uma grande mudança que está fazendo ou testando, mas isso é extremamente raro, e geralmente é para coisas como "converter o jogo para rodar com essa biblioteca de física diferente", que pode não ser realmente realizada. produto lançado.

Já é uma excelente resposta acima, mas uma coisa a ser observada é quando você deseja ramificar e quando deseja marcar.

A maioria dos vcs permitirá que você marque tags (às vezes eles chamam de rotulagem). Você deve aplicar uma tag toda vez que fizer uma compilação importante (para um teste de reprodução, beta ou para um recurso em exibição). Se você estiver usando algum tipo de integração contínua (e deve), o sistema de IC deve marcar as compilações bem-sucedidas. Basicamente, sempre que você faz algo para o qual deseja voltar (para criar uma ramificação ou para verificar novamente como fez algo nessa versão), crie uma etiqueta / rótulo. Eles geralmente são de baixo custo e simples de adicionar.

A outra coisa que eu recomendaria fortemente é manter seus ativos e código no mesmo sistema de versão. Ter uma ramificação (ou tag) de código é completamente inútil se você não conseguir igualar (e depois ramificar) os ativos. Essa é uma das principais razões pelas quais as empresas de jogos adoram o Perforce - é igualmente feliz em armazenar arquivos de arte binária e em código, e (ao contrário do git) é compreensível para tipos não técnicos!

Ah, e sempre que você quiser verificar os arquivos compilados no seu VCS, pare e pense em como evitar isso. Na minha experiência, quase sempre leva a dados incompatíveis, falta de origem (onde, por exemplo, uma textura DDS compactada é registrada, mas não a png de origem) e caos na linha. Se você tiver um pipeline de ativos que é mais bem servido por arquivos exportados serem armazenados em cache em algum lugar (para que todos não estejam gerando novamente o mesmo conjunto de arquivos), tenha um processo construindo os ativos de origem no seu VCS e colocando os arquivos exportados em um cache (ou unidade compartilhada ou mesmo um VCS separado). Mas não verifique esses arquivos exportados manualmente - ele vai te morder (especialmente se você estiver trabalhando como parte de uma equipe).

Adorei esse livro e recomendo a todos com interesses relevantes. Para projetos independentes, não há necessidade real de ramificação, a menos que você precise ou queira criar versões separadas; como um para Android e outro para PC, ou algo assim.

Como você disse, se você quiser adquirir bons hábitos, eu seguiria a abordagem de Mike. Faz muito sentido e é a abordagem que eu uso nos meus dois projetos independentes.

Tudo o que você precisar para voltar e trabalhar mais deve ser ramificável (mas não necessariamente ramificado ... ainda).

A razão para isso é simples. Você precisa emitir uma versão fixa desse código, não qualquer outro código; portanto, nesse momento, você precisa trabalhar em uma ramificação.

VCS são diferentes. Alguns - como o git - são muito fáceis de ramificar de qualquer commit posteriormente, outros - como o CVS - são muito complicados de se trabalhar depois.

Talvez você queira abrir uma pergunta no stackoverflow, perguntando como funcionar melhor com o sistema de controle de versão que você escolheu? Se você ainda não começou muito com o histórico, pode abrir uma pergunta descrevendo a maneira como trabalha e pedir uma recomendação do melhor sistema de controle de versão para você?