Skip to content

GitLab

Last edited by Leonardo Vargas Soares
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Git Workflow

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

Sumário

Critério de aceite de Merge Requests (MR)

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