No git, qual é a diferença entre mesclagem - squash e rebase?

Eu sou novo no git e estou tentando entender a diferença entre squash e rebase. Pelo que entendi, você executa uma abóbora ao fazer um rebase.

Ambos git merge --squashe git rebase --interactivepodem produzir um commit "esmagado".
Mas eles servem a propósitos diferentes.

• git merge --squash abranch

produzirá uma confirmação compactada na ramificação de destino, sem marcar nenhum relacionamento de mesclagem.
(Nota: ele não produz um commit imediatamente: você precisa de um adicional git commit -m "squash branch")
Isso é útil se você deseja descartar completamente o ramo de origem, saindo de (esquema retirado da pergunta do SO ):

 git checkout stable

      X                   stable
     /                   
a---b---c---d---e---f---g tmp

para:

git merge --squash tmp
git commit -m "squash tmp"

      X-------------------G stable
     /                   
a---b---c---d---e---f---g tmp

e excluindo tmpramificação.

Nota: git mergetem uma --commitopção , mas não pode ser usada com --squash. Nunca foi possível usar --commite --squashjuntos.
Desde o Git 2.22.1 (terceiro trimestre de 2019), essa incompatibilidade é explicitada:

Veja commit 1d14d0c (24 de maio de 2019) por Vishal Verma ( reloadbrain) .
^{(Incorporado por Junio ​​C Hamano - gitster- in commit 33f2790 , 25 de jul de 2019)}

merge: recusar --commitcom--squash

Anteriormente, quando --squashera fornecido ' option_commit', era silenciosamente descartado. Isso pode ter sido surpreendente para um usuário que tentou substituir o comportamento de não confirmação da squash usando --commitexplicitamente.

git/git builtin/merge.c#cmd_merge() agora inclui:

if (option_commit > 0)
    die(_("You cannot combine --squash with --commit."));

• git rebase --interactive

repete alguns ou todos os seus commits em uma nova base, permitindo que você esmague (ou mais recentemente "conserte", consulte esta pergunta SO ), indo diretamente para:

git checkout tmp
git rebase -i stable

      stable
      X-------------------G tmp
     /                     
a---b

Se você optar por esmagar todos os commits de tmp(mas, ao contrário de merge --squash, poderá repetir alguns e esmagar outros).

Então as diferenças são:

• squashnão toca na ramificação de origem ( tmpaqui) e cria um único commit onde você deseja.
• rebasepermite que você continue no mesmo ramo de origem (ainda tmp) com:
  • uma nova base
  • uma história mais limpa

Mesclar confirmações: retém todas as confirmações em sua ramificação e as intercala com confirmações na ramificação base

Merge Squash: retém as alterações, mas omite o indivíduo confirma o histórico

Rebase: move a ramificação inteira do recurso para começar na ponta da ramificação principal, incorporando efetivamente todas as novas confirmações no mestre

Mais aqui

O squash de mesclagem mescla uma árvore (uma sequência de confirmações) em uma única confirmação. Ou seja, esmaga todas as alterações feitas em n confirma em um único commit.

Rebasear é basear novamente, ou seja, escolher uma nova base (confirmação pai) para uma árvore. Talvez o termo mercurial para isso seja mais claro: eles chamam de transplante porque é exatamente isso: escolher um novo terreno (confirmação dos pais, raiz) para uma árvore.

Ao fazer uma nova reformulação interativa, você terá a opção de esmagar, selecionar, editar ou pular as confirmações que você irá refazer.

Espero que isso esteja claro!

Vamos começar pelo seguinte exemplo:

Agora temos 3 opções para mesclar alterações da ramificação do recurso na ramificação principal :

1. Confirmação de mesclagem Manterá
   todo o histórico de confirmações da ramificação de recursos e as moverá para a ramificação principal
   .

2. Rebase and mesclagem
   Anexará todo o histórico de confirmações da ramificação de recursos na frente da ramificação mestre
   . NÃO adicionará confirmação fictícia extra.

3. Squash e mesclagem
   Agrupam todas as confirmações de ramificação de recursos em uma confirmação e depois anexam-na na frente da ramificação principal
   .

Você pode encontrar abaixo como o ramo mestre cuidará de cada um deles.

Em todos os casos:
podemos excluir com segurança o ramo do recurso .