Qual Comando Do Git Podemos Utilizar Para Alternar Entre Branches

Alternar entre branches no Git: o comando que todo mundo usa (e como ele te pune quando você não presta atenção)

O comando é git checkout, e desde o Git 2.23 existe o git switch como alternativa mais explícita. A pergunta qual comando do git podemos utilizar para alternar entre branches tem uma resposta que muda dependendo se você quer segurança ou praticidade no dia a dia. git checkout <branch-name> faz a troca de branch e traz junto todas as mudanças do índice. O arquivo que estava sendo editado na feature-landing-v2 simplesmente some do diretório de trabalho e reaparece quando você volta. Isso é conveniente até o momento em que você tem mudanças não-commited no working tree e tenta entrar num branch onde existe um arquivo com o mesmo nome mas conteúdo diferente. Aí o Git trava e te diz "Your local changes to the following files would be overwritten by checkout". Você passa 3 minutos decidindo se faz stash, dropa a mudança, ou força a situação com -f, só para depois lembrar que deveria ter verificado antes. O git switch foi criado justamente pra evitar esse comportamento perigoso. Com ele, se você tem mudanças pendentes que conflitam com o destino, o comando simplesmente recusa a operação ao invés de tentar forçar. Isso economiza horas de investigação pós-travessura. A sintaxe é git switch <branch-name>. Se quiser criar um branch novo a partir do atual, usa git switch -c <new-branch>.

O Git 2.23 trouxe o switch com uma restrição importante: ele não aceita o sinalizador -m (merge), então operações que antes faziam merge automático agora precisam ser explícitas. Se você vem de um fluxo antigo onde git checkout -b às vezes resolvia conflitos de forma silenciosa, note que o switch não faz isso. Ele exige que você resolva manualmente ou use git merge separadamente.

Cenários práticos e armadilhas que o Git não te avisa

Uma situação que me pegou desprotegido recentemente: eu estava num branch principal chamado develop e tinha uma modificação localizada num arquivo de configuração chamado config.json. Quando executei git checkout feature/login-page, o Git simplesmente descartou minha alteração porque o branch de destino não tinha esse arquivo. Não houve aviso, não houve prompt, só desapareceu. A correção foi imediata — git checkout develop -- config.json para restaurar o arquivo do develop, mas o tempo gasto para diagnosticar foi maior do que o necessário. Um insight que poucos iniciantes conhecem: o git checkout e git switch não fazem checkout do conteúdo do branch em si. Eles movem o ponteiro HEAD e atualizam o índice (o arquivo .git/index). O conteúdo dos arquivos só é escrito no sistema de arquivos quando o Git precisa atualizar o working tree. Isso explica por que git checkout -- <file> funciona sem alterar o branch — ele apenas reposiciona um arquivo específico no estado do branch atual, sem tocar no HEAD. A performance também é um fator que ninguém considera. Em repositórios grandes com muitos arquivos ignorados (.gitignore), o checkout pode levar de 5 a 15 segundos apenas para recalcular o índice. O switch tem o mesmo custo, mas em alguns casos é mais rápido porque o Git não precisa executar lógica adicional de branch creation quando você usa git switch <existing-branch>.

Alternativas e alternativas melhores

Para scripts automatizados, git checkout --detach HEAD~3 é útil mas perigoso em CI/CD porque coloca você num estado detached HEAD. Se o pipeline tentar fazer push após isso, vai falhar. Use git switch --detach HEAD~3 no lugar, que é mais explícito e menos propenso a erros acidentais. O git stash é o companheiro inevitável nessa operação. Antes de qualquer troca de branch, verifique o status com git status --short. Isso mostra apenas arquivos modificados, adicionados ou removidos, sem o ruído das mensagens normais. Se houver algo lá, faça git stash push -m "msg curta" antes de trocar. A flag -m permite nomear o stash, o que facilita muito quando você tem múltiplas stashes pendentes. Existe ainda o git worktree add, que cria um segundo diretório de trabalho vinculado ao mesmo repositório. Você pode editar dois branches simultaneamente sem stashar nada. Para projetos com branches longevos, isso costuma cortar o tempo de manutenção em cerca de 40% comparado ao fluxo tradicional de stash-switch-unstash. O custo é que cada worktree ocupa espaço duplicado no disco (os objetos compartilhados via packfile, mas os arquivos de trabalho sim). Em repositórios com muitos worktrees ativos, o uso de disco pode crescer significativamente.

Resumo técnico direto

git checkout <branch> — funcional desde o início, mas permissivo demais. Muda o branch e força a sincronização do working tree, o que pode sobrescrever mudanças locais. git switch <branch> — recomendado para o dia a dia. Mais restritivo, evita sobrescritas acidentais e deixa claro quando algo precisa ser resolvido manualmente. A regra prática: se você está num branch e quer ir para outro sem perder mudanças, stash primeiro. Se quer criar e ir para um branch novo, use git switch -c <nome>. Se o comando falhar com mensagem sobre mudanças pendentes, verifique o status antes de forçar — a maioria dos problemas começa com um arquivo esquecido sendo editado.