This week, I built two features (Add last modified timestamp, Add --preview option )in separate Git branches for my Repopal project (it extracts files for LLMs). Both feature branches started from the same commit on main. After finishing them, I needed to merge both back into main because main is our release branch.
When I tried to merge the second feature, I hit a merge conflict. I’ve resolved conflicts many times, but I hadn’t really thought about why they happen.
A merge conflict happens when two branches change the same part of the same file, and Git can’t automatically decide which change to keep.
For example, if the parent commit has:
console.log();
Branch A changes it to:
console.log('print A');
Branch B changes it to:
console.log('print B');
Git doesn’t know whether to keep A, B, or both. It asks you to choose and create the final version. You can keep A, B, or even combine them—whatever makes sense.
While looking into branch and merge strategies, I found another approach using rebase:
git checkout your-feature-branch
git rebase main
Rebasing makes the main branch history look like a single straight line, which is easier to read. But it also rewrites history, so you lose the true record of how the work was originally developed and merged.
Top comments (0)