Estou preocupado que eu possa esquecer esse recurso bacana da próxima vez que precisar.
O Git 2.13 (Q2 2017) explica por que não há "proteção" contra esta opção de envio sendo esquecida, porque mesmo que você não a esqueça no git push
nível, ela ainda pode ser ignorada.
Veja commit f17d642 (19 de abril de 2017) por Ævar Arnfjörð Bjarmason ( avar
) .
(Mesclado por Junio C Hamano - gitster
- na commit 46bdfa3 , 26 de abril de 2017)
push
: documento e teste --force-with-lease
com vários controles remotos
Documente e teste os casos em que existem dois controles remotos apontando para a mesma URL e uma busca em segundo plano e subsequente git push --force-with-lease
não devem refutar referências não atualizadas que não foram buscadas.
Alguns editores como o VSC da Microsoft têm um recurso para buscar automaticamente em segundo plano, isso ignora as proteções oferecidas por --force-with-lease
&--force-with-lease=<refname>
, conforme observado na documentação adicionada aqui.
Portanto, a documentação dogit push
momento inclui:
observação geral sobre segurança: fornecer esta opção sem um valor esperado, ou seja, como --force-with-lease
ou --force-with-lease=<refname>
interage muito mal com qualquer coisa que implícita seja executada git fetch
no controle remoto para ser empurrada para segundo plano, por exemplo, git fetch origin
no seu repositório em um cronjob.
A proteção oferecida --force
é garantir que as alterações subsequentes nas quais seu trabalho não foi baseado não sejam prejudicadas, mas isso será derrotado trivialmente se algum processo em segundo plano estiver atualizando as referências em segundo plano. Não temos nada, exceto as informações de rastreamento remoto, como uma heurística para os árbitros que você deve ter visto e está disposto a adotar.
Se o seu editor ou outro sistema estiver sendo executado git fetch
em segundo plano para você, uma maneira de atenuar isso é simplesmente configurar outro controle remoto:
git remote add origin-push $(git config remote.origin.url)
git fetch origin-push
Agora, quando o processo em segundo plano for executado, git fetch origin
as referências origin-push
não serão atualizadas e, portanto, comandos como:
git push --force-with-lease origin-push
Falhará, a menos que você execute manualmente git fetch origin-push
.
É claro que esse método é totalmente derrotado por algo que é executado git fetch
--all
; nesse caso, você precisa desativá-lo ou fazer algo mais entediante como:
git fetch # update 'master' from remote
git tag base master # mark our base point
git rebase -i master # rewrite some commits
git push --force-with-lease=master:base master:master
Ou seja, crie uma base
tag para versões do código upstream que você viu e deseja sobrescrever, depois reescreva o histórico e, finalmente, force as alterações por push para master
se a versão remota ainda estiver base
, independentemente do local em que seu local remotes/origin/master
foi atualizado. fundo.
rm
pararm -i
em seu .bashrc; você esquecerá e excluirá um arquivo importante em um servidor algum dia. Indo com seus próprios alias não tem esse problema :)