arquitetura.md

 | [Home](home) | **Arquitetura** |[Banco de Dados](banco_dados) | [Configuração](configuracao) | [Gerenciamento do Projeto](Gerenciamento_projeto) | [Instalação](instalacao) | [Materiais de Estudo](Materiais_estudo) | [Mockups](mockups) | [Requisitos](requisitos) |  [Reuniões](reunioes) | [Sprints](sprints) |
 | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ | ------ |
 
-## Acesso rápido:
-* [Fluxograma Geral](http://tools.ages.pucrs.br/dtool/wiki/wikis/arquitetura#fluxograma-de-funcionamento-do-aplicativo)
-* [Próximos artefatos](http://tools.ages.pucrs.br/dtool/wiki/wikis/arquitetura#pr%C3%B3ximos-poss%C3%ADveis-artefatos)
-
-
 # Arquitetura do Sistema
 
+* [Fluxograma de funcionamento do aplicativo](#fluxograma-de-funcionamento-do-aplicativo)
+* [Git Branching Model](#git-branching-model)
+* [Próximos artefatos](#pr%C3%B3ximos-poss%C3%ADveis-artefatos)
+
 ## Fluxograma de funcionamento do aplicativo
 
 Este fluxograma é referente à aplicação mobile que tem como principal função a coleta do tempo das atividades.
@@ -18,6 +17,29 @@ Perceba que num primeiro momento estamos abstraindo o fluxo de inserção de dad
 
 É possível notar que não é necessário login para o uso de funcionários e bolsistas, estes só precisam identificar o respectivo hospital, para que sejam vinculados os processos e atividades referentes à sua função. A identificação do paciente é apenas para identificar e diferenciar possíveis processos parecidos sendo realizados ao mesmo tempo. Esta identificação deve ser feita de forma que facilite o máximo possível o atendimento. Possíveis identificações: Iniciais do paciente, Código do atendimento do paciente no hospital ou outro. (Esta identificação deve ser informada no momento no fluxo apresentado).
 
+## Git Branching Model
+
+O modelo de gestão das branches do Git é baseado no [Git Flow "trandicional"](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.
+
+O desenvolvimento nos repositórios _app_ e _api_ deve seguir o fluxo de Git aqui definido:
+
+- 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.
+
+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`);
+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! 😃
+
 ### Próximos possíveis artefatos:
 
 * [ ]  Segurança