> For the complete documentation index, see [llms.txt](https://vizir.gitbook.io/jeito-vizir/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vizir.gitbook.io/jeito-vizir/git.md). # 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 ![](https://312592185-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lxvt8aT-Hrrz87g6Hij%2F-LxvuBYAdHB-7-iOs4yz%2F-LxvuL9lYxJhjqikpyJl%2Ffeature-branches.svg?generation=1578331893085699\&alt=media) 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 ![](https://312592185-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lxvt8aT-Hrrz87g6Hij%2F-LxvuBYAdHB-7-iOs4yz%2F-LxvuL9numOwMWsoUwIZ%2Fhotfix-branches.svg?generation=1578331892959209\&alt=media) 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 ` 3. Retorne a branch master: `git checkout master` 4. Atualize a master: `git pull origin master` 5. Volte para a sua branch: `git checkout ` 6. Faça rebase da master: `git rebase master` 7. Se conflitos aparecerem, resolva eles e então adicione as resoluções (`git add `), 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 * [Still using GitFlow? What about a simpler alternative?](https://hackernoon.com/still-using-gitflow-what-about-a-simpler-alternative-74aa9a46b9a3) * [Karma Commit Messages](http://karma-runner.github.io/1.0/dev/git-commit-msg.html) * [Semantic Versioning](https://semver.org/)