Por que o git pull executa uma mesclagem, em vez de uma rebase, por padrão?

Considere a seguinte situação:

• Você tem um clone de um repositório git
• Você tem algumas confirmações locais (confirmações que ainda não foram enviadas a lugar algum)
• O repositório remoto possui novas confirmações que você ainda não reconciliou

Então, algo como isto:

Se você executar git pullcom as configurações padrão, obterá algo como isto:

Isso ocorre porque o git executou uma mesclagem.

Existe uma alternativa, no entanto. Você pode dizer ao pull para fazer uma nova rebase:

git pull --rebase

e você obterá isso:

Na minha opinião, a versão rebased tem inúmeras vantagens, principalmente centradas em manter o seu código e o histórico limpos, então estou um pouco impressionado com o fato de o git fazer a mesclagem por padrão. Sim, os hashes dos commits locais serão alterados, mas isso parece um preço pequeno a pagar pelo histórico mais simples que você recebe em troca.

De maneira alguma, estou sugerindo que, de alguma forma, isso é um padrão ruim ou errado. Estou tendo problemas para pensar nos motivos pelos quais a mesclagem pode ser preferida para o padrão. Temos alguma ideia de por que foi escolhido? Existem benefícios que o tornam mais adequado por padrão?

A principal motivação para essa pergunta é que minha empresa está tentando estabelecer alguns padrões de linha de base (espero, mais parecidos com diretrizes) sobre como organizamos e gerenciamos nossos repositórios para facilitar aos desenvolvedores a abordagem de um repositório com o qual não haviam trabalhado antes. Estou interessado em defender que normalmente devemos refazer esse tipo de situação (e provavelmente por recomendar que os desenvolvedores definam sua configuração global para refazer o rebote por padrão), mas se eu fosse contrário a isso, certamente perguntaria por que o rebase não é ' o padrão, se é tão bom. Então, eu estou querendo saber se há algo que estou faltando.

Foi sugerido que esta pergunta é uma duplicata de Por que tantos sites preferem "git rebase" ao "git merge"? ; no entanto, essa pergunta é um pouco o inverso desta. Ele discute os méritos de rebase sobre mesclagem, enquanto essa pergunta pergunta sobre os benefícios da mesclagem sobre rebase. As respostas refletem isso, concentrando-se nos problemas de mesclagem e nos benefícios da rebase.

É difícil saber ao certo por que a mesclagem é o padrão sem ouvir a pessoa que tomou essa decisão.

Aqui está uma teoria ...

O Git não pode presumir que não há problema em - refazer cada puxão. Ouça como isso soa. "Rebase cada puxão." Soa errado se você usar solicitações pull ou similares. Você se recuperaria de uma solicitação pull?

Em uma equipe que não está apenas usando o Git para controle centralizado de fontes ...

• Você pode puxar a montante e a jusante. Algumas pessoas fazem muito esforço de downstream, de colaboradores, etc.

• Você pode trabalhar em recursos em estreita colaboração com outros desenvolvedores, retirando deles ou de um ramo de tópico compartilhado e, ainda assim, ocasionalmente atualizado do upstream. Se você sempre se refaz, acaba alterando o histórico compartilhado, sem mencionar divertidos ciclos de conflito.

O Git foi projetado para uma equipe grande e altamente distribuída, na qual todo mundo não puxa nem empurra para um único repositório central. Portanto, o padrão faz sentido.

• Os desenvolvedores que não sabem quando está tudo bem com a rebase serão mesclados por padrão.
• Os desenvolvedores podem se refazer quando quiserem.
• Os colaboradores que fazem muitos puxões e têm muitos puxões obtêm o padrão que melhor lhes convém.

Para evidências de intenção, aqui está um link para um e-mail bem conhecido de Linus Torvalds com suas opiniões sobre quando eles não devem ser refeitos. Dri-devel git pull email

Se você seguir o tópico inteiro, poderá ver que um desenvolvedor está puxando de outro desenvolvedor e Linus está puxando de ambos. Ele deixa sua opinião bem clara. Como ele provavelmente decidiu os padrões do Git, isso pode explicar o porquê.

Agora, muitas pessoas usam o Git de maneira centralizada, onde todos em uma equipe pequena recorrem apenas a um repositório central upstream e passam para o mesmo controle remoto. Esse cenário evita algumas das situações em que uma rebase não é boa, mas geralmente não as elimina.

