Merging: combining two lines of work

Merging takes the commits from one branch and joins them into another. It's how a finished feature branch becomes part of main.

Remember branches are side roads (see branch). You built feat/upi-payments off to the side. Now it's done and reviewed. Merging is bringing that side road back into the main road, so main now includes your UPI feature.

The everyday case

Most of the time on Sangam-Git you merge by clicking Merge pull request on the website — you don't type commands. But it helps to understand what happens.

On the command line it looks like this:

git switch main          # go to the branch you want to merge INTO
git merge feat/upi-payments   # bring the feature branch's commits in

Now main contains everything from your feature branch.

Two kinds of merge

Fast-forward — if main hasn't changed since you branched, Git just slides main forward to include your commits. Clean and simple:

before:  main → C          feat → C─D─E
after:   main ───────────────────► E

Merge commit — if both branches moved on (you added commits, and teammates also added to main), Git combines the two histories and creates a special merge commit to tie them together:

main:  A─B─C─────────M
              \     /
feat:          D─E─

M is the merge commit. It has two parents — one from each branch — and marks the point where the two lines became one.

Merge conflicts (don't panic)

Sometimes you changed a line and a teammate changed the same line differently. Git can't guess who's right, so it stops and asks you. This is a merge conflict. It's normal, it's common, and it has its own page — because it's the part beginners fear most and need least to.

Merge vs squash

When merging a pull request, Sangam-Git offers two styles:

• Create a merge commit — keeps every commit from your branch, plus a merge commit. Full detail preserved.
• Squash and merge — combines all your branch's commits into one tidy commit on main. Great when your branch had ten messy "wip" commits and you want main's history clean.

Neither is "correct" — teams pick a style. Squash keeps main readable; merge commits keep every step.

After the merge

Once your branch is merged, it has served its purpose. You can safely delete it:

git branch -d feat/upi-payments

The commits aren't lost — they're part of main now. You're just removing the finished side road's signpost.

In short: merging is the happy ending of a branch. You split off to work in peace, then merge to bring the finished work home.