|
|
|
| [Home](home) | [**Escopo**](escopo) | [Processo](processo) | [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)
|
|
|
|
| :----------: | :-------------------------------: | :------------------: | :--------------: | :--------------------------: | :--------------------: | :------------------------: | :--------------: | :---------------: | :--------------------: | :---------------: | :--------------------: | ------------: |
|
|
|
|
|
|
|
|
|
|
|
|
# Processos de Desenvolvimento
|
|
|
|
Este documento detalha os processos essenciais para colaborar de forma eficaz no projeto utilizando o Git, nosso sistema de controle de versão.
|
|
|
|
|
|
|
|
## Introdução ao Git
|
|
|
|
O Git é um sistema de controle de versão distribuído que facilita a colaboração em equipe, permitindo rastrear alterações, reverter versões e gerenciar o desenvolvimento de software de maneira organizada e eficiente.
|
|
|
|
|
|
|
|
## Git Workflow
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Branches Protegidas
|
|
|
|
|
|
|
|
As branches protegidas não devem ser apagadas e possuem regras definidas:
|
|
|
|
|
|
|
|
### Main
|
|
|
|
|
|
|
|
Branch dedicada para versões estáveis, que você pode utilizar para rollback em caso de problemas. Nenhum desenvolvimento ou hotfix ocorre diretamente aqui.
|
|
|
|
|
|
|
|
### Master
|
|
|
|
|
|
|
|
Branch estável usada para deploy em produção. Versões prontas para produção são lançadas aqui após os testes e verificações finais.
|
|
|
|
|
|
|
|
### Develop
|
|
|
|
Branch onde o desenvolvimento principal acontece. Funcionalidades são integradas e testadas antes de serem consideradas prontas para produção.
|
|
|
|
|
|
|
|
## Branches não Protegidas
|
|
|
|
|
|
|
|
### Feature
|
|
|
|
|
|
|
|
Ramificações da develop, usadas para desenvolver novas funcionalidades de forma isolada.
|
|
|
|
|
|
|
|
### Hotfix
|
|
|
|
|
|
|
|
Criada a partir da master para corrigir problemas críticos. Uma vez resolvido o problema, o hotfix é mesclado tanto na master quanto na develop, mantendo a correção na versão de produção e no código em desenvolvimento.
|
|
|
|
|
|
|
|
## Padronização de Branches e Commits
|
|
|
|
|
|
|
|
incluir aqui as padronizações que iremos utilizar.
|
|
|
|
|
|
|
|
## Passo a passo para utilização do Git:
|
|
|
|
|
|
|
|
1. Clonar o projeto
|
|
|
|
```
|
|
|
|
git clone <endereço-repositorio-projeto>
|
|
|
|
```
|
|
|
|
|
|
|
|
2. Criando uma nova branch
|
|
|
|
|
|
|
|
2.1 Primeiro atualize a branch para pegar mudanças feitas.
|
|
|
|
Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch develop antes de criar uma branch nova:
|
|
|
|
```
|
|
|
|
git pull origin develop
|
|
|
|
```
|
|
|
|
|
|
|
|
2.2 Crie a nova branch
|
|
|
|
|
|
|
|
OBS: Branches não devem possuir espaço no nome, substituir espaços ' ' por traços '-'
|
|
|
|
|
|
|
|
Depois da execução de atualização é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:
|
|
|
|
```
|
|
|
|
git checkout -b <nomeDaBranch>
|
|
|
|
```
|
|
|
|
|
|
|
|
3. Realizando commit
|
|
|
|
Realize commits para salvar as alterações realizadas na sua branch.
|
|
|
|
|
|
|
|
3.1 Adicione as alterações ao commit
|
|
|
|
Para garantir que apenas o código necessário para funcionamento da tarefa lembre-se de realizar o comando `add` apenas nos arquivos **essenciais** para a tarefa:
|
|
|
|
```
|
|
|
|
git add <nomeDoArquivo>
|
|
|
|
```
|
|
|
|
|
|
|
|
3.2 Realizando o commit
|
|
|
|
Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:
|
|
|
|
```
|
|
|
|
git commit -m 'descrição do commit'
|
|
|
|
```
|
|
|
|
|
|
|
|
4. Salve as alterações remotamente
|
|
|
|
Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando `push`:
|
|
|
|
```
|
|
|
|
git push
|
|
|
|
```
|
|
|
|
|
|
|
|
5. Merge Request para a branch master
|
|
|
|
Depois de uma task 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 principal (master). Para isso é necessário abrir um Merge Request pela platafora GitLab:
|
|
|
|
|
|
|
|
5.1 Criando Merge Request
|
|
|
|
A criação pode ser realizada na seção "Merge Request" do repositório em que a branch foi criada.
|
|
|
|
Clique no botão `Merge Request` e siga os passos abaixo:
|
|
|
|
|
|
|
|
1. Selecionar a branch de origem (sua branch de desenvolvimento);
|
|
|
|
2. Selecionar a branch de destino (branch master);
|
|
|
|
4. Em `Title`, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
|
|
|
|
5. Em `Description`escreva uma descrição das alterações realizadas.
|
|
|
|
6. Na seção `Assignee`, selecione `Assign to me` para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
|
|
|
|
7. Em `Reviewer` indique um membro AGES III ou IV para revisar as alterações propostas.
|
|
|
|
8. Em `Milestone` selecione a Sprint em que a tarefa foi realizada;
|
|
|
|
9. Em `Merge options`, marque a opção 'Delete source branch when merge request is accepted'
|
|
|
|
10. Por fim, revise se todos os arquivos estão corretos, e clique em `Create Merge Request`. |
