Branching, merging and conflicts

Why branches?

Imagine you are halfway through a new checkout page when an urgent bug is reported in production. Without branches, your half-finished code is mixed with the fix. With branches, the new page lives on its own line of work. You switch to a fresh branch from main, fix the bug, ship it, and come back to your page later. Nothing gets mixed up.

A branch is just a pointer

In Git, a branch is a tiny file that holds the ID of one commit. When you make a new commit on a branch, the branch label moves forward to the new commit. HEAD is another pointer: it says which branch you are on right now. That is why branches cost nothing to create, and why teams create many of them.

git branch                     # list branches; * marks the current one
git switch -c feature/upi-pay  # create a branch and switch to it
# ...edit, add, commit...
git switch main                # go back to main
git branch -d feature/upi-pay  # delete a branch that is already merged
git branch -D old-experiment   # force-delete, even if not merged (careful)

If you check out a commit ID instead of a branch name, Git says you are in "detached HEAD" state. You can look around, but new commits there belong to no branch. If you want to keep them, create a branch with git switch -c name before you leave.

Merging: fast-forward

You merge a branch into the branch you are on. If main has had no new commits since you created your feature branch, Git does not need a new commit: it just moves the main label forward to the tip of the feature branch. This is a fast-forward merge, and the history stays a straight line.

Merging: three-way merge

If both branches have new commits, Git finds their common ancestor (the merge base) and combines the changes from both sides since that point. It then creates a merge commit, a commit with two parents. git log --graph draws this as two lines joining.

git switch main
git merge feature/upi-pay
git log --oneline --graph --all
*   7d41c2e Merge branch 'feature/upi-pay'
|\
| * a19f0b3 Add UPI QR payment option
* | 5e2c8d1 Fix delivery charge for pin codes
|/
* 3f9c2ab Add checkout page

Merge conflicts

A conflict happens when both branches changed the same lines of the same file, or one deleted a file the other edited. Git cannot guess which version is right, so it stops and writes both versions into the file between conflict markers.

def delivery_charge(total):
<<<<<<< HEAD
    return 0 if total >= 499 else 40
=======
    return 0 if total >= 599 else 49
>>>>>>> feature/new-pricing

1. Run git status to see which files are in conflict ("both modified").
2. Open each file and decide the correct result. It may be one side, the other, or a mix. Talk to the person who wrote the other side if unsure.
3. Delete all three marker lines.
4. Run your tests, then git add the file to mark it resolved.
5. Run git commit (or git merge --continue) to finish the merge.

Common mistakes and how to fix them

• Long-lived branches cause big, painful conflicts. Merge small branches often, and bring main into your branch regularly.
• Working on main by accident? Create a branch where you are with git switch -c feature/x; your commits come with you. Then reset main to match the server version.
• Deleted a branch that was not merged? Find its last commit ID in git reflog and create the branch again.