Git

Fluxo Git

O fluxo recomendado é um simples modelo de feature branch, com as seguintes características:

  1. O master sempre está num estado deployable, ou seja, pode ir para produção

  2. Todas as mudanças são feitas através de pull requests + merge, por meio da criação de features branches. Os commits direto na master estão desabilitados

  3. Para resolver conflitos e atualizar com a master, use rebase na sua feature branch

Com base no modelo, o fluxo de desenvolvimento de uma nova funcionalidade segue os seguintes passos:

  1. Dev: cria uma nova branch feat/[nome da feature]

  2. Dev: durante o desenvolvimento realiza commits na branch criada

  3. Dev: gera builds da feature branch conforme necessidade (ambiente de integração do dev)

  4. Dev: ao término do desenvolvimento da feat, irá fazer git rebase master, para atualizar com o estado atual da branch de master, e resolver possíveis conflitos

  5. Dev: faz o push da branch e cria um PR no repositório para a branch master, colocando as pessoas da equipe como reviewers

  6. Equipe: analisa o código, e uma vez que não sejam encontrados problemas, aprova o PR

  7. Dev: após o PR aprovado, faz o merge via interface do repositório

  8. Ferramenta de build automatizado: gera o build da master para o ambiente de homologação

  9. Dev: gera uma tag baseado na master, seguindo o padrão SEMVER, e faz o push para o repositório git push --tags

  10. Dev: promove a tag para produção através da ferramenta de deploy

Agora em caso de hot-fix para produção. O fluxo seria o seguinte:

  1. Dev: faz o checkout da versão de produção utilizando tag git checkout v0.12.2

  2. Dev: cria uma nova branch a partir da tag git checkout -b hotfix-v0.12.3-[Identificador do card no issue tracker]

  3. Dev: faz o commit da correção

  4. Dev: gera builds da hotfix conforme necessidade (ambiente de integração do dev)

  5. Dev: faz o push da branch para o remote: git push -u origin hotfix-v0.12.3-[Identificador do card no issue tracker]

  6. Dev: gera o build da branch de hotfix para o ambiente de homologação

  7. Dev: uma vez validado o hotfix, o dev gera uma tag baseado na hotfix, seguindo o padrão SEMVER, e faz o push para o repositório git push --tags

  8. Dev: promove a tag para produção através da ferramenta de deploy

  9. Dev: uma vez o hotfix aplicado e validado em prod, faz o PR para a master e a partir daqui segue o mesmo fluxo de uma feature (continuando do passo 5)

Definições de nomenclatura

Branches

Os nomes dos branches criados devem seguir o seguinte padrão de nomenclatura.

Se houver um card criado no issue tracker do projeto, deve-se utilizar o card id:

tipo/CARD-ID

Exemplos:

  • feat/VB-1

  • fix/SG-2

Se NÃO houver um card no issue tracker, deve-se utilizar o escopo da mudança:

tipo/ESCOPO

Exemplos:

  • feat/add-logs

  • fix/input-mask

O tipo deve-se relacionar ao que aquela branch busca resolver, por exemplo, se será desenvolvida uma funcionalidade nova, se será implementada uma correção, etc.

Alguns tipos possíveis são os seguintes:

  • feat (será implementada uma nova funcionalidade)

  • fix (será implementada uma correção para resolver um problema existente)

  • refactor (será realizado algum refactor em parte do código que já funciona)

  • chore (será implementa alguma melhoria de código e/ou infraestrutura)

  • test (será desenvolvido algum novo cenário de teste para a aplicação)

  • docs (será feita alguma mudança na documentação)

Mensagens de commit

Para as mensagens de commit deve-se seguir o seguinte esquema de nomenclatura:

tipo(ESCOPO): mensagem

Aqui, o tipo e o ESCOPO devem se referir à branch que está sendo utilizada para o desenvolvimento. Já a mensagem deve descrever brevemente o conteúdo daquela alteração.

Mensagens de commit com descrição longa

Para as mensagens de commit que necessitarem de uma descrição mais detalhada do que foi implementado, recomendamos o seguinte padrão:

tipo(ESCOPO): resumo da mensagem

A mensagem detalhada da implementação.

Incremento de versão semântico

Para melhorar a previsibilidade das releases, recomenda-se a utilização do versionamento semântico (semver) que resumidamente, divide as releases em três tipos MAJOR, MINOR E PATCH. Cada release deve ser categorizada em um dos três tipos da seguinte maneira:

MAJOR

Deve-se fazer um release MAJOR (1.0.0 -> 2.0.0) quando são liberadas funcionalidades novas que necessitem adicionar módulos nativos na aplicação, ou funcionalidades que mudem drasticamente o funcionamento/estrutura/layout do aplicativo.

MINOR

Deve-se fazer um release MINOR (1.0.0 -> 1.1.0) quando são liberadas funcionalidades incrementais a uma versão, sem a necessidade de novos módulos nativos e também sem grandes alterações estruturais no aplicativo.

PATCH

Deve-se fazer um release PATCH (1.0.0 -> 1.0.1) quando são liberadas correções para a aplicação em produção, nesse caso não podem ser adicionados/removidos módulos nativos e dependendo do caso podem ser utilizadas ferramentas como o Microsoft App Center (aka Code Push) para evitar o tempo de aprovação e revisão das lojas de aplicativos.

Trabalhando com branches

Dado que uma branch está atrás da master, você pode seguir o seguinte processo, para atualizar ele com a master:

  1. Verifique se todas as mudanças feitas estão commitadas e que nada ficou no em stash;

  2. Faça um push para a branch remota: git push origin <sua-branch>

  3. Retorne a branch master: git checkout master

  4. Atualize a master: git pull origin master

  5. Volte para a sua branch: git checkout <sua-branch>

  6. Faça rebase da master: git rebase master

  7. Se conflitos aparecerem, resolva eles e então adicione as resoluções (git add <arquivo-arrumado>), e após resolver todos os conflitos continue o rebase (git rebase --continue)

  8. Após o rebase você agora precisa atualizar a sua branch remota: git push -f (sim -f, porquê após o rebase os seus commits tiveram seus hashes atualizados)

  9. Agora você pode finalmente criar o Pull Request (PR) e pegar um pouco de café.

Breaking Changes

Ao trabalhar com bibliotecas, mudanças de código podem alterar as interfaces utilizadas por terceiros. Essas atualizações devem ser acompanhadas por um incremento de versão da biblioteca e da versão de dependência nas aplicações que usem esse lib.

No git, é importante sinalizar essas BREAKING CHANGES em 3 lugares: 1. Nos commits que possam causar breaking changes

  • Exemplo:

    Commit message: refactor(input): use props for state management
Commit description: *BREAKING CHANGE*: input behavior now must be implemented by the peer, including value and handleChange

    1. No CHANGELOG.md do projeto

  • Exemplo:

    ```

  • BREAKING CHANGE: Update input to use props for state management. Input behavior now must be implemented by the peer, including value and handleChange

    ```

    1. No pull request da história trabalhada

  • Exemplo:

    (...Descrição)

*BREAKING CHANGE*: Update input to use props for state management. Input behavior now must be implemented by the peer, including value and handleChange

Referências

PreviousPadrões de códigoNextCI & CD

Last updated