Quando devo usar o git pull --rebase?

Conheço algumas pessoas que usam git pull --rebasepor padrão e outras que insistem em nunca usá-lo. Acredito entender a diferença entre mesclar e rebasear, mas estou tentando colocar isso no contexto de git pull. Trata-se de não querer ver muitas mensagens de confirmação de mesclagem ou existem outros problemas?

Você deve usar git pull --rebasequando

• suas alterações não merecem uma ramificação separada

De fato - por que não então? É mais claro e não impõe um agrupamento lógico em seus commits.

Ok, acho que precisa de alguns esclarecimentos. No Git, como você provavelmente sabe, você é incentivado a ramificar e mesclar. Sua ramificação local, na qual você puxa alterações, e ramificação remota são, na verdade, ramificações diferentes, e git pullé sobre como mesclá-las. É razoável, já que você pressiona com muita frequência e geralmente acumula várias alterações antes que elas constituam um recurso completo.

No entanto, às vezes - por qualquer motivo - você acha que seria realmente melhor se esses dois - remotos e locais - fossem um ramo. Como no SVN. É aqui que git pull --rebaseentra em jogo. Você não mescla mais - na verdade, confirma em cima da ramificação remota . É disso que se trata.

Se é perigoso ou não, é se você está tratando a filial local e remota como algo inseparável. Às vezes, é razoável (quando suas alterações são pequenas ou se você está no início de um desenvolvimento robusto, quando mudanças importantes são trazidas por pequenas confirmações). Às vezes não é (quando você normalmente cria outro ramo, mas você fica com preguiça de fazer isso). Mas essa é uma pergunta diferente.

Eu gostaria de fornecer uma perspectiva diferente sobre o que "git pull --rebase" realmente significa, porque às vezes parece se perder.

Se você já usou o Subversion (ou CVS), pode estar acostumado ao comportamento de "svn update". Se você tiver alterações a confirmar e a confirmação falhar porque as alterações foram feitas a montante, você "svn update". O Subversion prossegue mesclando alterações upstream com as suas, resultando potencialmente em conflitos.

O que o Subversion acabou de fazer foi essencialmente "pull --rebase". O ato de reformular suas alterações locais para que ele seja relativo à versão mais recente é a parte "rebasing" dela. Se você fez "svn diff" antes da falha na tentativa de confirmação e comparou o diff resultante com a saída de "svn diff" posteriormente, a diferença entre os dois diffs é o que a operação de rebasagem fez.

A principal diferença entre o Git e o Subversion, neste caso, é que no Subversion, "suas" alterações existem apenas como alterações não confirmadas na sua cópia de trabalho, enquanto no Git você tem confirmações reais localmente. Em outras palavras, no Git você bifurcou a história; sua história e a história a montante divergiram, mas você tem um ancestral em comum.

Na minha opinião, no caso normal de ter sua filial local simplesmente refletindo a filial upstream e desenvolvendo-a continuamente, a coisa certa a fazer é sempre "--rebase", porque é isso que você realmente está semanticamente fazendo . Você e outras pessoas estão cortando a história linear pretendida de um ramo. O fato de alguém ter empurrado um pouco antes da tentativa de empurrar é irrelevante e parece contraproducente para cada acidente de tempo resultar em mesclagens na história.

Se você realmente sente a necessidade de algo ser um ramo por qualquer motivo, essa é uma preocupação diferente na minha opinião. Mas, a menos que você tenha um desejo específico e ativo de representar suas alterações na forma de mesclagem, o comportamento padrão deve, na minha opinião, ser "git pull --rebase".

Por favor, considere outras pessoas que precisam observar e entender a história do seu projeto. Deseja que o histórico esteja repleto de centenas de fusões por todo o lado ou apenas algumas poucas fusões que representam fusões reais de esforços de desenvolvimento divergentes intencionais?

Talvez a melhor maneira de explicar isso seja com um exemplo:

