Git: Apagando Branches, Fazendo Merge e Desfazendo um Push Errado

August 2, 2026 · – visitantes

Essas três coisas aparecem o tempo todo, e de alguma forma os comandos nunca ficam de fato gravados de uma vez para a outra. Então aqui estão eles, escritos direito.

Apagando uma Branch

git branch -d feature-x

Essa é a versão segura — o Git verifica antes, e recusa se feature-x tiver commits que nunca chegaram à sua branch atual. Se você tiver certeza, pode forçar: (1)

git branch -D feature-x

Isso só apaga localmente, porém. Se a branch também existir no remoto (no GitHub, digamos), você precisa apagá-la lá separadamente:

git push origin --delete feature-x

Uma coisa que vale a pena saber: apagar uma branch não apaga de fato seus commits. Eles só ficam sem referência e continuam no repositório até o garbage collector do Git eventualmente varrê-los, o que pode demorar um bocado. Então git branch -D é mais tolerante do que parece — se você apagar a branch errada, geralmente ainda há um caminho de volta (mais sobre isso na seção de reflog logo abaixo). Eu não contaria com isso como um plano, mas é bom saber que está lá.

Fazendo Merge de Branches

O formato mais comum é: faça checkout da branch para a qual você quer fazer o merge, depois traga a outra para dentro dela.

git checkout main
git merge feature-x

O que acontece a seguir depende de a main ter avançado ou não desde que você criou a branch. Se não tiver avançado, o Git simplesmente desliza o ponteiro da main para frente até alcançar feature-x — um fast-forward, sem nenhum merge commit envolvido. Se a main avançou nesse meio-tempo, o Git cria um merge commit de verdade que amarra as duas histórias (2).

Às vezes você quer esse merge commit mesmo quando um fast-forward seria possível — ele deixa uma marca visível no histórico de que uma feature branch existiu e foi mesclada, em vez de a mudança simplesmente se misturar em silêncio. Para isso:

git merge --no-ff feature-x

Se as mesmas linhas foram alteradas dos dois lados, o Git para e deixa o conflito para você resolver:

git status

Isso vai listar quais arquivos estão em conflito. Abra cada um, você vai ver marcadores <<<<<<<, ======= e >>>>>>> em volta das mudanças concorrentes — escolha o que realmente deve ficar, apague os marcadores, e então:

git add resolved-file.txt
git commit

E se virar mais bagunça do que vale a pena, você pode simplesmente abandonar tudo:

git merge --abort

Isso devolve tudo exatamente a como estava antes de você começar o merge.

Desfazendo um Push Errado

Essa é a situação com a qual as pessoas entram em pânico, e sinceramente o pânico costuma ser desnecessário — mas qual correção você escolhe realmente importa aqui.

Se houver qualquer chance de outra pessoa já ter dado pull na branch, não mexa no histórico. Em vez disso, adicione um novo commit que desfaz o antigo:

git revert <bad-commit-sha>
git push

Essa é a opção chata e sempre segura. Ela não reescreve nada — só adiciona um commit por cima que cancela o erro, então o histórico de todo mundo continua sincronizado sem que ninguém precise fazer nada especial do lado deles (3).

Se a branch é genuinamente só sua e ninguém deu pull nela ainda, você pode rebobinar e reescrever: (4)

git reset --hard <last-good-commit-sha>
git push --force-with-lease

Use --force-with-lease, não o --force puro, nem que seja por hábito. A diferença importa mais do que parece: --force-with-lease verifica se ninguém deu push na branch desde o seu último fetch, e recusa se alguém tiver dado. O --force puro não verifica nada — ele sobrescreve alegremente o trabalho de outra pessoa sem nem um aviso (5).

E se você estiver encarando o terminal tentando lembrar qual era o último commit bom — o git log não ajuda aqui, já que ele só mostra commits alcançáveis de onde você está agora, o que não inclui aquilo de onde você já deu reset. O que você quer é:

git reflog

Ele mostra todo lugar para onde sua branch apontou recentemente, incluindo os que caíram fora do histórico normal. Volte até antes das coisas darem errado, então: (6)

git reset --hard HEAD@{2}

(troque pela posição ou SHA que realmente corresponde ao seu caso). O reflog é local à sua máquina e geralmente guarda entradas por cerca de 90 dias, então é menos um "desfazer de emergência para pushes errados" e mais uma rede de segurança geral para "acho que acabei de quebrar alguma coisa" — vale lembrar que ele existe mesmo fora dessa situação específica.

Uma reflexão final

Essas três coisas se apoiam no mesmo fato de fundo: o Git quase nunca descarta algo imediatamente. Branches apagadas, commits resetados, posições antigas de uma branch — tudo isso fica rondando por mais tempo do que parece. É isso, na real, que torna -D, reset --hard e o force-push seguros o suficiente para o uso do dia a dia, contanto que você saiba onde procurar se um deles acabar sendo um erro.

Leituras Relacionadas

Entendendo o Make — o que de fato dispara uma recompilação

Leitura adicional

git-branch — criação, listagem e exclusão de branches.
git-merge — estratégias de merge e resolução de conflitos.
git-revert — desfazendo commits criando novos commits.
git-reset — movendo o ponteiro de uma branch, com a diferença entre --soft, --mixed e --hard.
git-push: --force-with-lease — por que é mais seguro que --force.
git-reflog — recuperando commits que não aparecem mais no histórico normal.