Descomplicando Git: Branches e Merge

#Git

🧠Descomplicando Git:

Quando se trata de Git, é comum nos depararmos com conteúdos cheios de informações desnecessárias e conceitos difíceis de entender. Como profissional cansado de tudo isso e focado em ensinar de forma direta e prática, vou te mostrar, sem enrolação, como usar branches e merge no GIT.

Tópicos abordados neste artigo:

🧭 Introdução
🗂️ Controle de Versão
🌍 Main: nosso universo principal
🪐 Branches: nosso universo paralelo
🔀 Fluxos de Trabalho com Branches
🧹 Boas Práticas com Branches: cuidando bem dos seus universos paralelos
🌌 Merge: mesclando os universos
⚔️ Conflitos
♻️Merge vs Rebase – A Guerra dos Universos
🧠 Conclusão

🧭 Introdução

Antes de explorarmos os conceitos de branches e merge, é fundamental compreender do que se trata o nosso querido Git e o que, de fato, significa controle de versão. Além disso, também abordaremos a importância da branch principal, a famosa main, que costuma ser o ponto de partida na maioria dos projetos.

Gosto sempre de utilizar exemplos práticos ao explicar algum conceito, pois isso facilita tanto o meu entendimento quanto o de quem está aprendendo. Inspirado na técnica de Feynman, vou usar e abusar de analogias ao longo deste artigo para tornar o conteúdo mais acessível e fácil de compreender.

Uma das formas mais legais de entender como o Git funciona é imaginar que estamos lidando com universos paralelos. Pense comigo: a branch main é como o universo original, onde tudo o que você faz tem consequências reais — é o seu código oficial, o que vai pra produção.

Mas e se você quiser testar uma ideia maluca sem correr o risco de bagunçar tudo? Simples: você cria um universo paralelo — ou melhor, uma branch. Dentro dessa nova realidade, você pode experimentar à vontade: criar novas funcionalidades, mudar o layout, corrigir bugs, ou até fazer testes completamente fora da caixa.

No fim, você tem duas opções:

Pode descartar tudo e fingir que aquele universo nunca existiu;
Ou pode trazer de volta as mudanças para o universo original — e aí entra o famoso merge.

Essa é a mágica do Git: permitir que você desenvolva com liberdade, segurança e organização. E o melhor, sem medo de errar. Afinal, se algo sair errado, sempre dá pra voltar no tempo ou simplesmente apagar aquele universo alternativo sem afetar a realidade principal.

🗂️Controle de versão

Git consiste no entendimento sobre o que é controle de versão. Ele é um sistema que registra todas as alterações feitas em arquivos ao longo do tempo, permitindo que você:

Controle a versão do seu sistema, podendo navegar entre todas as versões;
Volte a versões anteriores do seu código ou projeto;
Compare mudanças entre versões;
Trabalhe em equipe sem sobrescrever o trabalho de outras pessoas;
Entenda quem fez o quê e por que fez;
Crie ramificações (branches) para desenvolver novas funcionalidades sem afetar o código principal.

Suponha que você esteja desenvolvendo um site. No dia 1, você cria a homepage. No dia 2, você altera o layout, mas algo quebra. Com o controle de versão, você pode voltar facilmente para a versão anterior sem ter que refazer tudo.

🌍 Main: Nosso universo principal

A main (ou master, em alguns projetos) funciona como o Universo principal . É nela que está o código oficial, aquele que representa a versão mais estável e pronta para ir à produção. Podemos considerá-la o coração do sistema.

Ao iniciar um repositório Git, a main geralmente é criada automaticamente como a primeira branch. Ela serve como referência central, o ponto de encontro onde todo o código que realmente "vale" acaba sendo integrado. É comum que só o que estiver bem testado e aprovado chegue até ela, justamente para manter a estabilidade do projeto.

Por que a Main é importante?

Código estável: a main costuma conter a versão pronta para produção ou a mais estável do projeto.
Base para outras branches: geralmente, novas funcionalidades ou correções são feitas em outras branches e depois unidas (mergeadas) à main.

