ROTEIRO ANTIGO DETECTADO

“Dar force-push num fix parece esconder a prova”

Experimente esta resposta:

“Meu histórico de commits é um espaço de trabalho, não uma confissão para eu apagar.”

Faça a autoavaliação de 60 segundos →

VER A PRÁTICA

Crie uma resposta para este pensamento e um passo para colocá-la à prova.

O PENSAMENTO

“Dar force-push num fix parece esconder a prova”

SUA RESPOSTA GRAVADA

“Meu histórico de commits é um espaço de trabalho, não uma confissão para eu apagar.”

UM PASSO PRIVADO

Num repositório git local descartável, faça uma primeira tentativa deliberadamente tosca, depois o fix real por cima sem squash nem force-push, e releia o log uma vez.

O Commit que Você Rebasa Antes que Alguém Olhe

O Rastro em Papel Não É uma ConfissãoVocê errou o fix na primeira tentativa, acertou na segunda, e agora sua branch tem os dois commits um atrás do outro. Antes de abrir a PR, você faz rebase, squash, force-push, e a primeira tentativa some. Por baixo disso está a ideia de que um erro visível não é parte normal de resolver o bug, mas prova que um júri poderia usar contra você, então precisa sumir antes que alguém consiga olhar.

Por Que Todo Commit Parece um DepoimentoIsso funciona com a mesma matemática viciada da ansiedade de review em geral: você presume que o reviewer está montando um caso contra você, não só lendo um diff, então qualquer tentativa anterior vira fato incriminador em vez de iteração normal. Quando você passa a acreditar que o próprio histórico será interrogado, organizar deixa de ser estilo e vira controle de danos—você não está moldando uma história, está destruindo uma prova.

Deixe um Commit Torto SobreviverNum repositório local descartável, faça um primeiro commit deliberadamente tosco, depois o fix de verdade por cima, sem squash e sem force-push. Releia o log como um estranho leria. A maioria desses históricos só mostra alguém resolvendo um problema em ordem, não um processo. Uma única releitura tranquila não desfaz o hábito, mas te dá um dado real ao lado do imaginado.

TRACE · 01/04

Como este roteiro controla você

Você faz rebase e force-push antes de abrir a PR para que o commit onde errou primeiro nunca fique visível.
Você relê o `git log` mais do que o diff em si, checando se a história dos seus erros ainda pode ser reconstruída.
Um reviewer perguntando 'como era a primeira versão?' cai como se ele tivesse notado algo que você tentou enterrar.

SOURCE_LOCATED · 02/04

A regra oculta por baixo

O Julgamento do Review

Se alguém puder ver o commit onde eu errei antes de acertar, vai concluir que eu não sei mesmo o que estou fazendo, então o histórico precisa parecer limpo desde a primeira linha.

FORGING_REPLACEMENT · 03/04

Linhas de substituição (grave estas)

Meu histórico de commits é um espaço de trabalho, não uma confissão para eu apagar.
Uma primeira tentativa tosca prova que eu itero, não que sou incapaz.
Reescrever o log me custa mais clareza do que esconde de qualquer outra pessoa.

No app são geradas por pessoa — isto é o sabor, não o seu roteiro. O seu é construído com as suas palavras exatas.

INSTALL · 04/04

O protocolo, em um cartão

Quando penso

“Dar force-push num fix parece esconder a prova”

Eu digo

“Meu histórico de commits é um espaço de trabalho, não uma confissão para eu apagar.”

Depois faço uma coisa

Num repositório git local descartável, faça uma primeira tentativa deliberadamente tosca, depois o fix real por cima sem squash nem force-push, e releia o log uma vez.

STATUS: READY_TO_INSTALL

Apagar este pensamento

4 minutos. Sua voz. Grátis.

Começar este wipe exato no app →

O protocolo de wipe

Escreva o pensamento exatamente como ele toca: "Dar force-push num fix parece esconder a prova". Palavra por palavra — o wipe mira a frase, não a sensação.
Rastreie a regra e a ação evitada. Do que esse pensamento convenientemente desculpa você?
Grave as linhas de substituição abaixo com a sua própria voz. Fale para valer — sem gravação, sem instalação.
Rode o ciclo: toque toda manhã e noite, registre uma ação-prova por dia durante 7 dias.

Respostas diretas

Dar force-push por cima de commits tortos antes de uma PR não é só boa prática de git?

Limpar commits barulhentos—renomear, remover um print de debug esquecido, juntar ajustes triviais—é prática comum. Esse pensamento vai além: trata qualquer tentativa falha visível como algo que precisa sumir antes do review, não por ser barulhenta, mas porque um primeiro erro parece algo que ninguém pode se dar ao luxo de ver.

E se um colega notar que um commit anterior sumiu da branch e perguntar por quê?

Essa pergunta geralmente significa curiosidade sobre uma abordagem, não a montagem de um caso contra você. Você pode responder com honestidade sobre o que tentou primeiro, sem tratar a pergunta como o julgamento que você tentava evitar reescrevendo o histórico.

Fazer squash de commits antes de um merge normal conta como a mesma coisa?

Squash como convenção de equipe, aplicado do mesmo jeito não importa como a branch andou, é uma escolha de formato que todo mundo segue. Esse pensamento é diferente—é uma decisão privada, movida pelo medo, de apagar especificamente os commits que mostram que você não acertou de primeira.