1. Alice cria a ramificação de tópicos A e trabalha nela
2. Bob cria um ramo de tópico não relacionado B e trabalha nele
3. Alice faz git checkout master && git pull. O mestre já está atualizado.
4. Bob faz git checkout master && git pull. O mestre já está atualizado.
5. Alice faz git merge topic-branch-A
6. Bob faz git merge topic-branch-B
7. Bob faz git push origin masterantes de Alice
8. Alice aceita git push origin master, o que é rejeitado porque não é uma mesclagem de avanço rápido.
9. Alice examina o log de origem / mestre e vê que o commit não está relacionado ao dela.
10. Alice faz git pull --rebase origin master
11. O commit de mesclagem de Alice é desenrolado, o commit de Bob é puxado e o commit de Alice é aplicado após o commit de Bob.
12. Alice faz isso git push origin master, e todo mundo fica feliz por não precisar ler um commit inútil de mesclagem quando olhar para os logs no futuro.

Observe que o ramo específico que está sendo mesclado é irrelevante para o exemplo. O mestre neste exemplo poderia ser tão facilmente um ramo de lançamento ou um ramo de desenvolvimento. O ponto principal é que Alice e Bob estão mesclando simultaneamente suas ramificações locais em uma ramificação remota compartilhada.

Eu acho que você deve usar git pull --rebaseao colaborar com outras pessoas no mesmo ramo. Você está no seu trabalho → confirmar → trabalhar → ciclo de confirmação, e quando você decide enviar seu trabalho, seu envio é rejeitado, porque houve um trabalho paralelo no mesmo ramo. Neste ponto, eu sempre faço a pull --rebase. Não uso squash (para nivelar confirmações), mas me refiz para evitar as confirmações de mesclagem extras.

À medida que seu conhecimento sobre o Git aumenta, você se vê muito mais histórico do que com qualquer outro sistema de controle de versão que eu usei. Se você tem uma tonelada de pequenas confirmações de mesclagem, é fácil perder o foco da imagem maior que está acontecendo em sua história.

Na verdade, essa é a única vez que refizo (*) e o restante do meu fluxo de trabalho é baseado em mesclagem. Mas, enquanto seus confirmadores mais frequentes fizerem isso, a história parecerá muito melhor no final.

(*) Enquanto ministrava um curso Git, um aluno me prendeu por isso, pois também defendia o rebasamento de ramos de recursos em determinadas circunstâncias. E ele havia lido esta resposta;) Esse rebote também é possível, mas sempre deve estar de acordo com um sistema pré-combinado / acordado e, como tal, não deve "sempre" ser aplicado. E naquela época eu normalmente também não pull --rebase, o que é a questão;)

Eu não acho que haja uma razão para não usar pull --rebase- eu adicionei código ao Git especificamente para permitir que meu git pullcomando sempre se rebase contra confirmações upstream.

Ao analisar a história, nunca é interessante saber quando o cara / garota que trabalha no recurso parou para sincronizar. Pode ser útil para o cara / moça enquanto ele estiver fazendo isso, mas reflogé para isso. É só adicionar ruído para todos os outros.

Apenas lembra-te:

• pull = buscar + mesclar
• pull --rebase = busca + rebase

Portanto, escolha a maneira como você deseja lidar com seu ramo.

É melhor você saber a diferença entre mesclar e refazer :)

Eu acho que tudo se resume a uma preferência pessoal.

Deseja ocultar seus erros bobos antes de fazer alterações? Se assim git pull --rebasefor , é perfeito. Ele permite que você comprima mais tarde seus commits para alguns (ou um) commit. Se você tiver mesclagens no seu histórico (sem push), não é tão fácil fazer um git rebaseposterior.

Eu, pessoalmente, não me importo de publicar todos os meus erros bobos, por isso tenho a tendência de mesclar em vez de me refazer.

git pull --rebasepode ocultar uma reescrita do histórico de um colaborador git push --force. Eu recomendo usar git pull --rebase apenas se você souber que esqueceu de enviar seus commit antes que alguém faça o mesmo.

Se você não cometeu nada, mas seu espaço de trabalho não está limpo, pouco git stashantes de fazê-lo git pull. Dessa forma, você não reescreverá silenciosamente seu histórico (o que pode excluir silenciosamente parte do seu trabalho).