🪐 Branches: nosso universo paralelo

No mercado de trabalho, usamos constantemente o conceito de branches, que nada mais são do que ramificações da main — o nosso universo principal. Em outras palavras, é como se você criasse um universo paralelo a partir da realidade atual do projeto. Nesse novo universo, você pode mexer à vontade, testar ideias, quebrar coisas, reconstruir... tudo sem afetar o universo original.

Cada branch é como uma realidade alternativa onde um desenvolvedor (ou uma equipe inteira) pode trabalhar em uma funcionalidade específica. É como se, em vez de todo mundo ficar mexendo na mesma realidade ao mesmo tempo (e correndo o risco de causar um caos temporal), cada um criasse sua própria linha do tempo para desenvolver tranquilamente.

Criando e Gerenciando Branches

Pessoalmente, costumo utilizar duas formas diferentes para criar branches, dependendo do que estou fazendo no momento.

🌍Criar a Branch sem sair da atual.

git branch nome-da-branch

🌍Criar e já ir pra nova Branch: (mais utilizado)

git checkout -b nome-da-branche

🌍Trocando de branches

git checkout nome-da-branch

🌍Lista todas a suas branches

git branch

Agora você pode realizar suas alterações e testar à vontade, sem se preocupar em quebrar o código principal. Afinal, você está em um universo paralelo.

🔀 Fluxos de Trabalho com Branches

Agora que já entendemos o conceito de universo paralelo com as branches, vamos falar sobre como organizar tudo isso de forma eficiente: os fluxos de trabalho com branches.

Na prática, quando estamos trabalhando em equipe (ou mesmo sozinhos em projetos maiores), não basta sair criando universos paralelos aleatoriamente. É preciso seguir um plano, uma linha do tempo organizada. Esses planos são chamados de fluxos de trabalho (workflows), e existem algumas abordagens bastante usadas no mercado.

Feature Branch Workflow

Esse é um dos mais comuns. Aqui, para cada nova funcionalidade que você vai desenvolver, cria-se uma branch específica — chamada de feature branch.

É como se cada nova ideia tivesse seu próprio universo temporário. Você trabalha nela até ficar pronta, e depois faz o merge de volta para a main ou para uma branch de desenvolvimento.

Exemplo:

1.🌍 Vá para a branch principal

git checkout main
git pull origin main

2.🌍 Crie uma branch para a nova feature

git checkout -b feature/nome-da-feature

3.📤 Faça alterações, commits e envie pro remoto

git add .
git commit -m "feat: descrição"
git push origin feature/nome-da-feature

4.🔀 Crie um Pull Request e faça o merge após revisão.

Git Flow

O Git Flow é como um verdadeiro multiverso organizado. Ele define regras claras sobre quando e como criar branches:

🌍main: o universo estável, com o código pronto para produção.
🌍develop: uma realidade onde tudo está sendo preparado, mas ainda não está pronto para ser lançado.
🌍feature: galhos que saem da develop para desenvolver novas funcionalidades.
🌍release: universos de transição, onde são feitos os ajustes finais antes de ir para produção.
🌍hotfix: ramificações emergenciais para corrigir algo crítico direto na main.

Esse fluxo é ótimo para projetos grandes e equipes com muitos desenvolvedores, pois garante controle e organização.

GitHub Flow

Mais simples e direto, o GitHub Flow parte da ideia de que a main está sempre pronta para produção. Para qualquer alteração, você cria uma branch, faz as mudanças, testa, e abre um pull request para revisar e unir à main.

É como abrir um portal para o universo principal — mas só passa por ele quem tiver aprovação dos guardiões (o time de revisão!).

🧹 Boas Práticas com Branches: cuidando bem dos seus universos paralelos

Assim como em qualquer multiverso bem organizado, cada universo paralelo (ou branch) precisa ter um propósito claro e um nome que faça sentido. Nada de criar realidades aleatórias sem saber o que existe lá dentro!

