O que é essa mensagem de aviso do Git ao enviar alterações para um repository remoto?

A descrição é um pouco concisa. Eu simplesmente adicionei um arquivo na minha filial master local e o empurrei de volta para um repository remoto. Alguma ideia de por que isso está chegando?

 aviso: atualizando o aviso de ramificação atual: Atualizar a ramificação atualmente retirada pode causar confusão, aviso: como o índice e a tree de trabalho não refletem as alterações que estão no HEAD.  aviso: Como resultado, você pode ver as alterações que você acabou de enviar para ele warning: reverted quando você executar 'git diff', e você pode querer aviso: para executar 'git reset --hard' antes de começar a trabalhar para recuperar .  aviso: aviso: Você pode definir a variável de configuração 'receive.denyCurrentBranch' para alertar: 'refuse' no repository remoto para proibir o push em seu aviso: branch atual.  aviso: para permitir o envio para o ramo atual, você pode configurá-lo para 'ignorar';  aviso: mas isso não é recomendado a menos que você tenha organizado a atualização de seu aviso de trabalho: tree para corresponder ao que você empurrou de alguma outra forma.  aviso: aviso: Para silenciar esta mensagem, você pode configurá-la para "avisar".  aviso: aviso: Observe que o padrão será alterado em uma versão futura do aviso git: para recusar a atualização da ramificação atual, a menos que você tenha o aviso: variável de configuração definida como 'ignore' ou 'warn'. 

Na verdade, isso significa exatamente o que ele diz: alguém está trabalhando no repository para o qual você está pressionando, e que alguém atualmente checou exatamente o mesmo ramo para o qual você está pressionando.

Isso é muito confuso, porque agora ele acha que checou a versão mais recente da ramificação, quando, na verdade, você acabou de atualizar a ramificação para uma versão mais nova. Então, quando ele agora executar git commit , o commit dele essencialmente reverterá todos os commits que você acabou de enviar. E quando ele corre git diff ele verá o oposto de tudo que você acabou de empurrar, mesmo que ele talvez nem tenha mudado nada.

Por esse motivo, geralmente é considerado uma prática ruim passar para um repository não-nu; você só deve empurrar para repositorys nus, ou seja, repositorys que não possuem uma cópia de trabalho anexada. No mínimo, você deve se certificar de não enviar para a ramificação atualmente em check-out, mas geralmente você não deve simplesmente empurrar seu código para o repository de outra pessoa, você deve pedir a eles para puxar de você.

Em alguns casos especiais, como quando você está veiculando um site a partir de um repository Git e deseja atualizar o site, basta fazer um push para a ramificação atualmente registrada, mas, nesse caso, é necessário garantir que você tem um gancho instalado que realmente atualiza a cópia de trabalho com check-out, caso contrário seu site nunca será atualizado.

Se ninguém está trabalhando nesse repository remoto não-nu, então deve ser possível empurrar para um ramo de check-out.

Mas, para ficar mais seguro nessa operação, você pode agora (com o Git 2.3.0, fevereiro de 2015) fazer nesse repository remoto:

 git config receive.denyCurrentBranch updateInstead 

É mais seguro que config receive.denyCurrentBranch=ignore : ele permitirá o envio somente se você não estiver sobrescrevendo a modificação em andamento.

Veja commit 1404bcb por Johannes Schindelin ( dscho ) :

receive-pack : adicione outra opção para receive.denyCurrentBranch

Ao sincronizar entre diretórios de trabalho, pode ser útil atualizar a ramificação atual via ‘ push ‘ em vez de ‘ pull ‘, por exemplo, ao enviar uma correção de dentro de uma VM ou ao pressionar uma correção feita na máquina de um usuário (onde o desenvolvedor está não é livre para instalar um daemon ssh e muito menos saber a senha do usuário).

A solução alternativa comum – avançar para um ramo temporário e depois se fundir na outra máquina – não é mais necessária com esse patch.

A nova opção é:

 updateInstead 

Atualize a tree de trabalho de acordo, mas recuse-se a fazê-lo se houver alterações não confirmadas.


O commit 4d7a5ce adiciona mais testes e menciona:

O anterior testa apenas o caso em que um caminho a ser atualizado pelo push-to-deploy tem uma alteração incompatível na tree de trabalho do destino que já foi adicionada ao índice, mas o recurso em si quer exigir que a tree de trabalho seja muito mais limpo do que o que é testado.

Adicione mais alguns testes para proteger o recurso de alterações futuras que, por engano (do ponto de vista do inventor do recurso), solucionam o requisito de limpeza, a saber:

  • Uma alteração apenas na tree de trabalho, mas não no índice, ainda é uma alteração a ser protegida;
  • Um arquivo não rastreado na tree de trabalho que seria sobrescrito por um push-to-deploy precisa ser protegido;
  • Uma mudança que acontece para fazer um arquivo idêntico ao que está sendo empurrado ainda é uma mudança a ser protegida (ou seja, o requisito de limpeza do recurso é mais rigoroso do que o da finalização da compra).

Além disso, teste que uma alteração apenas de statistics na tree de trabalho não é um motivo para rejeitar um push-to-deploy.

Este é o mesmo problema que esta questão , a solução é usar o git init --bare ou git clone --bare .