gerencia.md

@@ -13,7 +13,7 @@
 - [Matriz de Responsabilidade](#matriz-de-responsabilidade)
 - [Plano de Comunicação](#plano-de-comunicação)
 - [Plano de Riscos](#plano-de-riscos)
-- [Git Workflow](#git-workflow)
+- [Documento de Continuação](#documento-de-continuação)
 
 # Azure DevOps - Para Gerenciamento de Tarefas
 
@@ -71,104 +71,6 @@
 |   Falta de Motivação na Equipe    |      Lideranças devem acompanhar tarefas e verificar constantemente a moral da equipe     |      Eventos de comemoração e interação      |       Aceitar      |
 |   Alterações de Escopo   |      Fechar o escopo do projeto com os stakeholders antes do início do desenvolvimento     |      Negociar com stakeholders a troca de itens para não alterar o tamanho do escopo      |       Mitigar      |
 
-# 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`).
-
-![Fluxo_GIT](https://codigomaromba.files.wordpress.com/2019/01/gitflow-1.png)
-
-### 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 [Trello](https://trello.com/b/nGQNLhKU/meu-mundo-azul-ages). 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).
-
 # Documento de Continuação
 
 - Texto