📝 Dê nomes claros e objetivos para suas branches

O nome da sua branch é como o título de um capítulo: ele deve deixar claro o que está acontecendo ali, sem que ninguém precise abrir o código para entender. Branches bem nomeadas facilitam a colaboração, a revisão de código e a organização geral do projeto.

Bons exemplos:

✅feature/login-usuario → criando a funcionalidade de login
✅fix/ajuste-layout-footer → corrigindo o layout do rodapé
✅hotfix/erro-500-api → consertando um erro crítico na API

Evite nomes como:

🚫teste1
🚫nova-branch
🚫coisas-aleatorias

Esses nomes são como portais sem placas: ninguém sabe pra onde levam.

🎯 Crie branches com objetivos específicos

Cada branch deve ser criada com um propósito bem definido, como se fosse uma missão individual no seu multiverso. Em vez de juntar várias tarefas diferentes em uma única realidade, separe cada funcionalidade ou correção em sua própria branch.

Exemplo prático:

🌍Crie uma branch só para criar a página de login
🌍E outra separada para ajustar a cor de um botão

Por que isso é importante?

✅ Facilita os testes e o processo de revisão de código (code review)
✅ Reduz as chances de conflito entre diferentes partes do código
✅ Deixa o histórico do Git mais limpo e organizado

Trabalhar com branches pequenas e objetivas é como montar um quebra-cabeça: cada peça tem seu lugar certo e propósito único. E só quando todas estão prontas, elas se encaixam perfeitamente na main.

🚫 Evite trabalhar diretamente na main

Lembre-se: a main é o universo estável do seu projeto. É onde está o código final, pronto para ser enviado à produção. Fazer alterações diretamente nela é como mexer na linha do tempo oficial sem nenhuma segurança — e isso pode gerar problemas sérios, especialmente se você estiver:

🌍Testando funcionalidades novas
🌍Corrigindo erros ainda não revisados
🌍Refatorando trechos do código

A melhor prática é sempre criar um universo paralelo (uma branch!) para fazer qualquer alteração, e só depois de testado e revisado, fundir de volta à main com um merge bem feito.

🌌 Merge: mesclando os universos

Lembra do exemplo do universo paralelo, O merge é o processo de juntar o conteúdo de uma branch com outra.

Geralmente, usamos o merge pra trazer as alterações que fizemos em uma branch secundária (ex: feature/login) para a branch principal (main), depois que tudo já foi testado e validado.

Exemplo no mercado: Você criou uma cópia (uma branch) do seu projeto pra desenvolver uma nova funcionalidade. Trabalhou nela, testou, deu tudo certo. Agora quer trazer essas mudanças de volta pra base do projeto. Pra isso, você faz um merge

Passo a passo para fazer merge:

1.Atualize seu repositório local :

git pull origin main

Antes de qualquer coisa, certifique-se de que sua cópia do projeto está atualizada com a versão mais recente da main:

2. Vá para a branch main:

git checkout main

Você precisa retornar ao universo principal antes de iniciar o merge:

3. Faça o merge da sua branch:

git merge nome-da-sua-branch

Agora sim, chegou a hora de unir os universos! Faça o merge da sua branch com a main:

4.Apague a branch (boa prática após o merge)

git branch -d nome-da-sua-branch         # local
git push origin --delete nome-da-sua-branch  # remoto

Depois de mesclar, é uma boa prática remover a branch que já cumpriu sua missão

Isso ajuda a manter o multiverso do seu repositório limpo e organizado.

Pronto! Universos mesclados com sucesso. Agora o código atualizado está na main, pronto para seguir para produção ou ser utilizado por toda a equipe.

⚔️ Conflitos

Tudo parece lindo no mundo das branches... até que dois universos tentam existir no mesmo lugar ao mesmo tempo. É aí que surgem os famosos conflitos de merge.

Mas calma! Isso não é o fim do mundo — é só o Git pedindo sua ajuda pra decidir qual realidade deve prevalecer.