Sugestão: não faça uma política de alteração do padrão. Sempre que você juntar o Git a um grande grupo de desenvolvedores, alguns deles não entenderão o Git tão profundamente (inclusive eu). Eles irão para o Google, SO, obterão conselhos sobre livros de culinária e depois se perguntarão por que algumas coisas não funcionam, por exemplo, por que git checkout --ours <path>a versão incorreta do arquivo? Você sempre pode revisar seu ambiente local, criar aliases etc. para se adequar ao seu gosto.

Se você ler a página de manual do git para rebase, ele diz :

Reprovar (ou qualquer outra forma de reescrita) uma ramificação na qual outros se basearam é uma péssima idéia: qualquer pessoa a jusante é forçada a corrigir manualmente seu histórico. Esta seção explica como fazer a correção do ponto de vista do downstream. A solução real, no entanto, seria evitar rebasear o upstream em primeiro lugar.

Eu acho que isso diz o suficiente como uma razão para não usar rebase, e muito menos fazê-lo automaticamente a cada puxão. Algumas pessoas consideram a rebase prejudicial . Talvez nunca devesse ter sido colocado no git, pois tudo o que parece fazer é embelezar a história, algo que não deveria ser necessário em nenhum SCM cuja única tarefa essencial é preservar a história.

Quando você diz "manter ... a história limpa", pensa que está errado. Pode parecer melhor, mas para uma ferramenta projetada para manter o histórico de revisões, é muito mais limpo manter todas as confirmações para que você possa ver o que aconteceu. Limpar a história depois é como polir a pátina, fazendo com que uma antiguidade rica pareça uma reprodução brilhante :-)

Você está correto, supondo que você tenha apenas um repositório local / alterado. No entanto, considere a existência de um segundo PC local, por exemplo.

Depois que sua cópia local / modificada for enviada para outro lugar, o rebaseamento estragará essas cópias. Claro, você pode forçar o empurrão, mas isso rapidamente se torna complicado. O que acontece se um ou mais deles tiver outro commit completamente novo?

Como você pode ver, é muito situacional, mas a estratégia básica parece (para mim) muito mais prática em casos não especiais / de colaboração.

Uma segunda diferença: a estratégia de mesclagem manterá uma estrutura clara e consistente com o tempo. Após os rebotes, é muito provável que os commit mais antigos sigam mudanças mais recentes, dificultando a compreensão de todo o histórico e seu fluxo.

O grande motivo provavelmente é que o comportamento padrão deve "apenas funcionar" em repositórios públicos. Renascer a história que outras pessoas já fundiram vai causar-lhes problemas. Sei que você está falando sobre seu repositório particular, mas, de um modo geral, o git não sabe nem se importa com o que é público ou privado; portanto, o padrão escolhido será o padrão para ambos.

Eu uso git pull --rebasebastante em meu repositório particular, mas mesmo lá há uma desvantagem em potencial: a história do meu HEADnão reflete mais a árvore enquanto eu realmente trabalhava nela.

Portanto, para um grande exemplo, suponha que eu sempre execute testes e garanta que eles sejam aprovados antes de realizar uma confirmação. Isso tem menos relevância depois que eu faço um git pull --rebase, porque não é mais verdade que a árvore em cada um dos meus commits passou nos testes. Enquanto as alterações não interfere de forma alguma, e o código eu puxo foi testado, então, presumivelmente, ele iria passar os testes, mas nós não sabemos porque eu nunca tentei. Se a integração contínua for uma parte importante do seu fluxo de trabalho, qualquer tipo de rebase em um repositório que está sendo CI é problemático.

Eu realmente não me importo com isso, mas isso incomoda algumas pessoas: elas preferem que sua história no git reflita o código em que realmente trabalharam (ou talvez no momento em que a publicam, uma versão simplificada da verdade após algum uso) de "correção").

Não sei se esse problema em particular é o motivo pelo qual Linus optou por mesclar, em vez de se refazer por padrão. Pode haver outras desvantagens que não encontrei. Mas, como ele não tem vergonha de expressar sua opinião em código, tenho certeza de que tudo se resume ao que ele considera um fluxo de trabalho adequado para pessoas que não querem pensar muito sobre isso (e especialmente as que trabalham em público em vez disso). do que um repo privado). Evitar linhas paralelas no gráfico bonito, em favor de uma linha reta limpa que não represente o desenvolvimento paralelo como aconteceu, provavelmente não é sua principal prioridade, mesmo que seja sua :-)