Essa seção é dedicada a exposição e documentação dos processos do time, tais como Git Workflow escolhido e <adicionar mais processos de exemplo aqui>, tanto para proporcionar um ambiente organizado para os AGES e outros usuários que consultarão o projeto, quanto para servir de consulta aos integrantes do time durante o processo de desenvolvimento

Sumário

• Git Workflow

Git Workflow

O workflow escolhido se espelha no Gitflow workflow. As duas branches principais são master e develop:

• A master é onde concentramos as versões estáveis e as entregas para os Stakeholders. Por padrão iremos criar tags para cada merge que é feito nessa branch, seguindo o padrão de versionamento semântico
• A develop será de onde todas as outras branches serão criadas (com exceção à hotfix), e onde concentraremos a versão mais nova do software, sendo então onde as novas features serão mergeadas.

Branches

Os possíveis tipos de branch que teremos e o padrão que cada uma delas deve seguir:

master

Branch principal do projeto, onde o código testado e validado com o cliente é disponibilizado, através do merge de uma branch release. Essa branch ficara bloqueada para commits.

develop

Branch de integração dos códigos desenvolvidos durante a duração do projeto. Todos as branches devem ser criadas a partir dela e os MRs correspondentes devem apontar para ela (salvo exceções). Essa branch também ficara bloqueada para commits, sendo possível altera-la apenas através de MRs.

feature

Branch utilizada para o desenvolvimento das US.

feature/<Codigo_da_Issue>_<Nome_da_Issue>
Ex.: feature/02_Criar_Botão

release

Para realizar os testes e ajustes finais antes de disponibilizar o código em produção (master). As releases são enviadas para a master somente após a validação com os clientes.

release/<nr_da_sprint>
Ex.: release/01

hotfix

Para corrigir erros que foram lançados em produção (master).

hotfix/<Codigo_da_Issue>_<Nome_da_Issue>
Ex.: hotfix/12_Ajustar_Endpoint_de_Suplementos

task

Todas as alterações necessárias que não dizem respeito ao código em si devem ser feitas através de branches de task: Alterar dependências, adicionar arquivos de deploy...

task/<Codigo_da_Issue>_<Nome_da_Issue>
Ex.: task/20_Adicionar_Docker_Compose

Commits

Estrutura

Todo commit deverá possuir a seguinte estrutura:
<prefixo>: <descrição> Onde a descrição explica brevemente o que foi feito e o prefixo corresponde a uma das opções abaixo.

Prefixos

• feat: trabalho em uma feature nova;
• task: adição/alteração não relacionada a features;
• fix: correção de algum bug ou problema na aplicação;
• test: adição/edição dos testes de uma funcionalidade;
• docs: ajustes na documentação/swagger/README.

Exemplos

• feat: Criando tela de login
• fix: Corrigindo erro visual no botão de login
• task: Adicionando configuração do swagger para o endpoint de cadastro de suplementos

Merge Requests

TODO

Fluxo de Desenvolvimento

Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch develop antes de criar uma branch nova:

git pull origin develop

1. Crie uma branch para o seu trabalho seguindo o padrões de nomenclatura
2. Commite as alterações periodicamente seguindo o padrão de mensagens de commit
3. Crie os testes necessários ⚠
4. Atualize sua branch com as mudanças da develop e resolva os conflitos git pull origin develop
5. Abra o MR para a develop
6. Mova o Card da tarefa para In Review
7. Corrija/discuta os comentários feitos no MR
8. Realize o merge da tarefa quando três pessoas aprovarem

clone com HTTP vs SSH

Por limitações impostas pelo GETIT, as opções de clone (http, ssh) não estão disponíveis em todas as localizações, existem 3 redes possíveis de acesso aos repositórios:

• Eduroam
• AGES
• Externo

Aqui está a relação de o que funciona em qual rede:

Recomendação

Por conta dessa limitação, aqueles que forem usar um computador em uma rede externa e também na AGES, é recomendado usar a rede Eduroam e clonar via HTTP, assim não é necessário ficar alterando o origin do repositório.

Como alterar

Caso o git clone já foi feito e seja necessário mudar, para que não seja necessário apagar a pasta e possivelmente perder contribuições, é possível apenas trocar a url que o git está usando.

Para ver o link sendo usado atualmente, use o seguinte comando:

git remote -v

Ex:

Agora para alterar, use o seguinte comando, substituindo com o nome do remote e link para o repositório:

git remote set-url <remote> <https://tools.ages.pucrs.br/grupo/projeto.git>

Nesse caso ficaria dessa maneira:

git remote set-url origin https//tools.ages.pucrs.br/easy-choose/easychooseapi.git

Erro SSH: