Gitflow Workflow

No final do post anterior foi mencionado um modelo de branching para facilitar na organização do projeto. Agora vamos apresentar melhor esse modelo.

Alguns dos termos usados não parecem se encaixar muito bem pra jogos, mas os pincípios apresentados podem ser facilmente adaptados para o desenvolvimento de jogos.

Para esse guia, é recomendado conhecimento básico de git, conhecer termos como ‘commit’, ‘branch’, ‘merge’, ‘push’, ‘pull’, ‘remote’ e ‘repositório’.

O post original do modelo pode ser revisado aqui, e é a principal fonte de consulta usada para escrever esse guia.

gitflow_full

Branches principais

  • master
  • develop

Nesse modelo, o ‘master’ é considerado o branch principal do produto final, onde cada commit representa uma versão estável. O branch ‘develop’ reune todas as alterações que serão publicadas na próxima versão do jogo.

Aqui, uma “versão estável do jogo” não necessariamente significa a versão final do jogo. Uma versão estável pode ser a inclusão de uma nova mecânica, um novo level, uma alteração de arte, etc.

O branch master sempre é criado. Para criar o branch ‘develop’:

  • git branch develop master  # cria o branch
  • git checkout develop       # muda o branch atual

Alternativamente, o comando a seguir combina os dois acima:

  • git checkout -b develop master

Além desses, existem outras 3 famílias de branches:

  • Feature
  • Release
  • Hotfix

Cada um desses tipos de branch tem um objetivo específico e, ao contrário dos branches ‘master’ e ‘develop’, esses branches possuem tempo de vida limitado. Isso vai ficar mais claro daqui a pouco.


Feature

Um branch de feature deve ser criado a partir do branch ‘develop’, e seu nome deve refletir a feature que ele está incluindo no jogo. Quando a feature estiver finalizada, esse branch vai imergir de volta no ‘develop’ (merge). O objetivo desse branch é manter isolado o desenvolvimento de cada feature que, quando terminada, será adicionada ao jogo final, ou descartada (caso necessário) sem causar danos.

gitflow_feature

Para criar um branch de feature

  • git checkout -b nome_da_feature develop

Para incorporar a feature no ‘develop’:

  • git checkout develop               # muda branch atual
  • git merge --no-ff nome_da_feature  # integra a feature
  • git branch -d nome_da_feature      # remove o branch
  • git pull origin develop            # atualiza repositório

A flag --no-ff serve para manter o histórico do branch de feature, mesmo depois que ele seja deletado.


Release

Um branch de release deve ser derivado do ‘develop’, e seu nome segue a convenção ‘release-*’. No momento da criação desse branch, ‘develop’ deve ter todas as features que serão integradas na próxima versão do jogo. O objetivo desse branch é dar retoques antes do lançamento da nova versão, corrigir bugs de última hora e alterar valores de versão nos arquivos necessários, além de liberar o branch ‘develop’ para receber alterações para a próxima release. É proibido adicionar novas features em um branch ‘release’; novas features devem ser incluídas na próxima release.

Na criação do branch de release será atribuído um número de versão para essa release. Antes disso, ‘develop’ refletia o estado da “próxima release”, sem um número específico.

  • git checkout -b release-1.2 develop

Após todas as alterações feitas nesse branch, é necessário atualizar ‘master’ e ‘develop’ com essas alterações.

  • git checkout master           # muda o branch atual
  • git merge --no-ff release-1.2 # merge das alterações
  • git tag -a 1.2                # marca o commit com versão
  • git push origin master
  • git checkout develop
  • git merge --no-ff release-1.2 # pode causar conflitos
  • git branch -d release-1.2     # deleta o branch
  • git push origin develop

Hotfix

Um branch de hotfix tem uma utilidade parecida com o branch de release, mas são destinadas a alterações de última hora sobre uma versão que já foi lançada. O branch de hotfix é criado a partir do ‘master’. O nome desse branch segue a convenção ‘hotfix-*’. O número de versão atribuído aqui deve incrementar o terceiro nível de versão; no nosso exemplo, um branch de hotfix da versão 1.2 seria ‘hotfix-1.2.1’.

  • git checkout -b hotfix-1.2.1 master

Alterações feitas nesse branch devem ser refletidas tanto em ‘master’ quanto em ‘develop’.

  • git checkout master
  • git merge --no-ff hotfix-1.2.1
  • git tag -a 1.2.1
  • git push origin master
  • git checkout develop
  • git merge --no-ff hotfix-1.2.1
  • git branch -d hotfix-1.2.1
  • git push origin develop

 

 

girflow_hotfix


Resumo

O modelo apresentado pode ser visto dessa forma: um conjunto de branches, cada um desenvolvendo uma feature diferente; quando eles estão prontos, são selecionados para develop, onde é feita a integração das várias features adicionadas; quando a integração estiver pronta, tudo é passado para um branch ‘release’, onde últimos detalhes podem ser alterados; quando tudo estiver pronto, a release se torna parte de uma nova versão do jogo, no ‘master’ e, se algo der errado, um branch especial, ‘hotfix’, é usado para corrigir esses problemas.

Lembrando que o modelo foi apresentado usando git, mas os mesmos princípios podem ser aplicados a qualquer sistema de versionamento com suporte a branching e merging, como o PlasticSCM, por exemplo.

Espero que esse guia seja útil para nós, desenvolvedores de jogos. Quaisquer dúvidas e sugestões, fiquem à vontade para perguntar, comentar aqui no blog, mandar um email ou entrar em contato pela nossa página no Facebook ou pelo site.