João Vianna Moog Brentano · f7dfc7d9
--- a/processo.md
+++ b/processo.md
@@ -14,130 +14,29 @@ Esta seção é dedicada a apresentar o processo de desenvolvimento do time, jun
 - [Plano de Comunicação](#plano-de-comunicação)
 - [Plano de Riscos](#plano-de-riscos)
-## Git Workflow
+## Git Branching Model
-### Branches
+O modelo de gestão das branches do Git é baseado no [Git Flow "tradicional"](https://nvie.com/posts/a-successful-git-branching-model/) com adaptações. Não é previsto o uso de branches `hotfix/*`, uma vez que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente.
-#### Nomes
+O desenvolvimento nos repositórios devem seguir o fluxo de Git aqui definido:
-Como padrão para nomes de branches, foi decidido o seguinte:
+* uma branch `master` com o código atualmente em produção;
+* uma branch `develop` com o código em desenvolvimento, com funcionalidades finalizadas mas ainda em fase de testes para validação;
+* feature branches para tasks relacionadas às user stories a serem desenvolvidas. Uma branch de task deve ser nomeada com o número único da task, seguida da breve descrição da task (por exemplo, `feature/t06-login` ou `feature/t24-reports-ui`);
+* quando uma feature é finalizada, um PR da branch `feature/` relacionada é aberto com destino à branch `develop`.
-```
+O código da `develop` é integrado com a `master` ao final da sprint, após validação dos stakeholders do que foi desenvolvido.
-<tipoDeItem>-<nomeDoItem>
-```
-Exemplo de Componentes:
+Dessa forma, o fluxo usual de trabalho é o seguinte:
-```
-component-navBar
-component-slider
-```
-Exemplo de Páginas:
-```
-page-recipes
-page-creations
-```
-#### Criação
-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 dev
-```
-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.
-### Commits
-Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de `commit` e `push`
-#### 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:
-```
-git add <nomeDoArquivo>
-```
-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:
-```
-git commit -m 'descrição da tarefa em português'
-```
-Não hesite em realizar vários commits, assim podemos ter docuemntado e salvo vários estados do desenvolvimento
-#### Salvando Remotamente
-Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando `push`:
-```
-git push
-```
-### Merge Requests
-Depois de uma task 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 desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:
-#### 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 dev);
-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`, selecione `Assign to me` para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
-8. Em `Milestone` selecione a Sprint em que a tarefa foi realizada;
-9. Em `Labels`selecione qual é o tipo de tarefa que foi realizada;
-10. Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em `Submit Merge Request`.
-#### Revisando o Merge Request
-A revisão de merge request pode ser realizada por qualquer desenvolvedor, mas é preciso da aprovação de pelo menos um AGES III ou AGES IV para que a mesma seja incorporada na dev.
-Na hora de revisar o Merge Request, entre na branch em sua máquina e teste a funcionalidade/bug/componente/tela de acordo com os critérios de aceitação apresentados no [Airtable](https://airtable.com/tblV0c8w2YX9PZAAC/viw4mJkZmd28WlplE?blocks=hide).
-Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração.
-## Matriz de Responsabilidade
-Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.
-| **Atividades**             | **AGES I** | **AGES II** | **AGES III** | **AGES IV** |
-| -------------------------- | :--------: | :---------: | :----------: | :---------: |
-| Alimentar a wiki           |       R    |     R      |       R    |     R/A     |
-| Definir squads             |     I/C    |      C      |      C       |     R/A     |
-| Definir marcos da sprint   |     I/C    |      I/C    |     I/C      |     R/A     |
-| Quebra de tasks            |     I/C    |      I/C    |     R/A      |     R/A     |
-| Desenvolvimento            |      R     |       R     |     R/A      |     I       |
-| Code review                |      I     |       I     |     R/A      |     I       |
-| Executar testes funcionais |      I     |      R/A    |      C       |             |
-| Deploy da aplicação        |            |        C    |     R/A      |       C     |
-| Apresentação da review     |            |             |              |     R/A     |
- I: Deve ser informado
- C: Deve ser consultado
- R: Responsável
- A: Aprova
+1. antes de iniciar o desenvolvimento de uma task, fazer checkout para a branch `develop` e pegar as últimas atualizações (`pull`);
+2. criar uma branch para a task com o ID da task (`feature/tXX-YYYYY`);
+3. "enviar" a branch para o remoto (`git push -u origin feature/tXX-YYYYY`);
+4. desenvolver, commitar mudanças e atualizar o remoto (`push`);
+5. voltar para o item **4** até finalizar a task;
+6. abrir um PR com destino à branch `develop`;
+7. mover o card da task no Trello para a lista *Code Review* e avisar no Slack (canal #code-review) que a task está pronta para review;
+8. fim! :smiley:
 ## Plano de Comunicação