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

É difícil saber com certeza porque 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 está tudo bem - solapar cada puxão. Ouça como isso soa. "Rebase cada puxada." soa errado se você usar pull requests ou similar. Você rebase em um pedido pull?

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

• Você pode extrair do upstream e do downstream. Algumas pessoas fazem muito do downstream, dos contribuidores, etc.

• Você pode trabalhar em recursos em estreita colaboração com outros desenvolvedores, aproveitando-os ou de uma ramificação de tópico compartilhada e ainda ocasionalmente sendo atualizada a partir do upstream. Se você sempre rebase, você acaba mudando o histórico compartilhado, sem mencionar os divertidos ciclos de conflito.

O Git foi projetado para uma equipe grande e altamente distribuída onde todos não puxam nem pressionam para um único repositório central. Então, o padrão faz sentido.

• Os desenvolvedores que não sabem quando está ok para fazer o rebase serão mesclados por padrão.
• Os desenvolvedores podem fazer o rebase quando quiserem.
• Os commiters que fazem muitos pulls e têm muita influência obtêm o padrão que melhor lhes convier.

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

Se você seguir todo o tópico, 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ê.

Muitas pessoas agora usam o Git de forma centralizada, onde todos em um pequeno grupo puxam apenas de um repositório central a montante e vão para o mesmo controle remoto. Esse cenário evita algumas situações em que um rebase não é bom, mas geralmente não as elimina.

Sugestão: Não faça uma política de alteração do padrão. Toda vez que você coloca o Git junto com um grande grupo de desenvolvedores, alguns dos desenvolvedores não entenderão tudo isso profundamente (inclusive eu). Eles vão ao Google, então, recebem conselhos sobre livros de culinária e depois se perguntam por que algumas coisas não funcionam, por exemplo. Por que git checkout --ours <path> obtém a versão incorreta do arquivo? Você sempre pode revisar seu ambiente local, criar apelidos, etc. para se adequar ao seu gosto.

Se você ler o git manpage para rebase, diz :

Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.

Eu acho que isso diz muito bem como uma razão para não usar o rebase, e muito menos fazê-lo automaticamente a cada puxada. Algumas pessoas consideram que o rebase é prejudicial . Talvez nunca devesse ter sido posta de modo algum, já que tudo o que parece fazer é embelezar a história, algo que não deveria ser necessário em nenhum SCM cujo trabalho essencial seja preservar a história.

Quando você diz "mantendo ... o histórico limpo", pense que está errado. Pode parecer melhor, mas para uma ferramenta projetada para manter o histórico de revisões, é muito mais limpo manter cada commit para que você possa ver o que aconteceu. Sanitizing a história depois é como polir a pátina de distância, fazendo um olhar antigo rico como uma reprodução brilhante: -)

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

Uma vez que sua cópia local / modificada é enviada para outro local, a criação de nova configuração atrapalhará essas cópias. Claro, você pode forçar a empurrar, 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 base 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 no tempo. Depois de rebases, é muito provável que commits mais antigos possam seguir mudanças mais recentes, tornando todo o histórico e seu fluxo mais difíceis de entender.

O grande motivo é provavelmente que o comportamento padrão deva "simplesmente funcionar" em repositórios públicos. Rebasing histórico que outras pessoas já se fundiram vai causar-lhes problemas. Eu sei que você está falando sobre o seu repositório privado, mas de um modo geral o git não sabe ou se importa com o que é privado ou público, então o padrão escolhido será o padrão para ambos.

Eu uso git pull --rebase bastante no meu repositório privado, mas mesmo assim há uma desvantagem em potencial, que é que a história do meu HEAD não reflete mais a árvore como eu realmente trabalhei nela.

Portanto, para um grande exemplo, suponha que eu sempre execute testes e garanta que eles passem antes de fazer um commit. 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. Contanto que as alterações não interfiram de alguma forma, e o código que eu puxei tenha sido testado, então presumivelmente ele passaria nos testes, mas não sabemos porque eu nunca tentei. Se a integração contínua é uma parte importante do seu fluxo de trabalho, então qualquer tipo de rebase em um repositório que está sendo CIed é preocupante.

Eu realmente não me importo com isso, mas isso incomoda algumas pessoas: eles prefeririam que sua história no git refletisse o código em que eles realmente trabalharam (ou talvez no momento em que eles o empurrassem, uma versão simplificada da verdade depois de algum uso de "correção").

Não sei se esse problema em particular é o motivo pelo qual o Linus optou por se mesclar em vez de rebaixar 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, eu tenho certeza que se trata do que ele acha que é um fluxo de trabalho adequado para pessoas que não querem pensar muito sobre isso (e especialmente aqueles que trabalham em público, em vez 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: -)