Processo.md

+### Documentação de Negócio
+
+| [Escopo](escopo) | [**Processo**](processo) | [Gerência](gerencia) | [Design](design) | [Sprints](sprints)
+|-|-|-|-|-
+
+### Documentação Técnica
+
+| [Arquitetura](arquitetura) | [Banco de Dados](bancoDeDados) | [Transferência](transferência)
+|-|-|-
+
+---
+
+## Sumário
+
+[[_TOC_]]
+
+# Processo
+
+Esta sessão visa documentar os processos de desenvolvimento utilizados no projeto _Creative Flow_.
+
+## Git Flow
+
+![gitFlow](https://tools.ages.pucrs.br/creative-flow/wiki/-/raw/main/documents/processes/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.
+
 # 🌱 Padrões de Branch e Commit
 
 ## 📌 Commits
 
-Estamos utilizando o padrão [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) baseado em [@commitlint/config-conventional](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines).
+Estamos utilizando um padrão inspiraado no [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), que é baseado em [@commitlint/config-conventional](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines).
+
+- Os commits devem seguir `<tipo>(<escopo>): <mensagem>`;
+- Escopo é a abreviação da user story com três números, separados por dois hífens (ex. us-1-2-3);
+- Mensagens de commit não podem ultrapassar 72 caracteres e devem ser escritas no imperativo;
+- Tipo é conforme abaixo:
 
+### 🔹 Tipos de commit
 
-* Os commits devem seguir `<tipo>(<escopo>): <mensagem>`;
-* Escopo é a abreviação da user story com hífen e dois dígitos (e.g., us-01);
-* Mensagens de commit não podem ultrapassar 72 caracteres e devem ser escritas no imperativo;
-* Tipo é conforme abaixo:
+| Tipo    | Descrição
+|---------|----------
+| `feat`  | Adição de uma nova funcionalidade
+| `fix`   | Correção de um problema (bug ou não)
+| `refactor` | Refatoração de código (sem mudanças na funcionalidade)
+| `infra` | Tarefas de repositório, que não afetam diretamente o produto final (ex. atualização de dependências)
+| `test`  | Adição ou modificação de testes
+| `style` | Mudanças de formatação e estilo (sem afetar funcionalidade)
 
-### 🔹 Tipos de commit:
-| Tipo    | Descrição |
-|---------|----------|
-| `feat`  | Adição de uma nova funcionalidade |
-| `fix`   | Correção de um bug |
-| `refactor` | Refatoração de código (sem mudanças na funcionalidade) |
-| `chore` | Tarefas de manutenção (ex.: atualização de dependências) |
-| `docs`  | Alterações na documentação |
-| `test`  | Adição ou modificação de testes |
-| `style` | Mudanças de formatação e estilo (sem afetar funcionalidade) |
+### Exemplos
 
-### Exemplos:
-- `feat(us-01): I did something`
-- `fix(no-ref): something case sensitive`
+- `feat(us-1-2-1): Do something`
+- `fix(no-us): something case sensitive`
+
+### 🔹 Regras
 
-### 🔹 Regras:
 - O **tipo** do commit deve estar em **minúsculas**.
 - O identificador da **us** deve estar **entre parênteses**.
 - A **descrição** deve ser breve e começar com **letra minúscula**.
@@ -34,22 +61,138 @@ Estamos utilizando o padrão [Conventional Commits](https://www.conventionalcomm
 
 ## 📌 Branches
 
-As branches para desenvolvimento devem ser feitas a partir da `develop`. Os nomes de branch devem seguir `<tipo>/<escopo>/<descrição>`, onde a descrição **deve ser breve** e com hífen no lugar dos espaços. Tipo e escopo são definidos conforme dito anteriormente.
+As branches para desenvolvimento devem ser feitas a partir da `develop`. Os nomes de branch devem seguir `<escopo>/<descrição>`, onde a descrição **deve ser breve**, conter apenas letras minúsculas e utilizar hífens no lugar de espaços. Escopo é definido conforme dito anteriormente.
+
+### Exemplos
 
-### Exemplos:
-- `us-01/issue-naming`
+- `us-5-2-4/issue-naming`
 - `no-ref/writing-something-here`
 
-### 🔹 Regras:
-- **`us-XX/descricao`** → Para tarefas relacionadas a uma User Story (US). O número `XX` representa a ID da US.
+### 🔹 Regras
+
+- **`us-X-Y-Z/descricao`** → Para tarefas relacionadas a uma User Story (US). Os números `X`, `Y` e `Z` representam a ID da US.
 - **`no-ref/descricao`** → Para alterações sem uma US específica.
 - Utilize **hífens (-) para separar palavras** na descrição da branch.
+- A descrição deve ser escrita em **letras minúsculas**.
 - A descrição deve ser curta e clara.
 
 ---
 
 ## 🚨 Merge Requests
 
-O título do merge request deve seguir o mesmo formato dos commits acima. Os MRs precisam passar todos os jobs no pipeline e, após isso, podem ser mergeados por um AGES III. É obrigatório submeter o MR no formato definido pelo template.
+O título do merge request deve seguir o mesmo formato dos commits acima. Os MRs precisam passar todos os jobs no pipeline e, após isso, podem ser mergeados por um AGES III ou IV. É obrigatório submeter o MR no formato definido pelo template.
 
 ---
+
+## Tutoriais
+
+### Manter suas branches atualizadas
+
+Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar a seguinte sequência de comandos:
+
+``` git
+git fetch upsteram
+git rebase upsteram dev
+```
+
+### Criando novas branches
+
+Para criar uma nova branch, use a seguinte sequência de comandos:
+
+Todas as branches devem ser originadas da _dev_.
+
+``` git
+git checkout dev
+```
+
+Use isto para garantir que sua _dev_ (local) está atualizada
+
+``` git
+git pull origin dev
+```
+
+Agora, devemos criar a branch no seu repositório local
+
+``` git
+git checkout -b <Nome da branch no formato padrão>
+```
+
+Por fim, é necessáiro fazer um `push` para garantir que a branch estará no remoto
+
+``` git
+git push --set-upstream origin <Nome da branch no formato padrão>
+```
+
+Pronto! Agora você já pode começar a programar na sua branch.
+
+### Adicionando mudanças ao desenvolvimento
+
+#### Salvando Localmente
+
+Para realizar um commit, utilize:
+
+``` git
+git add <Nome do arquivo com extensão>
+```
+
+Ou, para múltiplos arquivos pode-se utilizar:
+
+``` git
+git add <arquivo 1> <arquivo 2> ...
+```
+
+Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit:
+
+``` git
+git commit -m "<Mensagem de commit no formato padrão>"
+```
+
+#### 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`:
+
+``` git
+git push
+```
+
+### Abrindo um Merge Request (MR)
+
+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.
+
+    ![mrOriginInto](https://tools.ages.pucrs.br/creative-flow/wiki/-/raw/main/documents/processes/mrOriginInto.png)
+
+2. Selecionar `Compare branch and continue`
+3. No campo **Title**, manter o mesmo formato de padrão do commit, com a descrição sendo um resumo do que foi feito em todos os commits da tarefa.
+
+    ![mrTitle](https://tools.ages.pucrs.br/creative-flow/wiki/-/raw/main/documents/processes/mrTitle.png)
+
+4. No campo Description, utilizar o template disponível e preenchê-lo com as informações necessárias.
+
+    ![mrDescription](https://tools.ages.pucrs.br/creative-flow/wiki/-/blob/main/documents/processes/mrDescription.png)
+
+5. Em **Asignee**, selecione _Assign to me_ para que você fique registrado como responsável pelo desenvolvimento daquela tarefa.
+
+    ![mrAssignToMe](https://tools.ages.pucrs.br/creative-flow/wiki/-/blob/main/documents/processes/mrAssignToMe.png)
+
+6. Em **Reviewer**, selecione o _AGES III_ responsável pela sua _Squad_ para que ele seja notificado pelo gitlab como responsável pela revisão.
+
+7. Em **Labels** adicione o tipo da tarefa que foi realizado.
+
+    ![mrLabel](https://tools.ages.pucrs.br/creative-flow/wiki/-/blob/main/documents/processes/mrLabel.png)
+
+8. Assegure-se que ambas as caixas `Delete source branch when merge request is accepted.` e `Squash commits when merge request is accepted.` estão marcadas.
+
+    ![mrMergeOptions](https://tools.ages.pucrs.br/creative-flow/wiki/-/blob/main/documents/processes/mrMergeOptions.png)
+
+9. 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.