Git-Workflow.md
0 → 100644
| | [Home](home) | [**Escopo**](escopo) | [Git Workflow](git-workflow) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [Arquitetura](arquitetura) | [Gerência](gerencia) | [Código](codigo) | [BD](Banco de Dados) | [Qualidade](qualidade) | [Frontend](frontend) | [Backend](backend) | [Analytics](analytics) | |||
| | :----------: | :-------------------------------: | :------------------: | :--------------: | :--------------------------: | :--------------------: | :------------------------: | :--------------: | :---------------: | :--------------------: | :---------------: | :--------------------: | ------------: | | |||
| ## Sumário | |||
| - [Critério de aceite](#critério-de-aceite-de-merge-requests-mr) | |||
| - [GitFlow](#gitflow) | |||
| - [Opções de Ferramentas](#opções-de-ferramentas) | |||
| - [Comandos básicos](#comandos-b%C3%A1sicos) | |||
| - [Tutoriais](#tutoriais) | |||
| ## Critério de aceite de Merge Requests (MR) | |||
| * Branch testada | |||
| * Branch atualizada com a DEV | |||
| * Arquitetura Respeitada | |||
| * Código Limpo | |||
| * [Boas práticas atendidas](https://tools.ages.pucrs.br/) | |||
| ## GitFlow | |||
| As atualizações da Developer serão feitos através de Pull Requests | |||
|  | |||
| ## Opções de Ferramentas | |||
| #### GitKraken | |||
| * Download do [GitKraken](https://www.gitkraken.com/download). | |||
| *essa ferramenta facilita o uso do git através de uma interface intuitiva* | |||
| #### GitBash (Windows) | |||
| * Download do [GitBash](https://gitforwindows.org/). | |||
| ## Comandos básicos | |||
| * clonar um repositório: | |||
| `git clone ADICIONAR URL` | |||
| * verificar o status do repositório: | |||
| `git status` | |||
| * CRIAR uma nova branch: | |||
| `git checkout -b <branch desejada>` | |||
| * ALTERNAR para uma branch: | |||
| `git checkout <branch desejada>` | |||
| * add arquivos alterados e dar um commit na branch: | |||
| `git commit -a -m 'adicionei um novo rodapé [issue 53]'` | |||
| * primeira vez a enviar os dados para o repositório. | |||
| `git push origin <branch desejada>` | |||
| * reenviar os dados para o repositório. | |||
| `git push` | |||
| * baixar os dados do repositório. | |||
| `git pull` | |||
| * fazer um merge em duas branch's. | |||
| `git merge <nome da branch>` | |||
| ## Padrão para criação de branches | |||
| As branches criadas para desenvolvimento das funcionalidades pelas squads devem seguir o padrão e de acordo com seu objetivo: | |||
| Tags para os tipos de alterações: | |||
| * **feat** - Nova funcionalidade | |||
| * **fix** - Correção de defeito | |||
| * **docs** - Alteração de documentação | |||
| * **style** - Alterações visuais que não possuem alteração em codigo fonte | |||
| * **refactor** - Reescrever um código para corrigir um bug ou adicionar uma nova funcionalidade | |||
| * **perf** - Melhorar performance do sistema | |||
| `feat/NUM_TASK-breve-descricao` | |||
| Exemplo: `feat/44-cadastro-usuario` | |||
| ## Padrão para as mensagens de commit | |||
| Os commits deverão ter um padrão em suas mensagens para facilitar o entendimento da equipe no que foi desenvolvido: | |||
| `"Descrição breve do commit - Autores (caso realizado em equipe)"` | |||
| Exemplo: `"Compare button done - Fulano, Ciclano"` | |||
| **OBS:** Caso as atividades do commit tenham sido realizadas individualmente não é necessário informar os autores, porque a única pessoa envolvida será quem está subindo o commit. | |||
| # Git Workflow | |||
| - O Gitflow é um modelo alternativo de ramificação do Git que consiste no uso de ramificações de recursos (features) e várias ramificações primárias (`main` e `development`). | |||
|  | |||
| ### Branches | |||
| - Cada branch relacionada à features será criada a partir da branch development. Nos tópicos abaixo será explicado as nomenclatura que serão utilizadas para o desenvolvimento. | |||
| #### Nomes | |||
| - O nome da branch deve seguir o padrão **feature/nome-da-feature**, onde os nomes das features podem ser encontrados no Azure DevOps. Quando for necessário fazer alguma correção, o prefixo utilizado deverá ser **fix/nome-da-feature**. | |||
| #### Criação | |||
| - Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch development antes de criar uma branch nova: | |||
| ``` | |||
| git pull origin development | |||
| ``` | |||
| - Depois da execução desse comando é necessário criar a Branch, para isso, execute o seguinte comando: | |||
| ``` | |||
| git checkout -b <nomeDaBranch> | |||
| ``` | |||
| ### Commits | |||
| - Após criar a sua branch de desenvolvimento, faça as alterações necessárias no código e commite as mudanças: | |||
| - Para adicionar as mudanças é possível utilizar dois comandos: | |||
| - O comando `git add .` , faz com que todas as alterações que foram feitas localmente sejam commitadas no repositório remoto. | |||
| ``` | |||
| git add . | |||
| ``` | |||
| - O comando `git add <nomeDoArquivo>` , faz com que apenas as alterações do arquivo informado seja commitado no repositório remoto. | |||
| ``` | |||
| git add <nomeDoArquivo> | |||
| ``` | |||
| - Após adicionar as alterações é necessário commitar elas usando o comando `git commit-m"comentario-do-commit"` | |||
| ``` | |||
| git commit-m"comentario-do-commit" | |||
| ``` | |||
| - O comentário deve descrever o que foi alterado no código. | |||
| - Após, se for o primeiro commit dessa branch: | |||
| ``` | |||
| git push --set-upstream origin nome-da-branch | |||
| ``` | |||
| - Caso contrário utilize: | |||
| ``` | |||
| git push | |||
| ``` | |||
| **Importante**: Sempre envie seus commits para o repositório remoto após realizar o seu trabalho, assim os outros desenvolvedores terão sempre as ultimas atualizações do código. | |||
| ### Merge Requests | |||
| - Depois da sua issue ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de development. | |||
| - Antes de abrir a MR certifique-se que, não irá ocorrer conflitos da sua branch com a `development`, para isso, siga os seguintes passos: | |||
| ``` | |||
| git checkout development | |||
| git pull | |||
| git checkout <nome-da-branch> | |||
| git merge development | |||
| ``` | |||
| - Resolva os conflitos caso ocorra, após resolvê-los, envie as alterações para o Gitlab: | |||
| `git push` | |||
| #### Criando o Merge Request | |||
| - A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão **New Merge Request** siga os seguintes passos: | |||
| 1. Selecionar a branch de origem (sua branch de desenvolvimento); | |||
| 2. Selecionar a branch de destino (branch development); | |||
| 3. Selecione **Compare branches and continue**; | |||
| 4. Em **Title**, escreva um título que descreva a funcionalidade adicionada ou bug corrigido; | |||
| 5. Em **Description**, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados; | |||
| 6. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário); | |||
| 7. Na seção **Assignee**, marcar o responsável pela tarefa. | |||
| 8. Na seção **Reviwers**, marcar os AGES 3 (Eduardo Ballico, Leonardo Vargas Soares e Pedro Vieira). | |||
| ## Tutoriais | |||
| * [basico-1](https://git-scm.com/book/pt-br/v1/Ramifica%C3%A7%C3%A3o-Branching-no-Git-B%C3%A1sico-de-Branch-e-Merge). | |||
| * [basico-2](https://fjorgemota.com/git-sistema-de-controle-de-versoes-distribuido/). | |||
| * [GitFlow](https://fjorgemota.com/git-flow-uma-forma-legal-de-organizar-repositorios-git/). | |||
| \ No newline at end of file |