... | ... | @@ -9,7 +9,6 @@ Esta página descreve os processos utilizados pelo time ao longo do projeto. |
|
|
|
|
|
- [Desenvolvimento](#desenvolvimento)
|
|
|
- [Fluxo de trabalho no Git](#fluxo-de-trabalho-no-git)
|
|
|
- [Padronização](#padronização)
|
|
|
|
|
|
## Desenvolvimento
|
|
|
|
... | ... | @@ -68,13 +67,19 @@ Quando o desenvolvimento na nova branch foi concluído, deve-se então abrir um |
|
|
|
|
|
<img src="./resources/images/gitlab-aba-merge-request.png" width="180">
|
|
|
|
|
|
Nesta seção, selecione a opção "New Merge Request" e clique no botão "Change branches" para selecionar as branches as quais você deseja mesclar. Neste momento, devem ser selecionadas:
|
|
|
Nesta seção, selecione a opção "New Merge Request":
|
|
|
|
|
|
<img src="./resources/images/gitlab-novo-merge-request.png" width="400">
|
|
|
|
|
|
Então, clique no botão "Change branches" para selecionar as branches as quais você deseja mesclar. Neste momento, devem ser selecionadas:
|
|
|
|
|
|
- **Source branch** - sua feature ou fix branch onde foram implementadas as novas alterações
|
|
|
- **Target branch** - develop
|
|
|
|
|
|
Selecionadas as branches, confira os arquivos sendo alterados em "Compare branches", e então continue.
|
|
|
|
|
|
<img src="./resources/images/gitlab-merge-request-selecao-branches.png" width="450">
|
|
|
|
|
|
Antes de abrir o Merge Request clicando no botão de "Submit", os campos abaixo também devem ser preenchidos obrigatoriamente para serem revisados:
|
|
|
|
|
|
- **Título** - <tipo da tarefa (fix ou feat)>/<descrição da tarefa>
|
... | ... | @@ -82,6 +87,8 @@ Antes de abrir o Merge Request clicando no botão de "Submit", os campos abaixo |
|
|
- **Assignee** - integrante da equipe responsável pelo desenvolvimento da tarefa.
|
|
|
- **Milestone** - sprint na qual a tarefa foi realizada.
|
|
|
|
|
|
<img src="./resources/images/gitlab-merge-request-preenchimento.png" width="450">
|
|
|
|
|
|
Após abertura do Merge Request, o MR será revisado por colegas de equipe.
|
|
|
|
|
|
As revisões serão feitas por apenas um AGES 3 e AGES 4, assim devendo ele aprovar ou não. Caso o MR não seja aprovado, a pessoa que o revisou deve destacar nos comentários do MR o motivo para não tê-lo aprovado para que assim a pessoa que o desenvolveu possa fazer os ajustes para aprovação. Dessa forma, o feedback é uma ferramenta fundamental de ambos os lados a fim de garantir o cumprimento das funcionalidades a serem adicionadas pelo MR.
|
... | ... | @@ -89,7 +96,3 @@ As revisões serão feitas por apenas um AGES 3 e AGES 4, assim devendo ele apro |
|
|
Uma vez que a revisão tenha sido concluída e todos os pontos de ajuste apontados tenham sido commitador na Source Branch, realize o merge e envie as alterações à branch develop.
|
|
|
|
|
|
No final de cada Sprint, para gerar uma nova versão do projeto a ser apresentada para o cliente, deve ser aberto um Merge Request para realizar o merge da branch develop na branch master, atualizando o código de produção com os desenvolvimentos realizados durante a sprint. |
|
|
|
|
|
### Padronização
|
|
|
|
|
|
TODO |