Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • A api
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • arbitrium
  • api
  • Wiki
  • Gerenciamento
  • Configuracao
  • Git Rebase

Last edited by Matheus Vaccaro May 12, 2018
Page history

Git Rebase

Objetivo do git rebase é simples: mudar a referência do seu branch atual em função do branch de origem, ou permitir a edição de alguns commits mais antigos que o último commit. É possível por exemplo editar mensagens de commits antigas, mudar a ordem de commits, juntar vários commits em apenas um, etc.

No seu uso mais simples, o rebase serve para atualizar o branch atual. Vamos supor que temos um branch feature com 2 commits, e ele deriva do branch master. Para atualizarmos esse branch só precisamos:

  1. Não ter nenhum arquivo pendente para ser commitado.
  2. Estar no branch feature. Podemos trocar para esse branch com git checkout feature.
  3. Rodar o comando git rebase master para indicar que queremos atualizar o branch que estamos, comparando-o com o branch master.

Git então irá retroceder até o commit em comum entre ambos os branches, aplicar todos os commits do master, seguindo de todos os commits no branch atual. Um exemplo do resultado é mostrado na figura abaixo:

rebase

Alguns podem se perguntar: e porque não usar o git merge?

Podemos, mas ele iria poluir bastante (e de forma desnecessária) o histórico de commits.

Se fizermos o merge do master para feature ele iria copiar os commits C e D, para depois de F, além de gerar um commit indicando que foi realizado merge. Quando quisermos carregar as mudanças do branch feature para master (através de um merge), teremos N commits de merge (1 para cada vez que atualizamos nosso branch feature).

Por isso rebase é uma opção mais interessante. Ele mantém o histórico de commits mais limpos. Apenas duas coisas muito importantes sobre rebase:

  1. Faça rebase apenas em commits de branches onde você é o único desenvolvedor - Porque? Mudando a referência (hash do commit) de branches públicos (master, homologação, dev), quando outros desenvolvedores tentarem atualizar seu repositório, eles terão problemas para commitar.

  2. Dentro do seu branch, depois do rebase utilize o commando git push --force-with-lease para atualizar as referências na cópia do seu branch remoto. Isso irá verificar com segurança que você é a única pessoa utilizando aquele branch, e atualizar o remoto.

Fonte da imagem e leitura complementar:

https://medium.freecodecamp.org/git-rebase-and-the-golden-rule-explained-70715eccc372

Clone repository
  • Back
    • Detalhamento das Rotas de Activity
    • Especificacao de Rotas
  • Banco
    • Modelagem
  • Front
    • Definicao
    • Design
    • Tutorial VueJS
  • Gerenciamento
    • Configuracao
      • Definicao de Branches e Fluxo do Git
      • Git Rebase
      • Git Squash
    • Cronograma AGES 2018 1
    • Horarios do Time
    • Sprints
      • Dailies
      • Planning
      • Retrospectivas
  • Requisitos
    • Regras de Negocio
View All Pages