DevOps · Junior

Git beyond the commit: branches, merge, and workflows

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

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.

AspectMergeRebase
HistoryPreserved (with a merge commit)Rewritten (linear)
TraceabilityShows when something was integratedCleaner history, loses the "when"
RiskSafe on shared branchesDangerous on already-published branches
Typical useBringing a feature into mainUpdating 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 commit

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---E

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.

Read also

Back to track