Documentação de Negócio

Documentação Técnica

Sumário

• Documentação de Negócio
• Documentação Técnica
• Sumário
• Processo
  • Git Flow
• 🌱 Padrões de Branch e Commit
  • 📌 Commits
    • 🔹 Tipos de commit
    • Exemplos
    • 🔹 Regras
  • 📌 Branches
    • Exemplos
    • 🔹 Regras
  • 🚨 Merge Requests
• 📖 Tutoriais
  • Manter suas branches atualizadas
  • Criando novas branches
  • Adicionando mudanças ao desenvolvimento
    • Salvando Localmente
    • Salvando Remotamente
  • Abrindo um Merge Request (MR)
  • Revisando o Merge Request

Processo

Esta sessão visa documentar os processos de desenvolvimento utilizados no projeto Creative Flow.

Git Flow

GitFlow é o processo de contribuição para os projetos utilizando a ferramenta de gerenciamento de versões Git. As definições descritas serão utilizadas nos repositórios do Frontend e Backend do projeto.

🌱 Padrões de Branch e Commit

📌 Commits

Estamos utilizando um padrão inspirado no Conventional Commits, que é baseado em @commitlint/config-conventional.

• Os commits devem seguir <tipo>(<escopo>): <mensagem>;
• Escopo é a abreviação da user story com dois números, separados por hífen (ex. us-1-1);
• Mensagens de commit não podem ultrapassar 72 caracteres e devem ser em inglês e escritas no pretérito perfeito;
• Tipo é conforme a tabela abaixo:

🔹 Tipos de commit

Exemplos

• feat(us-2-1): Did something
• fix(no-us): Re-did that thing

🔹 Regras

• O tipo do commit deve estar em letras minúsculas.
• O identificador da us deve estar entre parênteses, em letras minúsculas.
• A descrição deve ser breve e começar com letra maiúscula.

📌 Branches

As branches para desenvolvimento devem ser feitas a partir da develop. Os nomes de branch devem seguir <escopo>/<descrição>, onde a descrição deve ser breve, conter apenas letras minúsculas e utilizar hífens no lugar de espaços. Escopo é definido conforme dito anteriormente.

Exemplos

• us-2-4/issue-naming
• no-us/writing-something-here

🔹 Regras

• us-X-Y/description → Para tarefas relacionadas a uma User Story (US). Os números X e Y representam a ID da US.
• no-us/description → Para alterações sem uma US específica.
• Utilize hífens (-) para separar palavras na descrição da branch.
• A descrição deve ser escrita em inglês e em letras minúsculas.
• A descrição deve ser curta e clara.

🚨 Merge Requests

O título do merge request deve seguir o mesmo formato dos commits acima. Os MRs precisam passar todos os jobs no pipeline e, após isso, podem ser mergeados por um AGES III ou IV. É obrigatório submeter o MR no formato definido pelo template.

📖 Tutoriais

Manter suas branches atualizadas

Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar a seguinte sequência de comandos:

git fetch upsteram
git rebase upsteram dev

Criando novas branches

Para criar uma nova branch, use a seguinte sequência de comandos:

Todas as branches devem ser originadas da dev.

git checkout dev

Use isto para garantir que sua dev (local) está atualizada

git pull origin dev

Agora, devemos criar a branch no seu repositório local

git checkout -b <Nome da branch no formato padrão>

Por fim, é necessáiro fazer um push para garantir que a branch estará no remoto

git push --set-upstream origin <Nome da branch no formato padrão>

Pronto! Agora você já pode começar a programar na sua branch.

Adicionando mudanças ao desenvolvimento

Salvando Localmente

Para realizar um commit, utilize:

git add <Nome do arquivo com extensão>

Ou, para múltiplos arquivos pode-se utilizar:

git add <arquivo 1> <arquivo 2> ...

Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit:

git commit -m "<Mensagem de commit no formato padrão>"

Salvando Remotamente

Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o GitLab. Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando push:

git push

Abrindo um Merge Request (MR)

Após a realização do desenvolvimento de uma tarefa e ela estiver de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de development, então deve-se abrir um Merge Request.

Para criar o Merge Request devem ser seguidos os seguintes passos:

1. Selecionar a branch de origem (branch de desenvolvimento) e branch (branch de development) de destino.

2. Selecionar Compare branch and continue

3. No campo Title, manter o mesmo formato de padrão do commit, com a descrição sendo um resumo do que foi feito em todos os commits da tarefa.

4. No campo Description, utilizar o template disponível e preenchê-lo com as informações necessárias.

5. Em Asignee, selecione Assign to me para que você fique registrado como responsável pelo desenvolvimento daquela tarefa.

6. Em Reviewer, selecione o AGES III responsável pela sua Squad para que ele seja notificado pelo gitlab como responsável pela revisão.

7. Em Labels adicione o tipo da tarefa que foi realizado.

8. Assegure-se que ambas as caixas Delete source branch when merge request is accepted. e Squash commits when merge request is accepted. estão marcadas.

9. Revise se os arquivos estão corretos e clique em Submit Merge Request.

Revisando o Merge Request

Todo Merge Request deve ter pelo menos duas aprovações, sendo uma delas obrigatoriamente de um AGES III.

O merge deve ser feito com a estratégia squash-commits e as branches devem ser excluídas após o merge para a branch de destino.