Um conflito de merge acontece quando duas branches modificam a mesma parte do código e o Git não consegue decidir sozinho qual versão manter.

Como identificar um conflito?

Quando o conflito acontece, o Git pausa o merge e mostra os arquivos afetados com marcações especiais dentro do código, assim:

Essas marcações indicam as duas versões em conflito. Cabe a você resolver, escolhendo uma delas (ou até mesmo juntando as duas), e depois salvar o arquivo corrigido.

Como resolver um conflito?

1.📄 Abra o arquivo indicado pelo Git

O Git vai mostrar quais arquivos estão em conflito. Abra-os no seu editor.

2.✍️ Edite o conteúdo

Escolha qual versão manter ou combine as duas.

3.❌ Apague as marcações do Git

Remova os símbolos de conflito:

<<<<<<< HEAD
Seu código atual
=======
Código vindo da outra branch
>>>>>>> nome-da-branch

4.💾 Salve o arquivo

5. ✅ Finalize o merge

Marque o conflito como resolvido e finalize o merge:

git add nome-do-arquivo
git commit

Pronto! Conflito resolvido, e os universos seguem em paz. 🌌

♻️Merge vs Rebase – A Guerra dos Universos

Ambos servem para integrar alterações de uma branch em outra, mas fazem isso de formas diferentes.

🔀Merge: Unindo dois universos paralelos

Quando você usa git merge, está dizendo:

"Vamos unir esses dois universos com tudo que aconteceu neles — inclusive os caminhos diferentes que cada um percorreu."

✨ Resultado: Um universo novo onde tudo existe, mas dá pra ver que eles vieram de linhas do tempo separadas. Isso cria um registro histórico do multiverso, com um commit de fusão marcando o encontro dos mundos.

🧼Rebase: Viagem no tempo e reescrita da linha do tempo

Aqui, você está pegando sua feature e voltando no tempo até o momento em que a main foi criada.

“E se minha feature tivesse nascido direto da linha do tempo principal, como se esse universo alternativo nunca tivesse existido?”

✨ Resultado: Uma realidade linear e limpa, como se tudo tivesse acontecido em uma única sequência de eventos — sem registros de multiverso.

Prefira usar o merge quando o objetivo for preservar o histórico real da colaboração, mantendo visível a origem de cada mudança e a sequência das contribuições. Já o rebase é ideal quando se busca um histórico mais limpo e linear, facilitando a leitura do projeto — porém, ele deve ser evitado em branches compartilhadas, pois reescreve o histórico e pode causar confusão ou conflitos entre membros da equipe.

🧠Conclusão

Trabalhar com branches e merge é parte essencial do dia a dia de quem desenvolve software. Entender bem esses conceitos vai muito além de saber os comandos — trata-se de organizar seu trabalho, colaborar com mais segurança e manter um histórico limpo e confiável do projeto.

Ao dominar o uso de branches, você ganha liberdade para testar novas ideias, corrigir erros e evoluir o sistema sem medo de quebrar o que já está funcionando. Já com o merge, você consegue unir esforços de forma controlada, garantindo que tudo esteja validado antes de ir pra produção.

Adotar boas práticas, como usar prefixos claros, manter branches pequenas e saber quando usar merge ou rebase, faz toda a diferença na qualidade do código e na produtividade da equipe.

Caso você queira se aprofundar ainda mais nos conceitos sobre Git, aqui mesmo na plataforma da DIO temos o curso "Versionamento de Código com Git e GitHub", que é completo e prático, abordando os principais conhecimentos que você precisa para atuar como um profissional no mercado.No fim das contas, Git é uma ferramenta poderosa, e saber tirar proveito dela vai te destacar como desenvolvedor. Use com consciência, explore os comandos.

- K.A.I.Z.E.N -

significa: "a melhoria contínua."

📚REFERENCIAS:

https://git-scm.com/docs/git-branch

https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging

🔗MEUS LINKS:

REPOSITORIO