What merging does and when you need it

Merging combines the changes from one branch into another — usually bringing work from a feature branch back into your main branch so everyone uses the updated code. When you merge, GitHub takes all the commits (saved changes) from one branch and adds them to the other. The most common merge is pulling a finished feature back into your main branch after review.

You merge when a feature is complete and tested, when a bug fix is ready for production, or when you want to bring in changes that another team member finished. Without merging, branches stay separate and your codebase stays fragmented — people work on different versions that never come together.

Key Takeaways

  • The simplest merge happens on GitHub itself through a pull request, where you open a comparison, request review, and click the merge button once approved.
  • A merge conflict occurs when the same lines of code were changed differently in both branches, and you must manually choose which version to keep.
  • GitHub offers three merge strategies: create a merge commit (the default, which keeps all history), squash commits (combines all changes into one), or rebase (replays changes on top of the main branch).
  • After merging, you can delete the old branch to keep your repository clean, since the changes now live in the main branch.

Merging through a pull request on GitHub

The standard way to merge is through a pull request, which is GitHub's way of saying "I have changes ready — please review them before I merge." Open your repository, click the "Pull requests" tab, and click "New pull request." Select the branch you want to merge from (your feature branch) and the branch you want to merge into (usually main or master).

GitHub shows you a summary of all the commits and changes. Write a title and description so reviewers understand what you changed and why. Click "Create pull request." Now team members can review your code, leave comments, and request changes. Once someone approves it, click the green "Merge pull request" button. GitHub merges the branches and closes the pull request automatically.

This method is safer than merging from the command line because it forces a review step — someone else sees the changes before they go into the main branch. It also creates a record of what was merged and when.

Handling merge conflicts

A merge conflict happens when you and someone else edited the same lines in the same file differently. GitHub cannot automatically decide which version is correct, so it stops the merge and asks you to choose. You will see a message like "This branch has conflicts that must be resolved before merging."

Click "Resolve conflicts" on the pull request page. GitHub shows you the conflicting sections marked with <<<<<<<, =======, and >>>>>>> symbols. The top section (between <<<<<<< and =======) is your change. The bottom section (between ======= and >>>>>>>) is the change from the other branch. Delete the symbols and the lines you do not want to keep, leaving only the correct version. Click "Mark as resolved" and then "Commit merge."

If conflicts are complex, you can also resolve them on your computer using a text editor or a merge tool, then push the resolved version back to GitHub. Many developers find this easier for large conflicts.

Understanding merge strategies

GitHub offers three ways to merge, each leaving a different history in your repository. The default is Create a merge commit, which keeps every commit from both branches and adds a new "merge commit" that ties them together. This preserves the full history and makes it straightforward to see when features were merged.

Squash and merge combines all commits from your feature branch into a single commit before merging. Use this when you have many small commits that do not need individual history — it keeps the main branch cleaner and easier to read. Rebase and merge replays all your commits on top of the main branch as if you had started from the latest version. This creates a linear history with no merge commits, which some teams prefer for clarity.

Choose based on your team's preference. Most teams use the default merge commit method because it shows when work was integrated. Squash is useful for feature branches with messy commit histories. Rebase is less common but preferred by teams that want a straight timeline.

Deleting branches after merging

Once you merge a branch, you can delete it to avoid clutter. GitHub offers a button to delete the branch right after the merge completes. You can also delete it manually by going to the "Branches" tab, finding the branch, and clicking the trash icon next to it.

Deleting a merged branch does not lose any work — all the changes are now in the main branch. It just removes the pointer to that old branch. This keeps your repository organized and makes it easier to see which branches are still active.

Merging from the command line

If you prefer working in the terminal, you can merge locally and push the result to GitHub. First, switch to the branch you want to merge into (usually main) by typing git checkout main. Then type git merge feature-branch-name, replacing "feature-branch-name" with the actual name of your branch.

Git merges the branches on your computer. If there are no conflicts, the merge completes and you can push it to GitHub with git push origin main. If there are conflicts, resolve them in your text editor the same way as on GitHub, then type git add . and git commit -m "Merge feature-branch-name" to finish.

Command-line merging is faster once you are comfortable with it, but pull requests on GitHub are safer for team projects because they enforce review.

Common mistakes and how to avoid them

The most common mistake is merging into the wrong branch — always double-check which branch you are merging into before clicking the button. Another is merging without reviewing changes first, which can introduce bugs or unwanted code into the main branch. Always use pull requests and wait for approval.

Forgetting to delete old branches clutters your repository and makes it hard to see what is actually being worked on. Set a team rule to delete branches after merging. Finally, do not merge branches that have conflicts without resolving them first — conflicts do not disappear on their own, and unresolved code will not work correctly.

Frequently Asked Questions

What happens to my commits when I merge?

With a regular merge commit, all your commits stay in the history and a new merge commit is added. With squash and merge, all your commits combine into one. With rebase and merge, your commits are replayed on top of the main branch. In all cases, your changes end up in the main branch — only the history looks different.

Can I undo a merge after it is complete?

Yes. On the pull request page, scroll down and click "Revert" to undo the merge. This creates a new commit that reverses all the changes from the merge. You can also use git revert -m 1 commit-hash from the command line if you know the merge commit's hash.

What if I merge the wrong branch by accident?

Use the revert option to undo it when ready. This creates a new commit that removes the unwanted changes. Then merge the correct branch. Reverting is safer than trying to manually undo a merge because it creates a clear record of what happened.

Do I have to use pull requests to merge?

No, you can merge from the command line without a pull request. But pull requests are safer for team projects because they require review before merging. For solo projects or local work, command-line merging is fine.

Why would I use squash and merge instead of a regular merge?

Squash and merge keeps your main branch history cleaner by combining many small commits into one. Use it when your feature branch has lots of work-in-progress commits that do not need individual history. Regular merge is better when you want to preserve the full timeline of work.