Resetar branch local conforme branch do repositório

Neste artigo você vai aprender a como resetar branch local conforme branch do repositório, ou seja, resetar o branch de acordo com a master

Pra deixar o branch local exatamente igual ao do repositório remoto, são dois comandos:

git fetch origin
git reset --hard origin/main

Troque main por master se o branch principal do teu projeto ainda for esse

O fetch atualiza a referência origin/<branch> aqui no teu clone, e o reset –hard move a ponta do branch local pra ela, reescrevendo o índice e o diretório de trabalho

Se liga antes de apertar o enter: o –hard descarta qualquer alteração em arquivo rastreado feita desde aquele commit, e arquivos não rastreados continuam onde estão (pra esses existe o git clean)

Fala programador(a), beleza? Bora aprender mais sobre branches e git!

Primeiramente vamos atualizar todos os arquivos que temos no local com os do repositório remoto, para isso podemos utilizar o git fetch

Por último basta utilizar o comando git reset

Em reset vamos colocar a flag –hard, para forçar a reinicialização do branch

E escolher o branch que vamos utilizar como parâmetro para o reset

Em repositórios mais antigos você vai utilizar origin/master

Porém com as mudanças mais recentes o nome deve ser origin/main

Isso sempre está diretamente ligado ao branch principal do seu projeto, vale a checagem

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Veja o comando na prática:

git fetch origin
git reset --hard origin/<branch>

Lembre-se de substituir <branch> por master ou main, depende do seu repositório

Quer aprender mais sobre git? Veja este curso gratuito:

Conclusão

Neste artigo vimos como resetar branch local conforme branch do repositório em git

Utilizamos o git fetch para assegurar o recebimento das últimas atualizações

Por fim o reset para resetar o branch local de acordo com um branch remoto, geralmente o master ou main

Confira nossos cursos gratuitos no Youtube, com vídeos todos os dias!

Se inscreva e ative o sininho para receber as notificações e aprender mais ainda sobre desenvolvimento web!

Veja também nosso catálogo de cursos na Udemy, todos com exercícios e projetos práticos, nas mais diversas tecnologias

O link acima contém um cupom de desconto para os cursos!

Como saber se é master ou main:

O chute aqui custa caro, então melhor perguntar pro próprio Git

git remote show origin

Esse comando mostra os detalhes do remoto, incluindo os dados dos branches de rastreamento

E por que essa confusão existe? Porque as duas pontas mudaram em ritmos diferentes

No GitHub, desde 1 de outubro de 2020, todo repositório novo nasce com o branch padrão main, e os que já existiam não foram mexidos

Já o Git, a ferramenta que roda na tua máquina, ainda cria o branch inicial como master, e a troca pra main está prevista pro Git 3.0

Da pra fixar isso de uma vez nos teus repositórios novos:

git config --global init.defaultBranch main

Essa configuração está disponível a partir do Git 2.28

No GitHub também tem o ajuste: nas preferências de usuário (github.com/settings/repositories) ou nas configurações da organização, na página de repository-defaults

E se tu quiser apontar explicitamente pra onde o HEAD do remoto olha:

git remote set-head origin master

Isso faz refs/remotes/origin/HEAD apontar pra refs/remotes/origin/master, e só funciona se o branch remoto já existir, senão precisa buscar antes

Uma variação que vale conhecer aqui:

git fetch --prune

O –prune remove as referências remote-tracking que não existem mais lá no remoto, antes de buscar as novas

Ou seja, aqueles origin/feature-antiga que ficam encalhados no teu clone saem do caminho

Dá pra deixar isso como padrão pela config fetch.prune, ou por remote.<nome>.prune se tu quiser só num remoto específico

O mesmo efeito de limpeza também sai com git remote prune origin

Cuidado: o –hard destrói trabalho de verdade

Antes de sair rodando, se liga no que essa flag faz

O git reset –hard <commit> move a ponta do branch atual e reescreve o índice E o diretório de trabalho

Qualquer alteração em arquivo rastreado feita desde aquele commit é descartada, sem perguntar nada

A própria documentação do Git é bem direta nisso: o –hard é a única flag que torna o reset perigoso, porque desfaz também o teu trabalho no diretório

É uma das poucas operações do Git que realmente destroem dado

Então a regra de ouro antes de resetar: commita, ou pelo menos tenha certeza de que o que está ali no working directory não te faz falta

Já me ferrei uma vez por causa disso 😅

E os arquivos que o reset NÃO apaga:

Tem uma pegadinha clássica aqui

O reset –hard não encosta nos arquivos não rastreados, aqueles que tu criou e nunca deu git add

Então você reseta o branch, acha que ficou igualzinho ao remoto, e continua com um monte de arquivo solto no projeto

Pra isso existe outro comando:

git clean -fd

O -d faz ele recursar nos diretórios não rastreados, e o -f é o que autoriza a deleção de fato

Sem o -f, o git clean se recusa a deletar arquivo ou diretório, a não ser que clean.requireForce esteja definido como false

E se tu quiser levar junto os arquivos ignorados pelo .gitignore, entra o -x

Tome cuidado com esse aqui, ele é irmão do rm -rf da vida

Deu ruim? Dá pra voltar atrás

Calma, nem todo reset –hard é sentença de morte

O Git guarda as posições anteriores do HEAD no reflog

git reflog
git reset --hard HEAD@{1}

O HEAD@{1} é a posição imediatamente anterior ao reset, ou seja, onde tu estava antes de fazer besteira

E se o reset veio logo depois de um pull ou de um merge, tem um atalho ainda mais direto

Operações de pull e merge sempre deixam a ponta anterior do branch em ORIG_HEAD:

git reset --hard ORIG_HEAD

Isso devolve índice, árvore de trabalho e ponta do branch pro estado anterior

Mas não vá dormir em cima: as entradas do reflog têm prazo de validade

O padrão do Git é gc.reflogExpire de 90 dias, e gc.reflogExpireUnreachable de 30 dias pros commits que ficaram inalcançáveis

E lembrando: isso salva COMMIT, não salva alteração que nunca foi commitada

git clean -fd

git reflog
git reset --hard HEAD@{1}

git remote show origin

git config --global init.defaultBranch main

git fetch --prune