Introduction

Merging a branch into master means taking the commits from another branch and integrating them into the master history. The safe workflow is to update your local repository, switch to master, merge the source branch, resolve any conflicts, run verification, and only then push the result.

Core Sections

Start from a clean local state

Before merging, make sure your working tree is clean so unrelated local changes do not interfere with conflict resolution.

git status

If you have uncommitted work, either commit it or stash it before continuing.

Then fetch the latest remote state.

git fetch origin

This keeps you from merging against stale branch tips.

Switch to master and update it

The merge happens from the target branch, not from the source branch. So you check out master first.

git checkout master
git pull origin master

At this point, your local master should match the remote branch you are about to update.

Merge the source branch

Now merge the branch you want to bring in.

git merge feature-branch

If the histories have not diverged in a conflicting way, Git may perform a fast-forward merge or create a merge commit depending on the branch structure and your settings.

If you want to force a merge commit for clarity, use:

git merge --no-ff feature-branch

That can be useful when you want the branch integration to remain explicit in history.

Resolve conflicts if they appear

If Git reports conflicts, open the affected files, choose the correct final content, and mark them resolved.

git status
git add path/to/resolved-file
git commit

The merge commit message editor usually opens automatically when the conflict resolution is ready. Use that commit to record the finished merge.

Do not blindly accept one side without understanding the semantic effect of the change. Conflict markers are a code review moment, not just a text-editing task.

Verify before pushing

After the merge, run the checks that matter for the project:

• tests
• linting
• build steps
• local smoke checks for risky areas

Then inspect the result.

git log --oneline --graph --decorate -n 10

This confirms that master now contains the intended merge state.

Push the updated master

Once the merge is correct locally, push it.

Understand fast-forward versus merge commits

If master has not advanced since the feature branch was created, Git may simply move the master pointer forward. That is a fast-forward merge and it produces no new merge commit. If both branches have new commits, Git creates a merge commit that records both histories explicitly.

Neither mode is inherently more correct. Fast-forward history is linear and simple. Explicit merge commits preserve the branching structure. The right choice depends on how your team wants history to read.

git push origin master

At that point the remote master branch contains the merged result.

Common Pitfalls

• Starting the merge from the feature branch instead of from master, which leads to confusion about what was actually updated.
• Merging into an outdated local master and only discovering remote conflicts or missing commits afterward.
• Treating merge conflicts as a mechanical exercise instead of validating the combined code behavior.
• Pushing immediately after conflict resolution without running the project’s normal verification steps.
• Confusing a merge with a rebase and expecting the resulting history to look the same.

Summary

• Update your local repository and switch to master before merging.
• Merge the source branch from the target branch context.
• Resolve conflicts carefully and verify the integrated result locally.
• Push only after the merged master is tested and understood.
• Use --no-ff when you want the merge to remain explicit in history.