Rebasing é o processo de mover ou combinar uma sequência de commits para uma nova base commit. O Rebasing é mais útil e facilmente visualizado no contexto de um fluxo de trabalho de ramificação de recursos. O processo geral pode ser visualizado como o seguinte:

a partir de uma perspectiva de conteúdo, o rebasing está a mudar a base do seu ramo de um compromisso para outro, fazendo com que pareça que criou o seu ramo a partir de um commit diferente., Internamente, o Git realiza isso criando novos commits e aplicando-os à base especificada. É muito importante entender que, embora o ramo pareça o mesmo, é composto por commits inteiramente novos.

uso

a principal razão para o ajuste é manter um histórico de projeto linear. Por exemplo, considere uma situação em que o ramo mestre progrediu desde que você começou a trabalhar em um ramo de recurso., Você quer obter as últimas atualizações para o ramo mestre em seu ramo de recursos, mas você quer manter o histórico do seu ramo limpo para que pareça como se você estivesse trabalhando fora do ramo mestre mais recente. Isto dá o benefício posterior de uma fusão limpa do seu ramo de recurso de volta para o ramo mestre. Por que queremos manter uma “história limpa”? Os benefícios de ter uma história limpa tornam-se tangíveis ao realizar operações Git para investigar a introdução de uma regressão. Um cenário mais real seria:

1. um bug é identificado no ramo mestre., Uma característica que estava funcionando com sucesso está agora quebrada.
2. um desenvolvedor examina o histórico do ramo mestre usando git log por causa do” histórico limpo ” o desenvolvedor é rapidamente capaz de raciocinar sobre o histórico do projeto.
3. o desenvolvedor não pode identificar quando o bug foi introduzido usando git logde modo que o desenvolvedor executa umgit bisect.
4. Porque o histórico do git é limpo, git bisect tem um conjunto refinado de commits para comparar ao procurar a regressão., O desenvolvedor encontra rapidamente o commit que introduziu o bug e é capaz de agir de acordo.

Saiba mais sobre o git log e o Git bisect nas suas páginas de uso individual.

tem duas opções para integrar a sua funcionalidade no ramo principal: juntar-se directamente ou rebocar e depois juntar-se. A primeira opção resulta em uma junção de 3 vias e um commit de merge, enquanto a segunda resulta em uma junção de fast-forward e um histórico perfeitamente linear. O diagrama seguinte demonstra como o rebocar para o ramo mestre facilita uma junção rápida.,

Rebasing é uma forma comum de integrar as alterações a montante no seu repositório local. Puxar para cima as alterações com o git merge resulta em um commit de merge supérfluo cada vez que você quer ver como o projeto tem progredido. Por outro lado, rebater é como dizer: “Eu quero basear minhas mudanças no que todos já fizeram.”

não rebase o histórico público

como já discutimos anteriormente na história da reescrita, você nunca deve refazer commits uma vez que eles tenham sido empurrados para um repositório público., O ajuste substituiria os antigos commits por novos e pareceria que parte de seu histórico de projeto desapareceu abruptamente.

Git Rebase Standard vs Git Rebase Interactive

Git rebase interactive é quando git rebase aceita um argumento -- i. Isto significa “Interactive”.”Sem quaisquer argumentos, o comando funciona em modo padrão. Em ambos os casos, vamos assumir que criamos um ramo de recurso separado.,

 # Create a feature branch based off of master git checkout -b feature_branch master # Edit files git commit -a -m "Adds new feature" 

git rebase in standard mode will automatically take the commits in your current working branch and apply them to the head of the passed branch.

 git rebase 

Este automaticamente altera a base de ramificação atual para , que pode ser qualquer tipo de compromisso de referência (por exemplo, um ID, um ramo nome, uma marca, ou uma referência relativa à HEAD).

Runninggit rebase with the-i flag begins an interactive rebasing session., Em vez de mover cegamente todos os commits para a nova base, rebasing interativo lhe dá a oportunidade de alterar commits individuais no processo. Isto permite-lhe limpar o histórico removendo, dividindo e alterando uma série existente de commits. É como se Git commit --amend em esteróides.

 git rebase --interactive 

isto reinicia o ramo actual para mas usa uma sessão de ajuste interativo. Isto abre um editor onde poderá introduzir os comandos (descritos em baixo) para que cada envio seja reiniciado., Estes comandos determinam como os commits individuais serão transferidos para a nova base. Você também pode reordenar a lista de commit para alterar a ordem dos commits em si. Uma vez que você tenha especificado comandos para cada commit no rebase, o Git começará a reproduzir commits aplicando os comandos rebase. Os comandos de edição de ajuste são os seguintes:

comandos de ajuste adicionais

como detalhado na página de histórico de reescrita, o ajuste pode ser usado para alterar commits mais antigos e múltiplos, arquivos comprometidos e múltiplas mensagens., Embora estas sejam as aplicações mais comuns, git rebase também tem opções de comando adicionais que podem ser úteis em aplicações mais complexas.

• git rebase -- d significa que durante a reprodução o commit será descartado do bloco de commit combinado final.
• git rebase -- p deixa o commit como está. Ele não irá modificar a mensagem ou conteúdo do commit e ainda será um commit individual no histórico de ramificações.
• git rebase -- x durante a reprodução executa um programa de linha de comandos em cada persistência marcada., Um exemplo útil seria executar o conjunto de testes da sua base de código em commits específicos,que podem ajudar a identificar regressões durante um ajuste.

