As atualizações foram rejeitadas porque a dica do seu ramo atual está atrasada

Eu sou novo no Git, então fique à vontade para me tratar como um novato.

Nosso fluxo de trabalho é tal. Temos um ramo chamado devque eu posso alcançar origin/dev. Quando fazemos alterações, criamos uma ramificação do dev:

git checkout -b FixForBug origem / dev

Agora eu tenho um ramo chamado FixForBugque está rastreando (acho que é a palavra certa) origin/dev. Assim, se eu fizer git pullisso, trará novas mudanças, das origin/devquais é ótimo. Agora, quando terminei minha correção, levo para um ramo remoto chamado a mesma coisa.

Primeiro, retiro todas as alterações origin/deve refiz:

git pull --rebase

Em seguida, envio as alterações para uma ramificação remota com o mesmo nome:

origem do push do git FixForBug

Agora, há uma ramificação no servidor remoto e posso criar uma solicitação de recebimento para que essa alteração seja aprovada e mesclada novamente à ramificação dev. Eu nunca empurro nada para origin/devmim mesma. Suponho que este é um fluxo de trabalho bastante comum.

A primeira vez que faço um git push, ele funciona bem e cria a ramificação remota. No entanto, se eu pressionar pela segunda vez (digamos que durante a revisão de código, alguém aponte um problema), recebo o seguinte erro:

erro: falha ao enviar algumas referências à dica ' https://github.limeade.info/Limeade/product.git ': as atualizações foram rejeitadas porque a dica do seu ramo atual está atrás da dica: sua contraparte remota. Integre as alterações remotas (por exemplo, dica: 'git pull ...') antes de pressionar novamente. dica: Consulte a 'Nota sobre avanço rápido' em 'git push --help' para obter detalhes.

No entanto, se eu fizer um git status, diz que estou à frente de origin/dev1 commit (o que faz sentido) e se eu seguir a dica e executar git pull, ele diz que tudo está atualizado. Eu acho que isso é porque estou empurrando para um ramo diferente do meu ramo upstream. Eu posso corrigir esse problema executando:

git push -f origin FixForBug

Nesse caso, ele enviará as alterações para a ramificação remota, dizendo (atualização forçada) e tudo parecerá bom na ramificação remota.

Minhas perguntas:

Por que é -fnecessário neste cenário? Geralmente, quando você está forçando algo, é porque você estava fazendo algo errado ou pelo menos contra a prática padrão. Estou bem em fazer isso, ou isso atrapalhará algo no ramo remoto ou criará um aborrecimento para quem tiver que eventualmente mesclar minhas coisas no dev?

Na verdade, -f é necessário por causa do rebase. Sempre que você faz uma nova reformulação, é necessário fazer um push forçado, porque a ramificação remota não pode ser encaminhada rapidamente para sua confirmação. Você sempre desejaria ter um puxão antes de empurrar, mas se não gostar de forçar o push para dominar ou dev, pode criar um novo ramo para empurrar e depois mesclar ou criar um PR .

Para garantir que o ramo local FixForBug não esteja à frente do ramo remoto FixForBug, puxe e mescle as alterações antes de enviar.

git pull origin FixForBug
git push origin FixForBug

Se você quiser evitar ter que usar -f, pode usar apenas

git pull

ao invés de

git pull --rebase

O non-rebase buscará as alterações origin/deve as mesclará em sua FixForBugramificação. Então, você poderá executar

git push origin FixForBug

sem usar -f.

the tip of your current branch is behind its remote counterpartsignifica que houve alterações na ramificação remota que você não possui localmente. e o git diz para você importar novas alterações REMOTEe mesclá-las ao seu código e depois pushao controle remoto.

Você pode usar este comando para forçar alterações no servidor com repo local ().

git push -f origin master

com a -ftag, você substituirá o Remote Brach codeseu código.

O comando que eu usei com o Azure DevOps quando encontrei a mensagem "as atualizações foram rejeitadas porque a ponta da sua filial atual está atrasada" era / é este comando:

mestre de origem do git pull

(ou pode começar com uma nova pasta e executar um clone) ..

Esta resposta não aborda a pergunta feita, especificamente, o Keif respondeu isso acima, mas responde ao texto do título / título da pergunta e essa será uma pergunta comum para os usuários do Azure DevOps.

Eu observei o comentário: "Você sempre quer ter certeza de fazer um puxão antes de pressionar" na resposta de Keif acima!

Eu também usei a ferramenta Git Gui, além da ferramenta de linha de comando Git.

(Eu não tinha certeza de como fazer o equivalente ao comando da linha de comando "git pull origin master" dentro do Git Gui, então estou de volta à linha de comando para fazer isso).

Um diagrama que mostra vários comandos git para várias ações que você pode querer executar é este:

Isto somente aconteceu para mim.

• Ontem fiz um pedido pull ao nosso mestre.
• Meu colega estava revisando hoje e viu que estava fora de sincronia com o ramo principal; portanto, com a intenção de me ajudar, ele fundiu o mestre ao meu ramo.
• Eu não sabia que ele fez isso.
• Então eu mesclei o mestre localmente, tentei empurrá-lo, mas ele falhou. Por quê? Como meu colega de fusão com o mestre criou um commit extra que eu não tinha localmente !

Solução: Pull pela minha própria filial assim que eu conseguir esse extra cometer. Em seguida, empurre -o de volta para o meu ramo remoto.

literalmente o que eu fiz no meu ramo foi:

git pull
git push

Foi assim que resolvi meu problema

Vamos supor que o ramo upstream seja aquele que você retirou e a origem é seu repositório e você deseja enviar um MR / PR para o ramo upstream.

Você já tem digamos cerca de 4 confirmações e está recebendo Updates were rejected because the tip of your current branch is behind.

Aqui está o que eu fiz

Primeiro, esmague todos os seus 4 commits

git rebase -i HEAD~4

Você obterá uma lista de confirmações com pick escrito. (aberto em um editor)

exemplo

pick fda59df commit 1
pick x536897 commit 2
pick c01a668 commit 3
pick c011a77 commit 4

para

pick fda59df commit 1
squash x536897 commit 2
squash c01a668 commit 3
squash c011a77 commit 4

Depois disso, você pode salvar seu commit combinado

Próximo

Você precisará esconder seu commit

Aqui está como

git reset --soft HEAD~1
git stash

agora rebase com seu ramo upstream

git fetch upstream beta && git rebase upstream/beta

Agora pop seu commit oculto

git stash pop

comprometer essas mudanças e empurrá-los

git add -A
git commit -m "[foo] - foobar commit"
git push origin fix/#123 -f

Deve ser por causa do commit estar à frente do seu push atual.

1) git pull origin "nome do ramo que você deseja enviar"

2) git rebase

se o git rebase for bem-sucedido, tudo bem. Caso contrário, você resolverá todos os conflitos de mesclagem localmente e continuará até que a recuperação com o controle remoto seja bem-sucedida.

3) git rebase --continuar

Eu tive esse problema ao tentar enviar após uma nova atualização através do Visual Studio Code, meu problema foi resolvido apenas copiando o comando da janela de saída git e executando-o na janela do terminal no Visual Studio Code.

No meu caso, o comando era algo como:

git push origin NameOfMyBranch:NameOfMyBranch