Como refazer a ramificação local com o mestre remoto


934

Eu tenho um projeto clonado de uma ramificação mestre do repositório remoto remote_repo. Crio um novo ramo e me comprometo com esse ramo. Outros programadores passaram para remote_repoa ramificação principal.

Agora preciso refazer minha ramificação RB no remote_repomestre.

Como fazer isso? Quais comandos para digitar em um terminal?


14
Para mim, essa pergunta é ambígua, pois "with" pode significar rebasear em qualquer direção. Observando as respostas, vejo que a intenção é refazer sua ramificação no mestre remoto, e não o contrário. Menciono isso no caso de alguém seguir uma resposta abaixo e obter o contrário do que deseja.
Glenn Lawrence

8
@GlennLawrence Acho que é melhor editar a pergunta original do que adicionar um comentário. Isso também é incentivado pelo stackoverflow. Além disso, o rebasing master no RB provavelmente falhará de qualquer maneira, porque o RB depende do histórico do master.
Daniel kullmann # 24/17

Respostas:


1245

Primeiro, busque o novo mestre no repositório upstream, depois refaça sua ramificação de trabalho com isso:

git fetch origin            # Updates origin/master
git rebase origin/master    # Rebases current branch onto origin/master

Atualização : Veja a resposta de Paul Draper para uma maneira mais concisa de fazer o mesmo - as versões recentes do Git fornecem uma maneira mais simples de executar o equivalente aos dois comandos acima.


16
esta é a única resposta que realmente faz o que foi perguntado
kayaker243

5
@ kayaker243 Não, é o mesmo que a resposta de Paul Drapers, mas de forma longa, eu acho.
Erik

7
@erik Observe que Paul Draper escreveu sua resposta cerca de meio ano após o comentário de kayaker243 (e quase dois anos após essa resposta).
Frerich Raabe 11/11

3
Recebo o seguinte: Your branch and 'origin/b1' have diverged, # and have 3 and 2 different commits each, respectively.Parece que git pullé necessário outro . Isso está correto ou estou faltando alguma coisa aqui?
Dror

2
@RGC Não, git rebase masternão fará o mesmo trabalho que o segundo comando ( git rebase origin/master) desde mastere origin/masterpode apontar para confirmações diferentes (especialmente considerando que o primeiro comando foi git fetch origin, que pode ser modificado origin/master).
Frerich Raabe 29/04

816
git pull --rebase origin master
# where --rebase[=(false|true|merges|preserve|interactive)]

19
(Equivalente à resposta de Frerich)
Paul Draper

12
isso não é um pouco diferente da resposta de Frerich, na medida em que isso comprometerá alterações do mestre de origem no mestre local, enquanto a resposta de Frerich deixa o mestre local intocado? (pull vs. fetch) #
1955 Jimmy Huch

7
Não, na resposta de Frerich, o rebase modifica o mestre local. Um --rebase puxar é a mesma coisa que uma busca seguido por uma alteração de base
argumentum ad hominem

9
Para sua informação, você pode fazer rebotes interativos comgit pull --rebase=interactive origin master
emmby

14
@adhominem - verifiquei a documentação do git-pull e não consigo ver nada que suporte a alegação de que o mestre local está modificado. Se eu estiver em um ramo nomeado deve executado git pull --rebase origin master, apenas o ramo devserá modificado, não master. A --rebasedocumentação do sinalizador indica que ele tenta rebase the current branch on top of the upstream branch after fetchinge nada sobre a modificação de ramificações de rastreamento local.
Reintegrar Monica 2331977

227

Depois de confirmar as alterações em sua filial, faça o checkout mastere obtenha-as para obter as alterações mais recentes do repositório:

git checkout master
git pull origin master

Em seguida, efetue o checkout de sua filial e refaça as alterações em master:

git checkout RB
git rebase master

... ou últimos dois comandos em uma linha:

git rebase master RB

Ao tentar voltar origin/RB, você provavelmente receberá um erro; se você é o único a trabalhar RB, pode forçar o push:

git push --force origin RB

... ou da seguinte forma, se você tiver configurado o git adequadamente:

git push -f

4
ao tentar retornar à origem / RB, você provavelmente receberá um erro. Se você é o único que trabalha no RB, pode usar o RB de origem push -force. fonte: stackoverflow.com/questions/8939977/...
Joey Baruch

1
Ah .... eu tenho exatamente isso. meu "RB" foi reformulado corretamente, mas recebo erros intermináveis ​​ao tentar enviá-lo após o rebase. Além do push - RB de origem de força - existe uma maneira "melhor" (não forçada) de fazer isso? Eu apenas tento entender a percepção dos gits aqui - e falho.
Motti Shneor

2
@MottiShneor Não, não há uma maneira agradável. Se alguém empurrar para o ramo nesse meio tempo, suas alterações serão perdidas! Se você quer ser legal com o histórico de confirmação do git, você deve mesclar o master em seu ramo, o que é seguro (você pode git pushprescindir -f).
Daniel kullmann # 24/17

