How to Merge Branches in GitHub: A Complete Guide

Merging branches is one of the most fundamental workflows in GitHub — and one of the most misunderstood. Whether you're working solo on a side project or collaborating across a team, knowing how merging works (and what can go wrong) makes the difference between clean version control and a tangled commit history.

What Does Merging Branches Actually Mean?

In Git, a branch is an independent line of development. You might create a branch to build a new feature, fix a bug, or experiment with an idea — without touching the main codebase. Merging is the process of integrating the changes from one branch into another.

The branch you're merging into is typically called the base branch (often main or master). The branch carrying your new changes is the compare branch or feature branch.

When you merge, Git takes the commit history from both branches and combines them. If the changes don't overlap, this happens automatically. If they do overlap, Git flags a merge conflict that requires manual resolution.

Two Main Ways to Merge Branches in GitHub

1. Merging via a Pull Request (Recommended)

The pull request (PR) workflow is GitHub's native, collaborative approach to merging. It creates a formal review process before any changes reach the base branch.

Steps:

1. Push your feature branch to GitHub
2. Navigate to your repository and click "Compare & pull request" (GitHub often prompts this automatically)
3. Set the base branch (where changes go) and the compare branch (your feature branch)
4. Add a title and description
5. Request reviewers if working in a team
6. Once approved, click "Merge pull request"

GitHub offers three merge options inside a pull request:

Each option produces a different commit structure in your repository history — the right choice depends on your team's conventions and how much granularity you want in the log.

2. Merging via the Command Line

If you prefer working locally or need more control, Git's command line gives you direct access to the merge process.

Basic merge workflow:

git checkout main # Switch to the branch you're merging INTO git pull origin main # Make sure it's up to date git merge feature-branch # Merge your feature branch into main git push origin main # Push the updated main branch to GitHub 

This mirrors what GitHub does through the PR interface, but executed locally. After pushing, your merged changes appear on GitHub.

🔀 Understanding Merge Conflicts

A merge conflict occurs when two branches have made changes to the same part of the same file. Git can't automatically decide which version to keep, so it pauses the merge and asks you to resolve it.

Conflict markers look like this in your file:

<<<<<<< HEAD Your current branch's version of the code ======= The incoming branch's version of the code >>>>>>> feature-branch 

You manually edit the file to keep the correct version (or a combination of both), remove the markers, then commit the resolved file.

GitHub has a built-in web editor for resolving simple conflicts — useful for non-critical text changes. More complex conflicts typically need a local editor or a dedicated merge tool like VS Code's built-in diff viewer.

Variables That Affect How You Should Merge

Not every merge scenario is the same. Several factors change the best approach:

• Team size — Solo developers can merge freely; teams benefit from required PR reviews and branch protection rules
• Branch protection settings — GitHub allows repository admins to require approvals, passing CI checks, or linear history before a merge is allowed
• Commit history philosophy — Some teams value a detailed, granular history; others prefer a clean linear log using squash or rebase merges
• Project maturity — Production repositories often have stricter merge controls than experimental or personal ones
• CI/CD pipelines — If automated tests run on PRs, merging before tests pass can introduce broken code to the main branch
• Technical skill level — Rebase merges are powerful but rewrite commit history, which can cause problems if the branch has already been shared with others

🛡️ Branch Protection and Merge Rules

GitHub's branch protection rules let repository owners enforce merge standards. Common settings include:

• Require pull request reviews before merging
• Require status checks (like automated tests) to pass
• Require branches to be up to date before merging
• Restrict who can push directly to the base branch

These settings live under Settings → Branches in your GitHub repository. They're particularly important for open-source projects or any codebase where multiple contributors are actively pushing changes.

After the Merge: Cleanup

Once a branch has been merged, it's generally good practice to delete it. GitHub offers a one-click delete button immediately after a PR merge. Leaving stale branches around isn't harmful, but it creates clutter and makes repository navigation harder over time.

Locally, you can clean up with:

git branch -d feature-branch # Delete local branch git fetch --prune # Remove remote tracking references 

The mechanics of merging are consistent across GitHub — the same underlying Git operations, the same conflict resolution logic. What varies significantly is how those mechanics fit into your specific project structure, team agreements, and deployment workflow. A solo developer merging a quick fix operates very differently from a team running mandatory CI checks and multi-reviewer approvals on every pull request. 🔧