Processos de Desenvolvimento

Neste documento, vamos detalhar os processos essenciais para colaborar efetivamente no projeto usando o sistema de controle de versão Git.

Introdução ao Git

O Git é um sistema de controle de versão distribuído que permite que várias pessoas colaborem em um projeto, rastreiem as alterações, revertam para versões anteriores e gerenciem o desenvolvimento de software de maneira eficiente.

Git Workflow

Com base na imagem acima, é possível afirmar que ela representa o fluxo com base no git flow. Em outras palavras, a imagem segue a padronização desse fluxo. Portanto, as branches são identificadas por cores, as estrelas simbolizam os commits realizados em cada uma dessas branches, e os círculos com borda transparente representam a fusão dessas branches na branch develop.

PASSOS PARA SEGUIR:

• clonar o projeto
• checkout para a branch develop
• criar uma branch com o início feature-
• realizar as alterações nesta branch criada e depois realizar o commit
• checkout para a branch develop
• git pull na branch develop
• checkout para a branch criada
• merge desta branch para a develop

Conceitos Básicos

• Repositório: Um repositório Git é onde todo o histórico de um projeto é armazenado.

• Branches: São ramificações que permitem que você trabalhe em diferentes partes do projeto sem afetar o código principal.

  • Padrão de branch
    • <tipo>/<user story>-<apelido>
    • tipo: O tipo da tarefa, sendo uma das opções abaixo:
      • feat: Desenvolvimento de uma nova funcionalidade
      • fix: Correção de um bug na aplicação
    • user story: O número da user story. Exemplo: US01
    • apelido: Breve descrição do escopo da user story.
    • Exemplo: feat/US02-Criação página de login

• Commit: É uma "fotografia" do código em um determinado momento. Cada commit tem uma mensagem explicando as alterações feitas.

  • Exemplo: [feat] - Adicionando botões na tela de login

• Pull Request (ou Merge Request): É uma solicitação para incorporar suas alterações de uma branch para outra. Isso permite revisões antes de unir o código.

Padrões de commits

Commits semânticos são uma convenção simples para ser utilizada nas mensagens de commit. Essa convenção define um conjunto de regras para criar um histórico de commit explícito, facilitando você e sua equipe a entenderem quais alterações foram realizadas no trecho de código que foi commitado.

Essa identificação ocorre por meio de uma palavra chave que identifica se aquele commit realizado se trata de uma alteração de código, atualização de pacotes, documentação, alteração de visual, teste...

Tipo e descrição

O commit semântico possui os elementos estruturais abaixo (tipos), que informam a intenção do seu commit ao utilizador(a) de seu código.

• feat- Commits do tipo feat indicam que seu trecho de código está incluindo um novo recurso (se relaciona com o MINOR do versionamento semântico).

• fix - Commits do tipo fix indicam que seu trecho de código commitado está solucionando um problema (bug fix), (se relaciona com o PATCH do versionamento semântico).

• docs - Commits do tipo docs indicam que houveram mudanças na documentação, como por exemplo no Readme do seu repositório. (Não inclui alterações em código).

• test - Commits do tipo test são utilizados quando são realizadas alterações em testes, seja criando, alterando ou excluindo testes unitários. (Não inclui alterações em código)

• build - Commits do tipo build são utilizados quando são realizadas modificações em arquivos de build e dependências.

• perf - Commits do tipo perf servem para identificar quaisquer alterações de código que estejam relacionadas a performance.

• style - Commits do tipo style indicam que houveram alterações referentes a formatações de código, semicolons, trailing spaces, lint... (Não inclui alterações em código).

• refactor - Commits do tipo refactor referem-se a mudanças devido a refatorações que não alterem sua funcionalidade, como por exemplo, uma alteração no formato como é processada determinada parte da tela, mas que manteve a mesma funcionalidade, ou melhorias de performance devido a um code review.

• chore - Commits do tipo chore indicam atualizações de tarefas de build, configurações de administrador, pacotes... como por exemplo adicionar um pacote no gitignore. (Não inclui alterações em código)

• ci - Commits do tipo ci indicam mudanças relacionadas a integração contínua (continuous integration).

Recomendações

• Adicione um título consistente com o título do conteúdo.
• Recomendamos que na primeira linha deve ter no máximo 4 palavras.
• Para descrever com detalhes, usar a descrição do commit.

Criando sua Branch

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

Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:

git checkout -b <nomeDaBranch>

Assim que criar a branch, é necessário fazer um pushpara garantir que a mesma estará remota:

git push --set-upstream origin <nomeDaBranch>

Pronto! Agora você já pode começar a codar na sua Branch.

Criando seu Commit

Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de commit e push

Salvando Localmente

Para garantir que apenas o código necessário para funcionamento da tarefa será commitado, lembre-se de realizar o comando add apenas nos arquivos essenciais para a tarefa:

git add <nomeDoArquivo>

Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:

git commit -m '[feat] - Adicionando botões na tela de login'

Não hesite em realizar vários commits, assim podemos ter docuemntado e salvo vários estados do desenvolvimento

Salvando Remotamente

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

git push

Merge Requests

Depois de uma task ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:

Criando o Merge Request

A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request siga os seguintes passos:

1. Selecionar a branch de origem (sua branch de desenvolvimento);
2. Selecionar a branch de destino (branch develop);
3. Selecione Compare branches and continue
4. Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
5. Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
6. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um print (imagem) ou um gif exemplificando o uso (se considerar necessário);
7. Na seção Assignee, selecione Assign to me para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
8. Em Milestone selecione a Sprint em que a tarefa foi realizada;
9. Em Labelsselecione qual é o tipo de tarefa que foi realizada;
10. Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em Submit Merge Request.

Revisando o Merge Request

A revisão de merge request pode ser realizada por qualquer desenvolvedor, mas é preciso da aprovação de pelo menos um AGES III ou AGES IV para que a mesma seja incorporada na develop.

Na hora de revisar o Merge Request, entre na branch em sua máquina e teste a funcionalidade/bug/componente/tela de acordo com os critérios de aceitação establecidos pela equipe.

Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração.