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 na sua branch de desenvolvimento:

git fetch origin
git merge origin/dev --no-edit

Se não houverem conflitos, sua branch está atualizada!

Existe uma possibilidade de que hajam conflitos (o git avisará sobre isso no terminal), nesse caso você deve resolver os conlfitos manualmente. Após resolver os conflitos, faça a seguinte sequência de comandos:

git add <arquivo>
git rebase --continue

Repita o processo de resolução de conflitos, add e rebase--continue até que não hajam conflitos.

Por fim, use:

git push

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.