Recap

rebasing interactivo dá-lhe um controlo completo sobre a aparência do seu histórico de projecto. Isso proporciona muita liberdade para os desenvolvedores, pois permite que eles cometam uma história “confusa” enquanto eles estão focados em escrever código, em seguida, voltar e limpá-lo depois do fato.

a maioria dos desenvolvedores gosta de usar um ajuste interativo para polir um ramo de recursos antes de fundi-lo na base de código principal., Isso lhes dá a oportunidade de esmagar commits insignificantes, excluir commits obsoletos, e certificar-se de que tudo o resto está em ordem antes de se comprometer com a história “oficial” do projeto. Para todos os outros, parecerá que todo o recurso foi desenvolvido em uma única série de commits bem planejados.

O poder real do ajuste interativo pode ser visto na história do ramo mestre resultante. Para todos os outros, Parece que você é um desenvolvedor brilhante que implementou o novo recurso com a quantidade perfeita de commits da primeira vez., É assim que o rebasing interactivo pode manter a história de um projecto limpa e significativa.

opções de configuração

Existem algumas propriedades de ajuste que podem ser definidas usando git config. Estas opções irão alterar o ID

saída olhar e sentir.

• rebase.stat: um booleano que é definido como falso por padrão. A opção activa ou desactiva a visualização do conteúdo de diffstat visual que mostra o que mudou desde a última depuração.

• rebase.autoSquash:um valor booleano que activa ou desactiva o comportamento de--autosquash.,

• rebase.missingCommitsCheck: pode ser definido para vários valores que mudam o comportamento de ajuste em torno de commits em falta.,/tr>
  

  error

  Stops the rebase and prints removed commit warning messages

  ignore

  Set by default this ignores any missing commit warnings
  • rebase.instructionFormat: A git log format string that will be used for formatting interactive rebase display

  Advanced rebase application

  The command line argument --onto can be passed to git rebase., Quando no git rebase --onto modo de comando expande para:

    git rebase --onto 

  --onto comando permite uma forma mais poderosa ou alterar a base que permite passar específico de árbitros para ser o dicas de um rebase.
  suponhamos que temos um exemplo de recompra, com ramos como:

    o---o---o---o---o master \ o---o---o---o---o featureA \ o---o---o featureB 

  featureB é baseado em featureA, no entanto, percebemos featureB não é dependente de qualquer das alterações no featureA e só poderia ser ramificado mestre.

    git rebase --onto master featureA featureB 

  featureA é o ., master fica e featureB é referência para o que HEAD de irá apontar para. Os resultados são então:

    o---o---o featureB / o---o---o---o---o master \ o---o---o---o---o featureA 

  compreender os perigos de rebase

  uma advertência a considerar quando se trabalha com git Rebase é que os conflitos de junção podem tornar-se mais frequentes durante um fluxo de trabalho de rebase. Isto ocorre se você tiver um ramo de longa vida que se desviou do mestre., Eventualmente, você vai querer refazer contra o mestre e, nesse momento, ele pode conter muitos novos commits com os quais as mudanças de branch podem entrar em conflito. Isso é facilmente remediado, rebatendo seu ramo frequentemente contra o mestre, e fazendo com que os commits mais freqüentes. --continue e --abort argumentos de linha de comando pode ser transmitido para o git rebase para avançar ou redefinir o rebase ao lidar com os conflitos.

  um ajuste de caveat mais sério é perdido commits de reescrita de história interativa., A execução do rebase no modo interactivo e a execução de subcomités como o squash ou o drop irá remover os commits do registo imediato do seu branche. À primeira vista, isto pode parecer como se os commits tivessem desaparecido permanentemente. Usando git reflog estes commits podem ser restaurados e todo o rebase pode ser desfeito. Para mais informações sobre o uso de git reflog para encontrar commits perdidos, visite a nossa página de documentação do Git reflog.git Rebase itself is not seriously dangerous., Os casos de perigo real surgem quando se executa a reescrita da história, reescrevendo os rebases interativos e forçando a empurrar os resultados para um ramo remoto que é compartilhado por outros usuários. Este é um padrão que deve ser evitado, pois ele tem a capacidade de substituir o trabalho de outros usuários remotos quando eles puxam.

  a Recuperação do montante rebase

  Se outro usuário tiver realocados e força empurrado para o ramo que você está cometendo, uma git pull irá substituir qualquer compromete-se você tiver com base anterior do ramo com a sugestão de que era força empurrado., Felizmente, usando git reflog você pode obter o reflog do ramo remoto. No reflog do ramo remoto, você pode encontrar um árbitro antes que ele tenha sido rebatizado. Você pode então ajustar a sua ramificação contra essa remote ref usando a opção --onto, como discutido acima na seção de Aplicação de ajuste avançado.

  resumo

  neste artigo cobrimos git rebase utilização. Discutimos casos básicos e avançados de uso e exemplos mais avançados., Alguns pontos chave de discussão são:

  • git rebase standard vs interactive modes
  • git rebase configuration options
  • git rebase –onto
  • git rebase lost commits