Skip to content

GitLab

Last edited by Leonardo Vargas Soares
Page history

Git Workflow

Home Escopo Git Workflow Design/Mockups Configuração Arquitetura Gerência BD Qualidade

Sumário

Critério de aceite de Merge Requests (MR)

  • Branch testada;
  • Branch atualizada com a DEV;
  • Arquitetura Respeitada;
  • Código Limpo;
  • Boas práticas atendidas.

GitFlow

As atualizações da Developer serão feitos através de Pull Requests

git1

Opções de Ferramentas

GitKraken

  • Download do GitKraken.
    essa ferramenta facilita o uso do git através de uma interface intuitiva

GitBash (Windows)

Comandos básicos

  • clonar um repositório:
    git clone ADICIONAR URL
  • verificar o status do repositório:
    git status
  • CRIAR uma nova branch:
    git checkout -b <branch desejada>
  • ALTERNAR para uma branch:
    git checkout <branch desejada>
  • add arquivos alterados e dar um commit na branch:
    git commit -a -m 'adicionei um novo rodapé [issue 53]'
  • primeira vez a enviar os dados para o repositório.
    git push origin <branch desejada>
  • reenviar os dados para o repositório.
    git push
  • baixar os dados do repositório.
    git pull
  • fazer um merge em duas branch's.
    git merge <nome da branch>

Padrão para criação de branches

As branches criadas para desenvolvimento das funcionalidades pelas squads devem seguir o padrão e de acordo com seu objetivo:

Tags para os tipos de alterações:

  • feat - Nova funcionalidade
  • fix - Correção de defeito
  • docs - Alteração de documentação
  • style - Alterações visuais que não possuem alteração em codigo fonte
  • refactor - Reescrever um código para corrigir um bug ou adicionar uma nova funcionalidade
  • perf - Melhorar performance do sistema

feat/NUM_TASK-breve-descricao

Exemplo: feat/44-cadastro-usuario

Padrão para as mensagens de commit

Os commits deverão ter um padrão em suas mensagens para facilitar o entendimento da equipe no que foi desenvolvido:

"Descrição breve do commit - Autores (caso realizado em equipe)"

Exemplo: "Compare button done - Fulano, Ciclano"

OBS: Caso as atividades do commit tenham sido realizadas individualmente não é necessário informar os autores, porque a única pessoa envolvida será quem está subindo o commit.

Git Workflow

  • O Gitflow é um modelo alternativo de ramificação do Git que consiste no uso de ramificações de recursos (features) e várias ramificações primárias (main e development).

Fluxo_GIT

Branches

  • Cada branch relacionada à features será criada a partir da branch development. Nos tópicos abaixo será explicado as nomenclatura que serão utilizadas para o desenvolvimento.

Nomes

  • O nome da branch deve seguir o padrão feature/nome-da-feature, onde os nomes das features podem ser encontrados no Azure DevOps. Quando for necessário fazer alguma correção, o prefixo utilizado deverá ser fix/nome-da-feature.

Criação

  • Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch development antes de criar uma branch nova:
git pull origin development
  • Depois da execução desse comando é necessário criar a Branch, para isso, execute o seguinte comando:
git checkout -b <nomeDaBranch>

Commits

  • Após criar a sua branch de desenvolvimento, faça as alterações necessárias no código e commite as mudanças:

  • Para adicionar as mudanças é possível utilizar dois comandos:

  • O comando git add . , faz com que todas as alterações que foram feitas localmente sejam commitadas no repositório remoto.

git add .
  • O comando git add <nomeDoArquivo> , faz com que apenas as alterações do arquivo informado seja commitado no repositório remoto.
git add <nomeDoArquivo>
  • Após adicionar as alterações é necessário commitar elas usando o comando git commit-m"comentario-do-commit" 
git commit-m"comentario-do-commit"

  • O comentário deve descrever o que foi alterado no código.

  • Após, se for o primeiro commit dessa branch:

git push --set-upstream origin nome-da-branch
  • Caso contrário utilize:
git push

Importante: Sempre envie seus commits para o repositório remoto após realizar o seu trabalho, assim os outros desenvolvedores terão sempre as ultimas atualizações do código.

Merge Requests

  • Depois da sua issue 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 development.

  • Antes de abrir a MR certifique-se que, não irá ocorrer conflitos da sua branch com a development, para isso, siga os seguintes passos:

git checkout development
git pull
git checkout <nome-da-branch>
git merge development
  • Resolva os conflitos caso ocorra, após resolvê-los, envie as alterações para o Gitlab:

git push

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 development);
  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 gif exemplificando o uso (se considerar necessário);
  7. Na seção Assignee, marcar o responsável pela tarefa.
  8. Na seção Reviwers, marcar os AGES 3 (Eduardo Ballico, Leonardo Vargas Soares e Pedro Vieira).

Tutoriais