Introduction

Merging master into main is just a normal Git branch merge, but it usually happens during branch renaming, repository cleanup, or migration to a new default branch. The safe workflow is to update your local refs, switch to main, merge master into it, resolve any conflicts, and then push the updated main branch.

Basic Merge Workflow

Start by fetching the latest remote state:

git fetch origin

Then switch to main:

git switch main

Make sure main is current:

git pull origin main

Now merge master into main:

git merge master

If there are no conflicts, push the result:

git push origin main

That is the normal answer when both branches already exist locally.

If Local Branches Are Missing or Out of Date

Sometimes you only have remote-tracking branches or stale local copies. In that case, create or refresh local branches first:

1git fetch origin
2git switch -c main origin/main
3git branch -f master origin/master
4git merge master

The point is to avoid merging outdated local history by accident.

Understanding the Direction of the Merge

"Merge master into main" means:

• 'main is the checked-out destination branch'
• 'master is the source branch whose commits are being integrated'

So the important command is:

git switch main
git merge master

If you do the reverse, you are updating master, not main.

Handling Conflicts

If Git reports conflicts, inspect them:

git status

Open the conflicting files, resolve the merge markers, then stage the resolutions:

git add path/to/file

Complete the merge:

git commit

In many repositories, the merge commit message will already be prepared for you. If the repository enforces linear history, you may need a rebase-based workflow instead of a merge commit.

Fast-Forward Versus Merge Commit

If main has not diverged from master, Git may perform a fast-forward merge. That simply moves the main branch pointer forward.

If both branches have unique commits, Git creates a merge commit unless you choose another strategy. Both outcomes are normal. The correct one depends on repository history and policy.

When Renaming Is the Real Goal

Sometimes the real goal is not to keep both branches forever, but to move the project from master to main. In that case, after confirming main contains everything needed, teams often:

• update the remote default branch
• update CI configuration
• retarget pull requests
• eventually delete the old master branch

That operational cleanup is often more important than the merge command itself.

Common Pitfalls

The most common mistake is merging in the wrong direction. If master should feed into main, then main must be checked out during the merge.

Another mistake is forgetting to fetch first, which can cause you to merge stale local branches instead of the latest remote state.

People also assume a merge is enough during a branch-renaming migration. In reality, branch protection rules, CI jobs, GitHub settings, and local developer workflows may still reference the old default branch.

Finally, do not force-push unless you actually intend to rewrite shared history. A normal merge does not require that.

Summary

• To merge master into main, check out main and run git merge master.
• Fetch and update local branches first so you are merging the latest history.
• Resolve conflicts on main, then push the result.
• Be explicit about merge direction to avoid updating the wrong branch.
• If this is part of a default-branch migration, remember the repository settings and CI cleanup too.