Escolher como juntar mudanças pensando na auditoria de um ano depois

Reverter uma entrega ruim numa segunda-feira depende de saber, sem arqueologia, o que exatamente voltou.

Merge, rebase e squash são três formas de incorporar uma mudança à linha principal, e cada uma produz um histórico diferente. Essa escolha decide o que a sua empresa consegue auditar daqui a um ano.

Na prática, o merge integra linhas de trabalho e pode preservar um ponto de junção. Rebase reaplica mudanças sobre outra base e gera novos identificadores.

Squash reúne mudanças em um commit, registro de uma versão. O código final só será equivalente se mudanças e conflitos forem resolvidos da mesma forma. A história preservada é diferente, e nenhuma escolha garante reversão simples de dados ou efeitos externos.

O critério que decide na prática é um só. Se outra pessoa já baixou aquela linha de trabalho, reescrever a história transfere para o dia dela o custo da sua limpeza.

É como refazer os nós de um cordão que outras três pessoas seguram. O fio fica reto na sua mão, e as etiquetas que elas seguravam deixam de existir.

A ponta dessa história é a release, o pacote identificado por versão que a empresa consegue anunciar e reverter como unidade. A marca que aponta para ela, chamada de tag, nasce uma vez e não se mexe.

Mover uma tag equivale a apagar um número de patrimônio e reusá-lo em outro item. Release que respeita a regra permite voltar atrás com confiança; release que fura vira trabalho de auditoria.

Isso vira um critério de contratação: prefira o time que exibe histórico legível de decisões ao time que exibe volume de commits.

Na reunião de incidente, o histórico legível responde em minutos o que entrou junto com a mudança que quebrou o sistema. O histórico bagunçado transforma a mesma pergunta em meio dia de investigação, com o cliente esperando.

Teste a reversão antes de precisar dela, com uma entrega que já está no ar. Escolha uma publicada no último mês, de preferência uma que tenha mexido em mais de um lugar do produto.

Pergunte quanto tempo levaria para desfazer só aquela entrega e quem executaria a operação. Resposta que começa com depende costuma indicar que a mudança entrou junto com outras e não sai sozinha. Pergunte também qual estratégia de integração o time usa e por quê, porque a justificativa importa mais que a escolha e precisa citar quem mais lê aquele histórico.

Se você guardar só cinco palavras, guarde estas. Branch: a linha paralela onde a mudança nasce. Pull request: o pedido para incorporá-la. Diff: a lista do que mudou linha a linha. Merge: o momento em que a mudança passa a valer para o cliente. Release: o pacote que a empresa anuncia e reverte.

Você decide o teto de linhas que a empresa aceita revisar de uma vez, e a exigência de revisor diferente do autor. As duas cabem numa regra do repositório.

O time decide entre merge, rebase e squash, desde que a reversão continue barata e o histórico continue legível.

Essa é a decisão que cabe a você. Peça por escrito, na renovação do contrato, a conta que hospeda o repositório, a lista de quem pode publicar e o registro de revisão das últimas dez entregas. Se alguma delas entrou sem revisor diferente do autor, a regra do repositório ainda não barra.