Why Merge Conflicts Aren’t Scary—Messy Merges Are the Real Problem

When a feature branch is ready, it must be merged back into main. In the simplest case where main has not changed (e.g., main: A → B and feature: → C → D), git merge feature/login can fast‑forward without issues.

In real projects, other developers often push new commits to main (e.g., main: A → B → E) while you are working on the feature branch. When you then merge, Git must reconcile the two histories. If the changes affect different files, the merge succeeds; if they modify the same line or interdependent logic, a conflict occurs and Git prints CONFLICT .

The conflicted file contains markers such as:

<<<<<<< HEAD
const timeout = 3000
=======
const timeout = 5000
>>>>>>> feature/login

These indicate the current branch ( HEAD) version and the incoming feature/login version. The developer must decide which version to keep or rewrite a new one, then stage and commit:

git add .
git commit

To reduce conflicts, the author recommends several habits:

Run git pull origin main before starting development.

Do not keep a branch alive for too long before merging.

Limit each branch to a single feature.

Check git status before committing.

Review the diff carefully before merging.

Clear branch naming also helps; good examples are:

feature/login
feature/payment
fix/order-timeout
hotfix/api-crash

Whereas vague names like test, aaa, new, final version may save effort short‑term but cause long‑term pain.

After a feature is released, delete the local branch with git branch -d feature/login. To visualize the branch structure, use: git log --graph --oneline --all which is especially useful for newcomers to understand branch flow.

Three key takeaways:

Conflicts are not disasters; they simply require manual judgment.

Small, short‑lived branches and frequent synchronization reduce conflict likelihood.

Clear branch naming facilitates team collaboration and future maintenance.