arquitetura.md

@@ -128,7 +128,30 @@ TBD
 
 ### Git Branching Model
 
-TBD
+Utilizaremos o [modelo de gestão de branches tradicional](https://nvie.com/posts/a-successful-git-branching-model/), realizando algumas adaptações. As alterações que faremos são:
+
+- Não utilização de branches no modelo `hotfix/*`, visto que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente;
+- Integração da branch de `release/*` com a branch de `develop/*`, com o propósito de unificar suas funcionalidades;
+
+O desenvolvimento nos repositórios _frontend_ e _backend_ **deverá** seguir o fluxo descrito abaixo:
+
+* 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/t01-login` ou `feature/t05-dropdown-list-login`);
+* 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.
+
+Dessa forma, o fluxo usual de trabalho é o seguinte:
+
+1. antes de iniciar o desenvolvimento de uma task, fazer checkout para a branch `develop` e pegar as últimas atualizações (`pull`);
+1. criar uma branch para a task com o ID da task (`feature/tXX-YYYYY`);
+1. "enviar" a branch para o remoto (`git push -u origin feature/tXX-YYYYY`);
+1. desenvolver, commitar mudanças e atualizar o remoto (`push`);
+1. voltar para o item **4** até finalizar a task;
+1. abrir um PR com destino à branch `develop`;
+1. mover o card da task no Trello para a lista *Code Review* e avisar no Discord (canal #code-review) que a task está pronta para review;
+1. fim! :smile_cat:
 
 ### Padrões de Commit