Você está concentrado trabalhando em uma funcionalidade e percebe que o Biome (ou o Prettier) não está funcionando. Confuso, executa biome check. Afinal, pode ser um problema de configuração ou até mesmo da IDE. Ele formata todos os seus arquivos, inclusive aqueles em que você estava adicionando a funcionalidade. Agora você tem 100 arquivos alterados, mas os arquivos em que realmente estava trabalhando são apenas 5.
Se você imaginou o CJ de GTA San Andreas dizendo “Ah shit, here we go again”, sabe exatamente o pesadelo que o espera. Você precisa separar os arquivos alterados entre mudanças da funcionalidade e mudanças do Biome.
Fazer isso é entediante e complexo, especialmente se você é novo no Git. Quanto mais arquivos tiver, e quanto mais complexa for a funcionalidade que está desenvolvendo, pior será.
Mas por que isso é um problema?
Commits precisam ser atômicos. O quanto precisam ser atômicos é algo bastante discutível. Por muito tempo, fiz commits com tudo o que é essencial para algo funcionar. Por exemplo, uma página React com um calendário terá o código da funcionalidade, os componentes e os pacotes que adicionei ao package.json. Se você fizer checkout especificamente desse commit, a página funcionará perfeitamente.
Mas há outras opiniões. Algumas pessoas afirmam que os commits deveriam ser ainda mais atômicos. Arquivos de configuração, componentes e o código da funcionalidade deveriam estar em commits separados. Então, em vez de um commit funcional, você teria três commits.
Não importa o que você prefira, há uma regra que não está escrita: não se pode ter código de funcionalidade e código formatado pelo Biome no mesmo commit. Caso contrário, o processo de revisão ficará muito difícil. Essas duas mudanças deveriam ser introduzidas separadamente, até em PRs diferentes.
As revisões precisam ser o mais fáceis possível. Corrigir essa bagunça garante que o revisor tenha commits limpos para analisar.
Escolhendo uma estratégia
Devo verificar cada arquivo e revertê-lo para manter apenas as mudanças da funcionalidade? Devo usar o stage do Git para separar as mudanças?
Como o Biome altera a maioria dos arquivos de forma automatizada, você pode descartar as mudanças e executá-lo novamente depois de fazer um commit das mudanças da funcionalidade. Usar o staging também funciona, e foi o caminho que escolhi para este tutorial.
Agora precisamos separar nossa funcionalidade das mudanças do Biome. Vejamos o que podemos fazer.
Identificando as partes
Primeiro, precisamos identificar as partes dos arquivos que foram alteradas pelo Biome. Essas mudanças dizem respeito a indentação, vírgulas finais, espaços e mais. São bem fáceis de identificar. Mudanças que alteram lógica ou adicionam linhas geralmente são as suas mudanças de funcionalidade.
Como regra geral, arquivos não rastreados (novos) e arquivos removidos podem ser considerados mudanças da sua funcionalidade. Mesmo que o Biome formate o código novo, isso não faz diferença funcional para suas alterações. Você pode ter certeza de que o componente funcionará exatamente como antes da formatação. E, de bônus, terá um arquivo já formatado antes de fazer o commit.
Arquivos modificados são a parte complicada.
Separando os arquivos modificados
É aqui que as coisas podem ficar muito bagunçadas, especialmente se o arquivo tiver muitas linhas de código. E, a menos que você seja muito habilidoso com Git, isso pode se tornar um pesadelo.
Como mencionado antes, você precisa identificar nos arquivos modificados o que foi adicionado ou alterado por você e o que foi alterado pelo Biome.
Vamos brincar de um jogo. Vou mostrar um diff e você tenta adivinhar onde estão as mudanças do Biome.
O primeiro:
O console log foi removido. E o Biome nunca remove linhas; ele apenas as altera. As outras linhas parecem ser sobre indentação, quebras de linha e ordenação de imports. Portanto, aqui há mudanças do Biome e da funcionalidade misturadas.
O próximo:
Este foi tão intensamente alterado que pode ser considerado uma mudança do usuário. O Biome pode ter feito algo aqui, mas há tantas alterações que ele é quase como um arquivo não rastreado. Portanto, mudança de funcionalidade.
O terceiro (e maior):
Esse é um botão ShadCN. Trata-se basicamente de imports, indentação, vírgulas finais e ponto e vírgula. Portanto, apenas Biome.
O último:
Há uma pequena mudança na vírgula final da variável de ambiente e, depois, um grande trecho de linhas de código adicionadas. Este também parece uma mistura. O Biome alterou a vírgula final, e o usuário adicionou a função getUser.
Pode haver cenários mais complexos; por exemplo, você alterou uma linha de código e o Biome também a alterou. Nesse caso específico, você precisa manter a mudança; caso contrário, seu componente não se comportará como planejou.
Separando as mudanças
Agora vem a parte divertida (e potencialmente perigosa).
Vamos colocar em stage as partes que pertencem à sua mudança de funcionalidade e deixar todo o restante sem stage.
Isso pode ser feito facilmente no VSCode. Por muito tempo usei a CLI do git para colocar mudanças em stage, mas, quando o VS Code foi lançado, me apaixonei por sua ferramenta de diff. Ela é completa e rica em recursos.
O principal recurso que usaremos é a capacidade de colocar blocos específicos em stage. Vejamos um exemplo:
Este é o arquivo misto em que removemos um console log. Também há ordenação de imports e correções de ponto e vírgula do Biome.
Para manter apenas o console log removido, mova o mouse até a barra que separa o diff e clique em “Stage Block”.
Isso fará com que o console log removido seja colocado em stage. Também fará com que a quebra de linha adicionada pelo Biome seja colocada em stage. Mas você pode confiar nesta. Está ganhando código formatado de graça e tem certeza de que a mudança é equivalente.
Nos casos em que uma única linha é alterada, a ferramenta “Stage Block” colocará essa linha em stage.
Repita esse processo em todos os arquivos.
Tudo em stage. E agora?
Agora você tem todas as mudanças separadas, em stage e prontas para seguir. Mas, antes disso, recomendo testar seu código separado para ter certeza de que funciona. Se não era uma funcionalidade completa, tente testá-la parcialmente.
Para isso, precisamos nos livrar das mudanças sem stage. Você pode fazer isso com:
git stash --keep-indexSe achar que as mudanças do Biome não são importantes e podem ser refeitas depois, faça isto em vez disso:
git restore .Agora restam apenas as mudanças em stage. Execute sua aplicação e teste tudo. Se estiver satisfeito, você pode fazer commit das mudanças com uma boa mensagem de commit ou continuar trabalhando nelas.
Depois de fazer commit dos arquivos da funcionalidade, execute biome check novamente e deixe o código bem formatado. Certifique-se de fazer commit dessas mudanças também.
Conclusão
Procure sempre realizar ações diferentes em momentos diferentes. Ao desenvolver uma funcionalidade, concentre-se nela e esqueça todo o resto. Depois, execute o Biome e deixe seu código bonito e formatado.
Um problema semelhante pode surgir quando você entra em estado de fluxo e começa a criar coisas por pura concentração. Quando chega a hora de fazer um commit, percebe que foi longe demais e que agora é necessário separar. A mesma técnica pode ser aplicada aqui. Mas, nesse caso, é ainda mais difícil. Você precisa saber exatamente quais partes do código pertencem a cada funcionalidade.
Até a próxima. ;)