110

Nota: Se você já possui amplo conhecimento sobre rebase, use abaixo de um liner para rebase rápido. Solução: Supondo que você esteja no seu ramo de trabalho e você seja a única pessoa que trabalha nele.

git fetch && git rebase origin/master

Resolva quaisquer conflitos, teste seu código, confirme e envie novas alterações para a filial remota.

                            ~:   For noobs   :~

As etapas a seguir podem ajudar quem é novo git rebasee deseja fazê-lo sem problemas

Etapa 1: Supondo que não haja confirmações e alterações a serem feitas no YourBranch neste momento. Estamos visitando o YourBranch.

git checkout YourBranch
git pull --rebase

O que aconteceu? Puxa todas as alterações feitas por outros desenvolvedores que trabalham em sua filial e refaz suas alterações sobre ela.

Etapa 2: resolva todos os conflitos que apresentar.

Etapa 3:

git checkout master
git pull --rebase

O que aconteceu? Puxa todas as alterações mais recentes do mestre remoto e refaz o mestre local no mestre remoto. Eu sempre mantenho o mestre remoto limpo e o lançamento pronto! E prefira apenas trabalhar no mestre ou nas ramificações localmente. Eu recomendo fazer isso até você obter uma mão nas alterações ou confirmações do git. Nota: Esta etapa não é necessária se você não estiver mantendo o mestre local; em vez disso, é possível buscar e refazer o mestre remoto diretamente na ramificação local. Como eu mencionei na única etapa no início.

Etapa 4: resolva todos os conflitos que apresentar.

Etapa 5:

git checkout YourBranch
git rebase master

O que aconteceu? Rebase no master acontece

Etapa 6: resolva quaisquer conflitos, se houver conflitos. Use git rebase --continuepara continuar a rebase depois de adicionar os conflitos resolvidos. A qualquer momento, você pode usar git rebase --abortpara abortar o rebase.

Etapa 7:

git push --force-with-lease 

O que aconteceu? Enviar alterações para o YourBranch remoto. --force-with-leasegarantirá se há outras alterações recebidas do YourBranch por outros desenvolvedores enquanto você refaz o processo. Isso é super útil, e não forçado. Caso haja alguma alteração recebida, busque-a para atualizar o YourBranch local antes de enviar as alterações.

Por que preciso fazer alterações? Para reescrever a mensagem de confirmação no YourBranch remoto após uma nova reformulação adequada ou se houver algum conflito resolvido? Em seguida, é necessário enviar as alterações que você resolveu no repositório local para o repositório remoto do YourBranch

Yahoooo ...! Você terminou com êxito o rebase.

Você também pode estar pensando em fazer:

git checkout master
git merge YourBranch

Quando e porque? Mesclar sua filial no master, se isso for feito com alterações feitas por você e por outros co-desenvolvedores. O que torna o YourBranch atualizado com o mestre quando você deseja trabalhar no mesmo ramo posteriormente.

                            ~:   (๑ơ ₃ ơ)♥ rebase   :~

O que é isso para: "Puxa todas as alterações mais recentes do mestre e rebase do mestre no mestre mais recente.". Rebase mestre no mestre? Você não precisa apenas puxar o mestre mais recente?
John John

@JohnLittle Obrigado por apontar. Quero dizer Pulls latest changes from remote master to local master. I always prefer keeping remote master clean and release ready always!. Vou atualizar minha descrição.
bh4r4th

21

Passo 1:

git fetch origin

Passo 2:

git rebase origin/master

Etapa 3: (Corrija se houver algum conflito)

git add .

Passo 4:

git rebase --continue

Etapa 5:

git push --force

5
Nenhuma explicação sobre em qual filial iniciar. Não é uma boa resposta.
Karl Morrison

12

1. Atualize o mestre primeiro ...

git checkout [master branch]
git pull [master branch]

2.Agora rebase fonte-ramo com ramo principal

git checkout [source branch]
git rebase [master branch]
git pull [source branch] (remote/source branch)
git push [source branch]

Se a ramificação de origem ainda não existir no controle remoto, faça:

git push -u origin [source branch]

"et voila ..."


Eu gosto da natureza passo a passo desta resposta. Ajuda a quebrar o que exatamente está acontecendo.
Dave Liu

6

git fetch origin master:master puxa a versão mais recente do master sem precisar verificar.

Então, tudo que você precisa é:

git fetch origin master:master && git rebase master 👌


Não git fetchatualiza o mestre sem precisar verificar também? Exceto que as atualizações git fetchnão estão git mergecorretas? Portanto, se fizermos o checkout, masterele não terá as atualizações mais recentes. Então não é mais curto para fazer enquanto no ramo de funcionalidade, git fetchentão git rebase origin/master? Não podemos fazer git rebase masterisso, porque isso tentará se recuperar do masterespaço de trabalho. Precisamos origin/mastersair do imerso, mas sentado no local.
Noitidart 11/01/19
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.