|
|
|
<table>
|
|
|
|
<tr>
|
|
|
|
<th> [Home](home) </th>
|
|
|
|
<th> [Escopo e Cronograma](Escopo e Cronograma) </th>
|
|
|
|
<th> [Processo](Processo) </th>
|
|
|
|
<th> [Design/Mockups](Design/Mockups) </th>
|
|
|
|
<th> [Configuração](Configuracao) </th>
|
|
|
|
<th> [Arquitetura](Arquitetura) </th>
|
|
|
|
<th> [Infra](Infraestrutura) </th>
|
|
|
|
<th> [Código](Codigo) </th>
|
|
|
|
<th> [BD](Banco de dados) </th>
|
|
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
|
|
|
|
## Descrição
|
|
|
|
|
|
|
|
Esta seção da documentação visa apresentar os processos de desenvolvimento utilizados no projeto Globo Aplausos e os documentos referentes as formas de organização do time.
|
|
|
|
|
|
|
|
## Sumário
|
|
|
|
|
|
|
|
- [GitFlow](#git-workflow)
|
|
|
|
|
|
|
|
## GitFlow
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GitFlow é o processo de contribuição para os projetos utilizando a ferramenta de gerenciamento de versões Git. As definições descritas serão utilizadas nos repositórios do Frontend e Backend do projeto.
|
|
|
|
|
|
|
|
### Branches
|
|
|
|
|
|
|
|
Aqui será definida a estratégia de branching do projeto.
|
|
|
|
|
|
|
|
#### Branches protegidas
|
|
|
|
|
|
|
|
As branches protegidas não devem ser apagadas e possuem regras definidas:
|
|
|
|
|
|
|
|
#### **main**
|
|
|
|
|
|
|
|
A branch **main** é a principal do projeto. Esta branch representa o código do ambiente de produção da aplicação e deve ser alterada somente a partir de Merge Requests vindos da branch de **development** ou **fixes**. Somente AGES III e IV podem fazer Merges dos MR's e realizar alterações na branch main.
|
|
|
|
|
|
|
|
#### **development**
|
|
|
|
|
|
|
|
A branch **development** é a branch default para desenvolvimento do projeto. Esta deve ser a branch de partida de todas as outras branches do projeto, exceto **fix**. Essa branch é protegida para modificação que não seja através de Merge Requests. Qualquer AGES pode criar um MR pra ela e fazer merge desse MR.
|
|
|
|
|
|
|
|
#### Branches não protegidas
|
|
|
|
|
|
|
|
##### **Feature**:
|
|
|
|
Branches para a implementação de funcionalidades novas. O padrão de nomenclatura utilizado é _feature/US-númerodaUS-atividade-desenvolvida_, que representa uma breve descrição do que está sendo implementado na branch.
|
|
|
|
|
|
|
|
Exemplo: _feature/US-03-tela-login._
|
|
|
|
|
|
|
|
MRs dessas branches devem sempre ser abertos *para* **development**.
|
|
|
|
|
|
|
|
##### **Fix**
|
|
|
|
Branches para correção de bugs. O padrão de nomenclatura utilizado é _fix/US-01-problema_, que representa uma breve descrição do que está sendo corrigido na branch. Exemplo: _fix/US-01-bug-botão-header_.
|
|
|
|
|
|
|
|
Em caso de `Fix`, devem ser abertos Merge Requests para **main** e **development**.
|
|
|
|
|
|
|
|
|
|
|
|
#### Como criar uma branch?
|
|
|
|
|
|
|
|
Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch dev antes de criar uma branch nova:
|
|
|
|
|
|
|
|
```
|
|
|
|
git pull origin development
|
|
|
|
```
|
|
|
|
|
|
|
|
Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:
|
|
|
|
|
|
|
|
```
|
|
|
|
git checkout -b <nomeDaBranch>
|
|
|
|
```
|
|
|
|
|
|
|
|
Assim que criar a branch, é necessário fazer um \\\`push\\\`para garantir que a mesma estará remota:
|
|
|
|
|
|
|
|
```
|
|
|
|
git push --set-upstream origin <nomeDaBranch>
|
|
|
|
```
|
|
|
|
|
|
|
|
Pronto! Agora você já pode começar a programar na sua branch.
|
|
|
|
|
|
|
|
### Como adicionar suas mudanças ao fluxo de desenvolvimento:
|
|
|
|
|
|
|
|
#### Commits
|
|
|
|
|
|
|
|
##### Salvando Localmente
|
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git add <nomeDoArquivo>
|
|
|
|
```
|
|
|
|
|
|
|
|
</div>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:
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git commit -m 'descrição da tarefa em português'
|
|
|
|
```
|
|
|
|
|
|
|
|
</div>O padrão de commits é que as mensagens devem ser em Português.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### Salvando Remotamente
|
|
|
|
|
|
|
|
Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o GitLab.
|
|
|
|
Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando `push`:
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
|
|
|
```plaintext
|
|
|
|
git push
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Abrindo um Merge Request
|
|
|
|
Após a realização do desenvolvimento de uma tarefa e ela estiver de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de development, então deve-se abrir um Merge Request.
|
|
|
|
|
|
|
|
Para criar o Merge Request devem ser seguidos os seguintes passos:
|
|
|
|
1. Selecionar a branch de origem (branch de desenvolvimento) e branch (branch de development) de destino.
|
|
|
|
|
|
|
|
2. Selecionar `Compare branch and continues`.
|
|
|
|
|
|
|
|
3. No campo **Title**, preencher com um título que descreva a funcionalidade implementada ou bug corrigido e o número da tarefa que está sendo realizada.
|
|
|
|
|
|
|
|
4. No campo **Description**, preencher utilizando o seguinte template:
|
|
|
|
|
|
|
|
```
|
|
|
|
## Link da Tarefa
|
|
|
|
[Inserir link da tarefa do Trello]
|
|
|
|
|
|
|
|
## Descrição
|
|
|
|
|
|
|
|
[Descreva brevemente o propósito e as principais mudanças e adições que foram feitas nesta solicitação de Merge]
|
|
|
|
|
|
|
|
## Checklist
|
|
|
|
|
|
|
|
- [ ] Não deixou string literais no código.
|
|
|
|
- [ ] Utilizou as variáveis padronizadas do design system (cor, títulos/fontes).
|
|
|
|
- [ ] Não deixou código comentado.
|
|
|
|
|
|
|
|
|
|
|
|
## Screenshots (se aplicável)
|
|
|
|
|
|
|
|
[Adicione capturas de tela ou imagens relevantes, se necessário.]
|
|
|
|
```
|
|
|
|
|
|
|
|
4. Na seção **Asignee**, selecione **Assign to me** para que você fique registrado como responsável pelo desenvolvimento daquela tarefa.
|
|
|
|
|
|
|
|
5. Em **Labels** adicione o tipo da tarefa que foi realizado.
|
|
|
|
|
|
|
|
6. Revise se os arquivos estão corretos e clique em **Submit Merge Request**.
|
|
|
|
|
|
|
|
#### Revisando o Merge Request
|
|
|
|
|
|
|
|
Todo Merge Request deve ter pelo menos duas aprovações, sendo uma delas obrigatoriamente de um AGES III.
|
|
|
|
|
|
|
|
O merge deve ser feito com a estratégia *squash-commits* e as branches devem ser excluídas após o merge para a branch de destino. |
|
|
|
\ No newline at end of file |
