Saber dar git commit e git push é o começo, mas o trabalho real começa quando várias pessoas mexem no mesmo código ao mesmo tempo. É aí que branches, merge, rebase e fluxos de trabalho entram em cena. Entender essas peças evita conflitos dolorosos e mantém o histórico do projeto limpo e compreensível.
Commit e branch: a base
Um commit é uma fotografia do código em um momento. Uma branch é uma linha de desenvolvimento independente — uma forma de trabalhar numa funcionalidade sem afetar o código estável. Criar uma branch é barato e rápido, e essa é justamente a graça do Git.
Knowing how to run git commit and git push is just the beginning; the real work starts when several people touch the same code at the same time. That is where branches, merge, rebase and workflows come into play. Understanding these pieces avoids painful conflicts and keeps the project history clean and easy to follow.
Commit and branch: the basics
A commit is a snapshot of the code at a moment in time. A branch is an independent line of development — a way to work on a feature without affecting the stable code. Creating a branch is cheap and fast, and that is precisely the beauty of Git.
git switch -c feature/login # cria e entra na branch
git add .
git commit -m "adiciona tela de login"Merge vs rebase
Os dois servem para juntar o trabalho de uma branch na outra, mas de formas diferentes. O merge cria um commit de junção e preserva o histórico real. O rebase reescreve os commits da sua branch como se tivessem nascido a partir do topo da outra, gerando um histórico linear. É comum em entrevista pedir para explicar a diferença e quando usar cada um.
| Aspecto | Merge | Rebase |
|---|---|---|
| Histórico | Preserva (com commit de merge) | Reescreve (linear) |
| Rastreabilidade | Mostra quando algo foi integrado | Histórico mais limpo, perde o "quando" |
| Risco | Seguro em branches compartilhadas | Perigoso em branches já publicadas |
| Uso típico | Trazer feature para a main | Atualizar sua branch local antes do PR |
A regra de ouro: nunca faça rebase de uma branch que outras pessoas já usam. Rebase reescreve a história, e reescrever história compartilhada quebra o trabalho dos colegas.
O que é um conflito
Um conflito acontece quando duas branches alteraram a mesma linha de um arquivo de formas diferentes. O Git não sabe qual versão é a certa e pede que você decida. Não é um erro — é uma situação normal que você resolve editando o arquivo e marcando como resolvido.
Merge vs rebase
Both are used to bring the work of one branch into another, but in different ways. Merge creates a merge commit and preserves the real history. Rebase rewrites your branch's commits as if they had been created on top of the other branch, producing a linear history. Interviewers often ask you to explain the difference and when to use each one.
| Aspect | Merge | Rebase |
|---|---|---|
| History | Preserved (with a merge commit) | Rewritten (linear) |
| Traceability | Shows when something was integrated | Cleaner history, loses the "when" |
| Risk | Safe on shared branches | Dangerous on already-published branches |
| Typical use | Bringing a feature into main | Updating your local branch before the PR |
The golden rule: never rebase a branch other people are already using. Rebase rewrites history, and rewriting shared history breaks your teammates' work.
What is a conflict
A conflict happens when two branches changed the same line of a file in different ways. Git doesn't know which version is right and asks you to decide. It's not an error — it's a normal situation that you resolve by editing the file and marking it as resolved.
<<<<<<< HEAD
porta = 8080
=======
porta = 3000
>>>>>>> feature/config
# escolha uma versão, apague os marcadores, git add e commitTrabalhando com o remoto
O repositório remoto (ex. GitHub) é a cópia compartilhada. Três comandos formam o vocabulário básico:
- push — envia seus commits para o remoto.
- pull — traz e já junta as mudanças do remoto.
- fetch — traz as mudanças sem juntar (você decide depois).
Diagrama de branches
Working with the remote
The remote repository (e.g. GitHub) is the shared copy. Three commands make up the basic vocabulary:
- push — sends your commits to the remote.
- pull — fetches and merges the remote's changes right away.
- fetch — fetches the changes without merging (you decide later).
Branch diagram
main A---B---C-------F (F = merge)
\ /
feature D---EA branch feature nasceu de B, recebeu os commits D e E, e foi integrada em F via merge.
Fluxos de trabalho
Não basta saber os comandos: equipes adotam um fluxo combinado. Os três mais comuns:
- Feature branch + Pull Request — cada tarefa em sua branch, revisada via PR antes de entrar na main. O padrão da maioria dos times.
- Trunk-based — todos integram com frequência numa única branch principal, branches vivem horas, não dias. Favorece CI/CD contínuo.
- GitFlow — branches separadas para develop, release e hotfix. Robusto, porém pesado; bom para releases versionadas.
Conclusão
Git é a memória do projeto e a forma como o time colabora. Entender merge vs rebase, saber resolver conflitos sem pânico e conhecer os fluxos de trabalho são habilidades que você usa todos os dias. Um histórico limpo e um fluxo bem definido tornam o trabalho de todos — incluindo o pipeline de CI/CD — muito mais previsível.
The feature branch was created from B, received commits D and E, and was integrated into F via merge.
Workflows
Knowing the commands isn't enough: teams adopt an agreed-upon workflow. The three most common:
- Feature branch + Pull Request — each task on its own branch, reviewed via PR before entering main. The standard for most teams.
- Trunk-based — everyone integrates often into a single main branch, and branches live for hours, not days. Favors continuous CI/CD.
- GitFlow — separate branches for develop, release and hotfix. Robust but heavy; good for versioned releases.
Conclusion
Git is the project's memory and the way the team collaborates. Understanding merge vs rebase, knowing how to resolve conflicts without panic and knowing the workflows are skills you use every day. A clean history and a well-defined workflow make everyone's work — including the CI/CD pipeline — far more predictable.