Processos.md

@@ -16,25 +16,25 @@
 
 # Processo de Desenvolvimento
 
-Esta seção é dedicada a apresentar o processo de desenvolvimento do time, junto dela serão apresentados documentos referentes a maneira como o time se organizou e trabalha.
-
+Esta seção é dedicada a apresentar o processo de desenvolvimento do time, com a finalidade de promover organização e padronização para o ambiente de trabalho dos membros da equipe.
+ 
 ## Git Workflow
 
-Git Workflow é um conjunto de práticas e padrões que as equipes de desenvolvimento usam para colaborar em projetos de software usando o sistema de controle de versão Git.
+Para nosso desenvolvimento e gerenciamento de código decidimos utilizar o Git Workflow como nosso padrão para controle de versionamento. Git Workflow é um conjunto de práticas e padrões que as equipes de desenvolvimento usam para colaborar em projetos de software usando o sistema de controle de versão Git.
 
-O Git é uma ferramenta poderosa que permite que os desenvolvedores trabalhem juntos em um mesmo código-fonte sem causar conflitos ou perder trabalho. O Git workflow estabelece uma estrutura para como as alterações no código são gerenciadas, revisadas e implementadas, a fim de garantir que o projeto progrida de maneira organizada e eficiente.
+![gitflow-1](uploads/32e173015d84fe39dbb9a1c2358214d2/gitflow-1.webp)
 
 ### Nomes das Branches
 
 Para padronizarmos os nomes das branches, deve-se nomeá-las da seguinte forma:
 
 ```
-<UserStory>-<Descrição>
+US + "Id da Issue"/"Descrição Resumida da Feature"
 ```
 
 Como por exemplo:
 ```
-US04-add-login
+US07/get-user-by-id
 ```
 
 ### Semântica dos Commits
@@ -46,9 +46,7 @@ Para padronizarmos a descrição dos commits, será utilizado um padrão semânt
 - **fix:** Essencialmente definem o tratamento de correções de bugs;
 - **docs:** referem-se a inclusão ou alteração somente de arquivos de documentação;
 - **test:** Adicionando testes ausentes ou corrigindo testes existentes nos processos de testes automatizados (TDD);
-- **build:** Alterações que afetam o sistema de construção ou dependências externas (escopos de exemplo: gulp, broccoli, npm),
 - **ci:** Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs);
-- **perf:** Uma alteração de código que melhora o desempenho;
 - **refactor:** Tipo utilizado em quaisquer mudanças que sejam executados no código, porém não alterem a funcionalidade final da tarefa impactada;
 - **style:** Alterações referentes a formatações na apresentação do código que não afetam o significado do código, como por exemplo: espaço em branco, formatação, ponto e vírgula ausente etc.);
 - **chore:** Atualização de tarefas que não ocasionam alteração no código de produção, mas mudanças de ferramentas, mudanças de configuração e bibliotecas que realmente não entram em produção;
@@ -56,7 +54,10 @@ Para padronizarmos a descrição dos commits, será utilizado um padrão semânt
 
 Exemplo da descrição commit:
 ```
-fix-loginError
+fix: loginError
+```
+```
+feature: userLogin
 ```
 
 ### Criando uma Branch
@@ -78,14 +79,4 @@ Para que uma tarefa seja considerada concluída ela deve seguir as seguintes con
 - O merge request da branch em que a tarefa foi desenvolvida para a develop deve ter sido concluída
 - O código deve ter sido revisado e aprovado
 - O código deve ter testes unitários e ter sido testado manualmente
-- Qualquer documentação necessária deve ter sido escrita (payloads, endpoints, ...)
-
-### Code freezing
-
-Code freezing é uma data para congelamento de entrada de código em produção. Após essa data, nenhum merge request será mais aceito. A única coisa que pode passar por esse bloqueio são hotfixes para erros em produção
-
-### Definition of Ready
-
-Para que uma tarefa seja considerada pronta para desenvolvimento, ela deve seguir as seguintes condições:
-- Qualquer tarefa da qual ela tenha dependência
-- O ambiente de desenvolvimento local deve estar devidamente setado
+- O código deve ter documentação para melhor entendimento das mudanças adicionadas (Swagger, descrição no MR, ...)