O Git tem um "modo de segurança" para impedir a reescrita do histórico?

Quando você está familiarizado com o Git (e o DVCS em geral) e começa a explorar as mudanças na reescrita do histórico, está seguro se o repositório for apenas local, mas poderá encontrar problemas se trabalhar com controles remotos e tentar empurre essas mudanças.

Um recurso que eu esperaria é a capacidade de ativar um "modo de segurança" que basicamente me impediria de fazer o que eu não deveria fazer ... E o que eu quero dizer com isso? Quero dizer mudanças na reescrita da história para coisas já enviadas para uma origem. Não posso defini-lo com precisão, mas isso incluiria casos como:

commit --amend quando HEAD já foi pressionado
rebase de uma filial não local
reset de um ramo que foi empurrado

Estes são exemplos de situações que provavelmente causarão a próxima pushfalha (porque não seria um avanço rápido, IIRC). Fiz isso por acidente e tive que recriar a filial no controle remoto. E ainda tive a sorte de fazer isso rápido o suficiente para que ninguém fizesse parte da história que reescrevi.

Acredito que é possível identificar esse tipo de alterações e, sob demanda, impedir que o usuário as faça. Existe talvez uma opção para isso?

Se não houver, você acha que vale a pena tentar criá-lo? Você tentaria definir com precisão como identificar uma "mudança perigosa"?

git dvcs

— Kos
fonte

Em um ambiente de trabalho no qual o comprometimento de alterações ruins afeta outros programadores, você provavelmente deve estar mais relutante em executar essas ações, a menos que tenha certeza de que algo deve funcionar. Mesmo assim, verifique se nenhum problema persiste depois. Imagine que, há alguns anos atrás, eu estava em uma equipe de muitos programadores em que um não teria escrúpulos em enviar uma fonte que não fosse compilada ! Eu queria matá-lo após três meses disso.

— 21412 Neil

Parece razoável que você possa detectar isso em um gancho na máquina remota e depois rejeitar as alterações.

— Andrew T Finnell

Veja stackoverflow.com/questions/2085871/…

— ChrisF

Eu não entendi sua pergunta. O modo padrão é seguro. Não permitirá que você faça push, a menos que você especifique --force.

— #

Eu gostaria de ver algo assim também. Basicamente, eu gostaria de fornecer aos alunos do git uma versão mais segura, provavelmente apenas envolvendo a linha de comando e expondo apenas o básico: confirmar, puxar, pressionar, coisas simples. Force-os a usar o git completo para tudo nesta página: git-scm.com/book/en/Git-Tools-Rewriting-History O Git já é um pouco mais difícil de aprender do que outras ferramentas para ter um repositório local e remoto para pensar sobre - preocupar-se com a possibilidade de se recuperar em vez de reverter é assustador.

— Chris Moschini

Respostas:

Isso parece muito próximo, se não a mesma pergunta que Estratégia para impedir ou capturar a reescrita do histórico do Git

Para resumir, você pode ativar

git config --system receive.denyNonFastforwards true

git config --system receive.denyDeletes true

Ou escreva um gancho de recebimento de mensagens para rejeitar qualquer coisa que você determinar como reescrita.

— Andrew T Finnell
fonte

Eu acredito que denyNonFastforwardsé o padrão (?), Enquanto denyDeletesnão é. Esses dois são úteis, mas estou imaginando uma solução do lado do cliente que me impediria de executar uma ação commit --amendse eu não pudesse pressioná-la (porque HEAD já foi enviado).

— 20912 Kos

Em outras palavras: além dos mecanismos que permitem manter um controle remoto consistente, eu gostaria de algo que permita manter um clone "consistente" com um controle remoto também.

— 21412 Kós

@Kos Você pode criar ganchos locais também

— Andrew T Finnell

Existe uma maneira para definir denyNonFastfowardsa trueapenas sobre o branch master? Eu gostaria que meus ramos de tópicos pudessem ser reformulados e pressionados à força.

— nnyby

Não, porque faz parte da filosofia do git fornecer a você todo o poder e permitir que você gerencie esse poder da maneira que desejar.

Se você não aderir a essa filosofia, talvez valha a pena mudar para o Mercurial, pois permite reescrever a história, mas de maneira limitada ou, para ser clara e relutante, que faz com que você sinta que não é uma boa ideia.

— Klaim
fonte

Eu cometo erros. Um mecanismo que exige que eu confirme explicitamente sempre que estou fazendo algo perigoso é algo que parece se encaixar em "gerenciar meu poder da maneira que quero". :-) (O Git também já faz isso em algumas ocasiões.) #

— 275 Kos

AFAIK, a maneira como o git resolve esses problemas é que sempre que você solicitar uma ação, ela será executada localmente, mas informará que o que você está fazendo pode ter consequências indesejáveis. Nesse ponto, você ainda não enviou nada, então você está em posição de revisar seu repositório local e, possivelmente, desfazer a mudança perigosa antes de fazer o envio. Você precisa prestar atenção no que o git está dizendo a você, e é melhor ter cuidado ao reparar esses erros.

— tdammers
fonte