If you think git merge is some mystical ritual performed by wizard developers you are half right and half wrong. It is mostly boring plumbing with occasional drama when conflicts show up. This guide keeps the facts correct and the tone slightly rude so you remember what to do next time your branches try to fight.

What git merge actually does

At its core git merge takes changes from one branch and combines them into another branch. That sounds boring but it matters for history and collaboration. There are two common merge personalities and both are useful in version control depending on how tidy you want your history to be.

Fast forward

A fast forward merge happens when the branch you are merging into has not moved since you created the feature branch. Git simply advances the branch pointer so no new commit is created. This keeps history linear and neat if you do not need to preserve the branch as a separate chapter.

Non fast forward and merge commits

When both branches have new commits git creates a merge commit that records the union of the two histories. This preserves the context of parallel work and is useful for tracking feature branches that deserve their own narrative in the log.

When conflicts arrive and what to do

Conflicts are the spicy part. They happen when the same lines were changed in different ways. The steps are boring but important and they work every time.

• Run git status to see the conflicted files
• Edit the files and decide which code to keep
• Stage your fixes with git add <file>
• Finish the merge with git commit if git did not auto commit

If you prefer visual help use git mergetool which launches a GUI merge helper that is less likely to make you cry at 2am.

Flags and merge strategies

Want to change merge behavior Use these common options

• git merge --no-ff feature-branch forces a merge commit so the feature branch shows up in history
• git merge --squash feature-branch collapses the branch into a single commit and keeps history linear and tidy

Pick the approach based on team preference and the importance of preserving branch context versus a simpler log.

Practical tips for fewer surprises

1. Pull remote changes before merging with git pull or fetch and rebase so conflicts appear early
2. Run tests locally after resolving conflicts and before pushing the merge
3. Write clear commit messages so git log reads like a helpful diary not a mystery novel

Which to prefer in daily work

Prefer merge commits for larger feature branches that deserve a recorded history. Prefer squash merge for small cleanup branches and tiny fixes that would only add noise. Both are fine if your team agrees and follows a consistent merge strategy.

Quick commands summary

git checkout main
git pull
git checkout -b feature-branch
# work and commit locally
git checkout main
git merge feature-branch
# if conflict follow the resolve workflow git status edit files git add git commit
# alternatives
git merge --no-ff feature-branch
git merge --squash feature-branch

In short git merge is predictable when you know the rules and a little annoying when you ignore them. Keep branches small when possible run tests before pushing and pick a merge strategy that your team can actually follow. Now go merge something and try not to cause a production incident.