DINÂMICA DE TRABALHO

Para definir uma política de versionamento, precisamos conhecer quais são as formas usuais de se trabalhar com o git. Como já foi citado na seção anterior, a Atlassian recomenda uma série de dinâmicas de trabalho para o uso do git. E são em algumas dessas dinâmicas que iremos basear a política de versionamento do LEDS.

Para ter ideia, a seguir está um pequeno resumo de algumas das dinâmicas.

Centralizado

Aqui, a equipe centraliza todo o seu trabalho em um único repositório e um único branch desse repositório (master). É bom para equipes que estão iniciando com o uso do git ou nunca usaram um versionador antes. Porém é muito simples e limitada.

Branch de funcionalidade

Aperfeiçoa um pouco a dinâmica centralizada acrescentando flexibilidade. Nessa dinâmica, há obranch principal (master) que detém a estória oficial do projeto. Quando uma nova funcionalidade for iniciada, uma novabranch deve ser criada na ponta demaster.

Assim, as pessoas que vão trabalhar nessa funcionalidade, poderão trabalhar independentemente dos outros, e sem se preocupar em atrapalhar o funcionamento do projeto principal.

Essa dinâmica pode ser utilizada junto com a dinâmica de Pull Request para que haja maior controle do repositório.

Gitflow

O Gitflow define um modelo voltado para asreleasesdo projeto. Ele se baseia no trabalho de Vincent Driessen originalmente postado no seu blog, porém com algumas modificações por parte da Atlassian.

Enquanto ele é um pouco mais complicado que a dinâmica de Branches de Funcionalidade, ele é bom para gerenciar grandes projetos.

Nessa dinâmica, há categorias especias para cada branch. Essas categorias de branch tem significados especiais e, apenas para enumerar aqui, elas são:branch principal (master),branch de desenvolvimento,branches dereleases, de funcionalidades e de reparos.

Como é possível notar, essas novasbranches adicionam uma certa complexidade. E por isso é normalmente usada com equipes mais experientes e projetos mais robustos.

Forking

Nessa dinâmica, ao invés de todo o código do projeto estar centralizado em um único repositório, cada contribuidor tem o seu repositório. Sendo que existe um repositório oficial que está em posse dos mantenedores oficiais do projeto.

Essa dinâmica combina muito com projetosopen source, pois enquanto mantém o controle da versão oficial é possível aceitar contribuições de várias partes.

Pull Request

Esse workflow existe para ser combinado com alguns dos outros já citados. Ele apenas especifíca que novas contribuições podem (ou talvez devam) ser integradas ao projeto usandopull requests.

Por exemplo, João criou umabranch, no repositório de seu projeto, para desenvolver uma nova funcionalidade. Ao terminar a funcionalidade, ele criará umapull request solicitando que as suas mudanças sejam revistas e então integradas ao projeto oficial quando forem aceitas.

As pull request também são um ótimo meio de discutir sobre o código, já que referenciam mudanças específicas no projeto. A equipe pode então discutir a contribuição de João e, se necessário, fazer mudanças ao código. E somente quando tudo estiver correto, apull requestserá aceita, sendo feito, então, ummerge dabranch de João à branchmaster.