Branches e merges no Git

Branches permitem manter várias frentes de trabalho no mesmo projeto ao mesmo tempo, sem que uma atrapalhe a outra. Neste artigo, o(a) senhor(a) vai entender o que são branches e por que elas são úteis. Também vai aprender a criá-las, alternar entre elas, combinar alterações e resolver conflitos de merge com as ferramentas da IDE, sem complicação. Essa base ajuda a entender o que o Claude Code faz quando trabalha em uma branch separada do seu repositório.

Os exemplos e as capturas de tela mostram uma IDE da JetBrains; os nomes e a localização das ações podem variar conforme a sua versão. Para praticar, use um repositório de estudo separado. Em projetos de trabalho, siga as regras do próprio projeto para branches, commits e envio de alterações.

O que são branches e por que elas são úteis

Uma branch dá nome a uma linha separada de commits. Criar uma branch não copia a pasta do projeto nem salva arquivos ainda não commitados. Em uma pasta de trabalho comum, ao trocar de branch, o Git atualiza os arquivos de acordo com a branch escolhida; alterações não finalizadas podem seguir junto para a nova branch ou impedir a troca.

Da branch principal main parte uma nova branch feature/new-idea para uma frente de desenvolvimento separada. Quando o trabalho termina, ela é mesclada de volta em main.

Imagine que o(a) senhor(a) queira reformular algo importante no projeto ou fazer um experimento arriscado. Como faria isso sem Git? Provavelmente copiaria o projeto inteiro para uma nova pasta e trabalharia nela. Se gostasse do resultado, levaria as mudanças para a pasta principal. Se não, bastaria apagar a cópia.

A comparação com uma cópia ajuda a visualizar frentes de trabalho separadas, mas, tecnicamente, uma branch é um ponteiro para um commit. Veja como isso funciona com o exemplo de um livro:

1. o(a) senhor(a) tem um manuscrito pronto (essa é a sua branch principal, main);
2. quer escrever um final alternativo (cria uma branch nova, por exemplo feature/new-idea);
3. escreve o novo final sem mexer no texto principal do manuscrito (trabalha na branch nova);
4. se o novo final ficar melhor, troca o antigo por ele (faz o merge das branches - merge);
5. dá para apagar o rascunho antigo, com o final que não vai usar (remove a branch).

Criar uma branch e trabalhar nela

Etapa 1. Abra o menu de branches.

Na barra de ferramentas principal, ao lado do nome do projeto, há um widget que mostra o nome da branch atual (por padrão, main). Clique nele e selecione + New Branch.

Etapa 2. Dê um nome à branch.

Uma boa prática é nomear a branch de acordo com a tarefa em que está trabalhando. Por exemplo, feature/add-usage-examples.

Se a opção Checkout branch estiver marcada durante a criação, a IDE mudará para a nova branch. Confira o nome dela no widget antes de editar os arquivos.

Etapa 3. Faça as alterações e crie um commit.

Adicione ao README.md uma seção com exemplos de uso. Revise as alterações e crie um commit como de costume: um snapshot salvo aparecerá no histórico da nova branch.

Alternar entre branches

Suas alterações com os exemplos de uso agora estão salvas na branch feature/add-usage-examples. Vamos voltar à branch principal main e ver o que há por lá.

Etapa 1. Clique novamente no widget com o nome da branch atual, no canto superior esquerdo.

Etapa 2. Na lista Local ou Recent, selecione a branch main e, no submenu que aparecer, clique em Checkout.

Etapa 3. Confira o resultado.

Depois de mudar de branch, abra o arquivo README.md. O(a) senhor(a) verá que a seção com exemplos de uso não está lá - ela ficou na outra branch. Assim, dá para trabalhar em uma funcionalidade nova sem mexer na versão estável da branch main.

Fazer merge das branches

O merge combina o histórico da branch selecionada com o da branch atual. Se main não avançou desde a criação da outra branch, pode ocorrer um fast-forward: main avança até C3 sem criar um novo commit. Se as linhas divergiram, um merge comum cria um commit com dois pais.

No caso linear mostrado, main pode avançar até C3. A branch feature/add-usage-examples também aponta para C3 por enquanto; não é preciso apagar o nome dela para fazer o merge.

Então, o(a) senhor(a) terminou o trabalho na branch feature/add-usage-examples e quer incluir essas alterações no projeto principal.

Etapa 1. Mude para a branch de destino.

Certifique-se de estar na branch PARA A QUAL quer levar as alterações. Neste caso, é main.

Etapa 2. Faça o merge.

Clique novamente no widget de branches. Na lista, selecione a branch DA QUAL quer trazer as alterações (feature/add-usage-examples), e no submenu selecione Merge 'feature/add-usage-examples' into 'main'.

Etapa 3. Confira o resultado.

Agora a branch main tem a nova seção com exemplos no arquivo README.md. Seu trabalho foi integrado à versão principal do projeto.

Conflitos de merge

