Git - é puxar ou rebase quando se trabalha em ramos com outras pessoas

Então, se eu estiver usando ramificações que são ramificações remotas (rastreadas), e eu quero pegar o último, eu ainda não estou claro se eu deveria estar fazendo git pull ou git rebase . Eu pensei que tinha lido que fazer git rebase ao trabalhar em uma ramificação com outros usuários, pode estragá-los quando eles puxam ou rebaixam. Isso é verdade? Todos nós deveríamos estar usando o git pull ?

0
adicionado editado
Visualizações: 1

5 Respostas

Se você quiser extrair a fonte sem afetar as ramificações remotas e sem nenhuma alteração na sua cópia local, é melhor usar o git pull.

Acredito que se você tem uma ramificação de trabalho para a qual você fez alterações, use git rebase para alterar a base dessa ramificação para ser o último mestre remoto, você manterá todas as mudanças de ramificação, mas a ramificação agora será ramificada do mestre localização, em vez de onde foi anteriormente ramificado.

0
adicionado

Git rebase é uma reescrita do histórico. Você nunca deve fazer isso em filiais que são "públicas" (ou seja, filiais que você compartilha com outras pessoas). Se alguém clonar o seu ramo e, em seguida, você rebase esse ramo - então eles não podem mais puxar/fundir as mudanças do seu ramo - eles terão que jogar fora o antigo e puxá-lo novamente.

Este artigo sobre software de empacotamento com o git é uma leitura muito interessante. É mais sobre o gerenciamento de distribuições de software, mas é bastante técnico e fala sobre como as agências podem ser usadas/gerenciadas/compartilhadas. Eles falam sobre quando rebaixar e quando puxar e quais são as várias consequências de cada um.

Em suma, ambos têm o seu lugar, mas você precisa realmente granjear a diferença.

0
adicionado
Em resumo, não rebase quaisquer commits que residam em outros repositórios.
adicionado o autor Ikke, fonte
O problema é se alguém puxar de um ramo que você rebase. Tudo bem se eu pego de A para local e depois rebase local , e outra pessoa extrai de A . Não é bom se eu pego de A , alguém puxa de local , então eu rebase local .
adicionado o autor Cameron Skinner, fonte
Isso é verdade, @Pat? No caso de um pull -rebase, você não está apenas reordenando seus commits locais para estar no topo do que você tirou? Já que esses foram commits locais, e ainda não foram publicados, como eles quebrarão alguém que tente puxar depois de eu puxar --rebase 'ed?
adicionado o autor Gabe Hollombe, fonte

git pull does a merge if you've got commits that aren't in the remote branch. git rebase rewrites any existing commits you have to be relative to the tip of the remote branch. They're similar in that they can both cause conflicts, but I think using git rebase if you can allows for smoother collaboration. During the rebase operation you can refine your commits so they look like they were newly applied to the latest revision of the remote branch. A merge is perhaps more appropriate for longer development cycles on a branch that have more history.

Como a maioria das outras coisas no git, há muita funcionalidade de sobreposição para acomodar diferentes estilos de trabalho.

0
adicionado

Git pull é uma combinação de 2 comandos

  • git fetch (sincroniza seu repositório local com as coisas mais recentes no controle remoto)
  • git merge (mescla as alterações do ramo distante, se houver, em sua filial de rastreamento local)

git rebase é apenas um equivalente grosseiro ao git merge. Não obtém nada remotamente. Na verdade, ele não faz uma mesclagem adequada, ele repete os commits do branch em que você está após os novos commits de um segundo branch.

Sua finalidade é principalmente permitir que você tenha um histórico mais limpo. Não é preciso muitas mesclagens por muitas pessoas antes que a história passada em gitk se torne terrivelmente parecida com espaguete.

A melhor explicação gráfica pode ser vista nos primeiros 2 gráficos aqui . Mas deixe-me explicar aqui com um exemplo.

Eu tenho dois ramos: mestre e mybranch. Quando estiver em mybranch, posso correr

git rebase master

e eu vou colocar qualquer coisa nova no master antes dos meus commits mais recentes em mybranch. Isso é perfeito, porque se eu agora mesclar ou rebase as coisas do mybranch no master, meus novos commits são adicionados linearmente logo após os commits mais recentes.

O problema a que você se refere acontece quando eu rebaso na direção "errada". Se eu acabei de obter o master mais recente (com novas alterações) e do master eu rebase assim (antes de sincronizar meu branch):

git rebase mybranch

O que acabei de fazer é que inseri minhas novas mudanças em algum lugar no passado do mestre. A linha principal de commits foi alterada. E devido à maneira como o git trabalha com IDs de commit, todos os commits (do master) que foram repetidos nas minhas novas alterações possuem novos ids.

Bem, é um pouco difícil de explicar apenas em palavras ... Espero que isso faz um pouco de sentido :-)

De qualquer forma, o meu próprio fluxo de trabalho é este:

  • 'git pull' novas alterações do remoto
  • mude para mybranch
  • 'git rebase master' para trazer as novas alterações do master no meu histórico de commits
  • voltar para o mestre
  • 'git merge mybranch', que só é rápido quando tudo em master também está em mybranch (evitando assim o problema de reordenação de commit em um branch público)
  • 'git push'

Uma última palavra. Eu recomendo fortemente o uso de rebase quando as diferenças são triviais (por exemplo, pessoas trabalhando em arquivos diferentes ou pelo menos linhas diferentes). Tem a pegadinha que eu tentei explicar lá em cima, mas isso contribui para uma história muito mais limpa.

Assim que houver conflitos significativos (por exemplo, um colega de trabalho tiver renomeado algo em vários arquivos), recomendo enfaticamente mesclar. Nesse caso, você será solicitado a resolver o conflito e, em seguida, enviar a resolução. No lado positivo, uma mesclagem é muito mais fácil de resolver quando há conflitos. O lado negativo é que sua história pode se tornar difícil de seguir se muitas pessoas se fundirem o tempo todo :-)

Boa sorte!

0
adicionado
Parece-me que você deveria ter dito: 'git mescla mybranch', que só é rápido quando tudo em master também está em mybranch (evitando assim o problema de reordenação de commit em um branch público)
adicionado o autor Bruno Bronosky, fonte
'git rebase mybranch' deveria definitivamente ler 'git merge mybranch'.
adicionado o autor James H, fonte

Confira os excelentes Gitcasts em Ramificação e fusão como bem como rebasing .

0
adicionado