Git
Last updated
Last updated
O fluxo recomendado é um simples modelo de feature branch, com as seguintes características:
O master sempre está num estado deployable, ou seja, pode ir para produção
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
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:
Dev: cria uma nova branch feat/[nome da feature]
Dev: durante o desenvolvimento realiza commits na branch criada
Dev: gera builds da feature branch conforme necessidade (ambiente de integração do dev)
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
Dev: faz o push da branch e cria um PR no repositório para a branch master, colocando as pessoas da equipe como reviewers
Equipe: analisa o código, e uma vez que não sejam encontrados problemas, aprova o PR
Dev: após o PR aprovado, faz o merge via interface do repositório
Ferramenta de build automatizado: gera o build da master para o ambiente de homologação
Dev: gera uma tag baseado na master, seguindo o padrão SEMVER, e faz o push para o repositório git push --tags
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:
Dev: faz o checkout da versão de produção utilizando tag git checkout v0.12.2
Dev: cria uma nova branch a partir da tag git checkout -b hotfix-v0.12.3-[Identificador do card no issue tracker]
Dev: faz o commit da correção
Dev: gera builds da hotfix conforme necessidade (ambiente de integração do dev)
Dev: faz o push da branch para o remote: git push -u origin hotfix-v0.12.3-[Identificador do card no issue tracker]
Dev: gera o build da branch de hotfix para o ambiente de homologação
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
Dev: promove a tag para produção através da ferramenta de deploy
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)
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:
Exemplos:
feat/VB-1
fix/SG-2
Se NÃO houver um card no issue tracker, deve-se utilizar o escopo da mudança:
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)
Para as mensagens de commit deve-se seguir o seguinte esquema de nomenclatura:
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.
Para as mensagens de commit que necessitarem de uma descrição mais detalhada do que foi implementado, recomendamos o seguinte padrão:
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:
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.
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.
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.
Dado que uma branch está atrás da master, você pode seguir o seguinte processo, para atualizar ele com a master:
Verifique se todas as mudanças feitas estão commitadas e que nada ficou no em stash;
Faça um push para a branch remota: git push origin <sua-branch>
Retorne a branch master: git checkout master
Atualize a master: git pull origin master
Volte para a sua branch: git checkout <sua-branch>
Faça rebase da master: git rebase master
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)
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)
Agora você pode finalmente criar o Pull Request (PR) e pegar um pouco de café.
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:
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
```
No pull request da história trabalhada
Exemplo:
