Git

Você está no meio de um branch de feature, três arquivos alterados e nada commitado, quando um colega avisa sobre um null pointer quebrando a produção. O jeito usual é dar git stash, fazer checkout da main, corrigir, dar push, depois git stash pop e torcer para que nada na sua feature inacabada dependesse dos arquivos que você acabou de trocar. O git worktree elimina essa dança. Ele faz checkout do branch do hotfix em uma segunda pasta, ao lado do seu branch de feature, com os dois apoiados no mesmo repositório. ...

Rode git reset --hard num commit que seu time já deu pull nele, e seu histórico passa a discordar do deles. Rode git revert num typo que você nem chegou a dar push nele, e acaba de acrescentar um commit inútil ao log. O Git tem quatro comandos para desfazer mudanças, restore, reset, commit --amend e revert, e eles não são intercambiáveis. Escolher o errado ou não faz nada, ou faz muito mais do que você queria. ...

A suíte de testes está verde há três semanas. Hoje o npm test falha em uma asserção que não tem nada a ver com o que você acabou de mudar, e git log v1.4.0..HEAD mostra 340 commits de quatro pessoas desde o último release que alguém tinha certeza de que funcionava. Ler cada diff custa um dia inteiro. Fazer checkout de commits ao acaso é mais rápido, mas ainda não é um plano. ...

Você dá pull na última versão da main e o Git para com CONFLICT (content): Merge conflict in checkout.js. Você resolve o conflito e o log agora mostra um commit chamado Merge branch 'main' into feature/checkout, acima dos três commits que você realmente escreveu. Quatro commits, uma única mudança real. Um colega que ler esse histórico no mês seguinte não consegue saber qual é qual. git merge e git rebase respondem à mesma pergunta: como eu atualizo meu branch com as mudanças feitas em outro lugar. Eles deixam rastros muito diferentes, e escolher o errado num branch compartilhado causa dano real. ...