O perigo de reescrever o histórico em um repositório público

Imagine que você deu um push de uma série de commits para um repositório público. Seus colaboradores puxaram esses commits e começaram a trabalhar em cima deles. Agora, se você voltar e der um amend, um revert ou um reset em qualquer um desses commits, estará basicamente mudando a base sobre a qual o trabalho deles foi construído.

Na próxima vez que seus colaboradores tentarem dar um push das alterações, vão receber um erro, porque o histórico da branch local deles não bate mais com o histórico da branch remota. Eles vão ter que reconciliar manualmente os históricos divergentes, o que pode ser um processo confuso e frustrante.

A regra de ouro é: nunca reescreva o histórico público. Depois de dar um push de um commit para um repositório público, considere que ele foi gravado em pedra. Se precisar corrigir algo, use git revert para criar um novo commit que desfaz as alterações, em vez de tentar modificar o commit existente.

Se não houver como escapar de reescrever o histórico (por exemplo, para remover dados sensíveis commitados por acidente), converse antes com seus colaboradores. Garanta que todo mundo puxou as alterações mais recentes e está na mesma página. Depois que você reescrever o histórico, cada pessoa vai precisar resetar a própria branch local para ficar de acordo com o novo histórico do remoto.

Só mais uma coisa: cuidado com o git push --force. Esse comando sobrescreve a branch remota com a sua branch local, ignorando qualquer conflito. É como dizer: "não me importa o que está no remoto, quero que fique exatamente igual à minha branch local". Isso pode fazer colaboradores perderem trabalho, se eles tiverem subido commits que você não puxou antes de forçar o push.

A opção --force tem usos legítimos, mas só use quando entender totalmente as consequências. Se não tiver certeza, é melhor usar git push --force-with-lease, que pelo menos avisa se a branch remota tiver alterações que você não esperava.