arquitetura.md

@@ -126,24 +126,24 @@ Nas sessões abaixo será ensinado a instalação Git em sua máquina de acordo
 
 #### Download
 
-Faça o download e instale o Git a partir deste link, selecionando seu sistema operacional: [aqui](https://git-scm.com/downloads).
+Faça o download e instale o Git a partir deste [link](https://git-scm.com/downloads), selecionando seu sistema operacional.
 
-Ao final da instalação, abra o Git Bash (caso esteja usando Windows) ou um terminal e digite `git –version`. Ao retornar a versão do Git, significa que a instalação foi bem sucedida.
+Ao final da instalação, abra o Git Bash (caso esteja usando Windows) ou um terminal, e digite `git –version`. Ao retornar a versão do Git, significa que a instalação foi bem sucedida.
 
-> Usuários de Linux e Mac já possuem o Git nativamente. Para verificar, abra um terminal e digite `git –version`. Caso retorne a versão do Git, significa que o mesmo está devidamente instalado em sua máquina.
+> **Nota:** Usuários de Linux e Mac já possuem o Git nativamente. Para verificar, abra um terminal e digite `git –version`. Caso retorne a versão do Git, significa que o mesmo está devidamente instalado em sua máquina.
 
-**Configuração Git e GitLab**
+### Configuração Git e GitLab
 
 Abaixo será ensinado algumas configurações iniciais do Git, bem como o vínculo do seu ambiente local com o GitLab via SSH.
 
-**Configurações Iniciais**
+#### Configurações Iniciais**
 
 Caso esteja utilizando o Git pela primeira vez, rode os comandos abaixo para configurar, respectivamente, seu nome e seu email. Substitua os valores entre aspas pelos seus dados.
 
 - git config --global user.name "${YOUR_FULL_NAME}"
 - git config --global user.email "${YOUR_EMAIL}"
 
-**Configurando uma chave SSH**
+<!-- **Configurando uma chave SSH**
 
 **Passo 1: Gerando a chave SSH**
 
@@ -170,48 +170,47 @@ Entre na sua conta do GitLab e navegue em Preferences > SSH Keys;
 Cole o conteúdo copiado do arquivo id_rsa.pub e atribua um título a chave;
 Clique em Add Key para salvá-la.
 
-**Nota**: Não é obrigatório atribuir uma data de expiração para a chave.
-
+**Nota**: Não é obrigatório atribuir uma data de expiração para a chave. -->
 
 ### Git Branching Model
 
-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:
+Utilizaremos o [modelo de gestão de branches tradicional](https://nvie.com/posts/a-successful-git-branching-model/), realizando algumas adaptações baseadas no Trunked Based Development. 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;
+- Não utilizaremos branches de `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;
+- Substituição da branch de `feature` por um modelo voltado a tarefa, reduzindo seu ciclo de vida e seu número de commits. Esta branch será deletada após o merge.
 
 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`.
+- 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. Esta sempre será a branch mais atualizada;
+*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:
+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;
 
 ### Padrões de Commit
 
 Quando realizar um commit, tente manter o seguinte padrão nas mensagens:
 
-* título: número da task e breve descrição da mudança;
-* se preciso, adicione um descrição mais longa da mudança, do porquê ela se faz necessária ou do porquê foi feito dessa forma; essa descrição longa deve estar separada do título por uma linha em branco;
-* se mais de uma pessoa participou das mudanças do commit: indique a co-autoria conforme exemplo abaixo, também separada por uma linha em branco da descrição longa (o Git precisa de um formato bem específico nessa parte, com uma pessoa por linha; não é preciso adicionar uma linha para a pessoa que está fazendo o commit, porque o Git já pega isso automaticamente).
+- Título: número da task e breve descrição da mudança.;
+- Se preciso, adicione um descrição mais longa da mudança, do porquê ela se faz necessária ou do porquê foi feito dessa forma; essa descrição longa deve estar separada do título por uma linha em branco;
+- Se mais de uma pessoa participou das mudanças do commit: indique a co-autoria conforme exemplo abaixo, também separada por uma linha em branco da descrição longa (o Git precisa de um formato bem específico nessa parte, com uma pessoa por linha; não é preciso adicionar uma linha para a pessoa que está fazendo o commit, porque o Git já pega isso automaticamente).
 
-Exemplo:
+Exemplo de mensagem de commit e descrição:
 
 ```
-#01: Tela de login
+#01: Desenvolvimento da tela de login
 
 Criada tela de login e definida rotas, a construção do componente de seleção do perfil não faz parte dessa task.
 
@@ -220,18 +219,62 @@ Co-authored-by: Marcos Silva <[email protected]>
 
 ### Code Review
 
-Após o desenvolvimento de uma task, um *pull/merge request* (PR) deve ser aberto com destino à branch *develop* do repositório relativo à task: *app* ou *api*. Todos os PRs são revisados por pelo menos dois AGES III, que se responsabilizam por garantir a qualidade do que foi desenvolvido e que os artefatos e estruturas se adequem aos padrões definidos neste documento.
+Após o desenvolvimento de uma task, um _pull/merge request_ (PR) deve ser aberto com destino à branch _develop_ do repositório relativo à task. Todos os PRs são revisados por pelo menos dois AGES III, que se responsabilizam por garantir a qualidade do que foi desenvolvido e que os artefatos e estruturas se adequem aos padrões definidos neste documento.
 
 Os AGES III se comprometem a revisar os PRs o mais rápido possível, garantindo que PRs abertos até dois dias antes de uma entrega serão integrados (se cumprirem todas as regras do code review).
 
-Foram definidas algumas regras usadas durante o processo de code review dos PRs abertos nos repositórios:
+### Hands On
+
+Esta seção é dedicada ao teste da configuração do seu ambiente, bem como a prática do Gitflow do projeto. O _hands on_ consiste em atualizar o README do repositório da Wiki com o seu nome e seu nível AGES, além de, ao final, submeter seu primeiro Pull Request.
+
+#### Passo 1: Clonar o repositório da Wiki
+
+Efetue o clone do repositorio da Wiki via HTTPS e abra o projeto com um editor de texto. Link: https://tools.ages.pucrs.br/ficai-4.0/ficai-4.0-wiki
+
+#### Passo 2: Criando uma branch nova
+
+A partir da branch main, crie uma nova branch seguindo o comando abaixo:
+
+```sh
+git checkout -b seuPrimeiroNome-handson
+```
+
+#### Passo 3: Editando o README.md
+
+Abra o arquivo README.md e atualize a tabela de membros com seu nome e seu nível AGES.
+
+#### Passo 4: Commit em suas mudanças
+
+Efetue o commit das suas mudanças rodando os comandos abaixo
+
+```sh
+git add .
+git commit -m “Add my name to the table”
+```
+#### Passo 5: Submetendo um pull request
+
+Após efetuar o commit, rode o comando abaixo para enviar suas modificações para o repositório remoto:
+
+```sh
+git push origin seuPrimeiroNome-handson
+```
+
+> **Nota:** Provavelmente, ao efetuar o push, o GitLab irá requisitar suas credenciais.
+
+Após efetuar, vá no painel do GitLab, procure pelo repositório Ficai-4.0 Wiki e, no menu lateral procure por Merge Request. Na opção “Select source branch” selecione a branch que você criou e clique em “Compare branches and continue”.
+
+Dentro do merge request, mantenha as informações padrão, porém, na opção Reviewer, marque um dos AGES III para fazer a revisão. Após isso, clique em “Create merge request” e aguarde a aprovação.
+
+Com este fluxo completo e bem sucedido, significa que seu ambiente está devidamente configurado para utilizar os repositórios do FICAI 4.0.
+
 
-* *app*:
+<!-- Foram definidas algumas regras usadas durante o processo de code review dos PRs abertos nos repositórios:
 
-* *api*:
+- _app_:
   
+- _api_:
 
-Essas regras foram adicionadas como template de PR em cada projeto.
+Essas regras foram adicionadas como template de PR em cada projeto. -->
 
 ## Arquitetura Geral da Aplicação