Processo.md

@@ -11,6 +11,8 @@ Esta seção da documentação visa apresentar os processos de desenvolvimento u
 
 ## GitFlow
 
+![gitflow](uploads/3df58ab8df702f92f7836f6069f317e7/gitflow.png)
+
 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
@@ -21,14 +23,89 @@ Aqui será definida a estratégia de branching do projeto.
 
 As branches protegidas não devem ser apagadas e possuem regras definidas:
 
-#### main
+#### **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 Mas e realizar alterações na branch main.
 
-#### development
+#### **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/atividade_, que representa uma breve descrição do que está sendo implementado na branch. Exemplo: _feature/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/problema_,  que representa uma breve descrição do que está sendo corrigido na branch. Exemplo: _fix/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
+