Um conflito significa que o Git não conseguiu combinar as alterações automaticamente. Um caso comum é quando as mesmas linhas foram editadas de maneiras diferentes; também pode acontecer quando um arquivo é removido em uma branch e alterado em outra. A solução depende do resultado desejado.

É aqui que as ferramentas integradas à sua IDE (CLion ou IntelliJ IDEA) fazem diferença. Resolver conflitos pelo terminal não é das tarefas mais agradáveis, mas a ferramenta de merge em três vias (3-way merge) deixa o processo visual e simples.

As duas branches receberam commits a partir do ancestral comum C1. A divergência no histórico, por si só, não garante um conflito: ele surge quando o Git não consegue combinar as alterações automaticamente. No exercício abaixo, textos diferentes substituem a mesma linha original.

Vamos criar um conflito de propósito:

1. confirme que está na branch main e que não há alterações sem commit nem arquivos novos na janela Commit;
2. crie uma branch nova, feature/new-title, mas ainda não mude para ela. Confira se a opção Checkout branch está desmarcada;
3. ainda na branch main, troque a primeira linha de README.md por "My Awesome Project" ecrie um commit;
4. mude para a branch feature/new-title. Verá que a primeira linha de README.md ainda está como antes - esse era o estado do arquivo quando a branch foi criada. Troque essa mesma linha por "My Super Project" ecrie um commit;
5. volte para a branch main e faça o merge com feature/new-title.

Agora o Git vai perceber que os dois históricos alteraram o mesmo trecho. Ele abrirá a janela para resolver o conflito (Merge Conflicts).

Clique em Merge para abrir a ferramenta de resolução de conflitos. O que aparece aqui:

• à esquerda (Your changes) - a versão do arquivo na branch atual, aquela que recebe o merge (main);
• à direita (Changes from branch) - a versão do arquivo na branch que está sendo integrada;
• no centro (Result) - a versão final do arquivo, que o(a) senhor(a) monta manualmente.

É possível clicar nas setas >> ou << (ou nos X para cancelar) e aceitar uma das versões por inteiro. Também dá para simplesmente escrever o texto correto no painel central.

Confira o resultado no painel central e clique em Apply ou no botão equivalente para concluir. Depois, verifique o estado do Git: se o merge ainda não foi registrado, crie um commit pela IDE. Resolver as linhas conflitantes e concluir o merge são etapas diferentes. Confira se o código resultante funciona como esperado.

Por que às vezes não há conflito

Se não houver conflito no exercício, confira a partir de qual commit a segunda branch foi criada e se os dois lados realmente substituíram a mesma linha de maneiras diferentes. O Git consegue combinar automaticamente alterações compatíveis, mesmo em branches divergentes. Outra possibilidade é um histórico linear, que permite o fast-forward:

Veja um exemplo:

1. há um commit qualquer na branch main (digamos, C1);
2. o(a) senhor(a) cria um commit novo na branch main com o texto "My Awesome Project". Agora, main aponta para o commit C2;
3. cria a branch feature/new-title a partir da posição atual de main - a branch nova também começa no commit C2;
4. cria um commit nafeature/new-title com o texto "My Super Project". Essa branch avança e aponta para o commit C3;
5. volta paramain (que ainda está no commit C2) e faz o merge com feature/new-title.

O Git percebe que a branch main é ancestral direta da branch feature/new-title: não houve commits novos no histórico de main enquanto o(a) senhor(a) trabalhava na outra branch. Por isso, ele apenas avança o ponteiro de main até o commit C3, sem conflitos.

O histórico de main continua no de feature/new-title, sem divergência. Por isso, o Git apenas avança main - não há conflito.

Consultar o histórico de alterações

Para entender melhor o que acontece no projeto, vale a pena consultar o histórico.

Abra a janela da ferramenta Git (geralmente, o ícone fica na barra lateral esquerda ou na parte inferior da IDE) e selecione a aba Log ou Show Git Log na barra da ferramenta Git. Aparecerá um gráfico com todas as branches e commits, que facilita acompanhar de qual branch cada uma surgiu e onde elas foram integradas.

Clique em qualquer commit para ver quais alterações ele contém, quem o criou e quando. É praticamente uma máquina do tempo para o seu código.

Como isso funciona com o Claude Code

Agora que o(a) senhor(a) entende branches, fica mais fácil acompanhar o que o Claude Code faz no seu repositório. Veja o que ele faz com essa tecnologia pelo(a) senhor(a) e no que vale prestar atenção:

• cria uma branch separada quando a tarefa e as regras do projeto preveem isso;
• sugere um commit em momentos importantes - o(a) senhor(a) lê o diff e decide se aceita ou faz ajustes;
• ajuda a encontrar o commit salvo certo e escolher como voltar, levando em conta as alterações ainda sem commit;
• se houver um conflito de merge, pode pedir sua ajuda - a resolução é feita na mesma ferramenta da IDE;
• consegue preparar e comentar um pull request (PR - uma proposta para integrar uma branch à principal, por exemplo, usando o GitHub CLI).

Artigo anterior: Rotina diária de trabalho com Git · Próximo artigo: Pull request: da criação ao merge