A merge combines changes from two different branches into one

A merge is the act of taking code changes from one branch and folding them into another branch. Most often, you merge a feature branch back into your main branch after the work is finished. When you merge, the version control system — usually Git — compares the two branches, finds what changed in each one, and creates a new commit that holds both sets of changes together.

Think of it like this: you created a branch to work on a login form without breaking the main code. While you worked, someone else fixed a bug in the main branch. A merge takes your login form changes and combines them with that bug fix so the main branch has both.

Without merges, branches would stay separate forever. Merging is how work from different people and different tasks actually comes back together into a single, working codebase.

Key Takeaways

  • A merge takes changes from one branch and combines them with another branch, usually bringing feature work back into the main branch.
  • Most merges happen automatically if the two branches changed different parts of the code, but conflicts occur when both branches changed the same lines.
  • You perform a merge through a pull request (on platforms like GitHub) or by running merge commands in Git, depending on your workflow.
  • Merge conflicts are normal and fixable — they just mean you have to decide which version of a line of code to keep.

How a merge actually works

When you merge branch B into branch A, Git looks at three things: the original code before either branch existed, the current state of branch A, and the current state of branch B. It then figures out what changed in each branch and tries to combine those changes.

If branch A changed line 5 and branch B changed line 12, Git can usually merge without any problem — it just applies both changes. But if both branches changed line 5 in different ways, Git cannot decide which version is correct. That is a merge conflict, and you have to fix it by hand.

After you resolve any conflicts, Git creates a new commit on branch A that represents the merged state. That commit has two parents — one from each branch — which is how Git keeps track of where the code came from.

Merge conflicts and how to fix them

A merge conflict happens when the same lines of code were changed in different ways on two branches. Git stops the merge and marks the conflicted lines in your file so you can see both versions side by side.

To fix a conflict, you open the file, look at both versions, and decide which one to keep — or write a new version that combines the best of both. Then you remove Git's conflict markers (the <<<<<<< and >>>>>>> lines), save the file, and tell Git the conflict is resolved.

Conflicts are not a sign something went wrong. They are a normal part of working on a team. The more often you merge, the smaller each merge tends to be, and the fewer conflicts you run into.

Pull requests vs. command-line merges

On platforms like GitHub, GitLab, or Bitbucket, you do not merge by typing commands. Instead, you open a pull request — a proposal to merge one branch into another. Other people can review your code, leave comments, and ask for changes before the merge happens.

Once the pull request is approved, you click a button to merge. The platform handles the actual Git merge behind the scenes. This workflow gives your team a chance to catch problems before they reach the main branch.

If you are working alone or in a very small team, you might merge using Git commands in your terminal instead. The end result is the same — two branches become one — but you skip the review step.

Fast-forward merges vs. three-way merges

Git can perform two different kinds of merges depending on the situation. A fast-forward merge happens when the branch you are merging into has not changed since you created your feature branch. Git just moves the branch pointer forward to include your new commits — no new merge commit is created.

A three-way merge happens when both branches have new commits. Git creates a new commit that combines the changes from both branches. This is the most common type of merge on a team, because people are usually working on different things at the same time.

Most of the time you do not need to think about which type will happen. Git chooses automatically. But some teams configure their repositories to always create a merge commit, even for fast-forward situations, so the history is clearer.

When to merge and when to wait

You should merge a branch back into main as soon as the work is done and tested. Waiting too long means your branch falls further behind the main branch, which makes conflicts more likely and harder to fix.

Before you merge, make sure your code works, your tests pass, and someone has reviewed it if your team uses pull requests. If you merge broken code, it breaks the main branch for everyone else.

Some teams have rules about when merges can happen — for example, only during certain hours, or only after automated tests pass. Check your team's process before you merge.

Merge strategies and rebasing

A merge strategy is the way Git combines two branches. The default strategy works for almost all situations, but some teams use alternatives like squash merges (which combine all the commits from a branch into one) or rebase merges (which replay your commits on top of the main branch instead of creating a merge commit).

A rebase is different from a merge. Instead of combining two branches, rebasing takes your commits and replays them on top of another branch. This keeps the history cleaner and more linear, but it rewrites commit history, which can cause problems if other people are using your branch.

Most teams use regular merges for shared branches and rebasing for personal work. Ask your team which strategy they prefer before you start.

Frequently Asked Questions

What happens to my branch after I merge it?

Your branch still exists, but it is no longer needed. Most teams delete the branch after merging so the repository does not fill up with old branches. You can delete it yourself or configure your platform to delete it automatically when the merge is done.

Can I undo a merge?

Yes. You can use the git revert command to create a new commit that undoes the merge, or git reset to move the branch pointer back to before the merge happened. The method depends on whether other people have already pulled the merged code.

What if I merge the wrong branch?

If you have not pushed the merge yet, undo it with git reset and try again. If you have already pushed it, use git revert to undo it with a new commit. Tell your team what happened so they know to pull the revert.

Do I have to fix every merge conflict by hand?

Most conflicts you can fix by hand in a few seconds. Some tools can help you visualize conflicts better, but there is no way to avoid deciding which code to keep when two branches changed the same lines. That decision has to come from a person.

Why do I get conflicts when I merge if I am the only one working on the branch?

You can still get conflicts if the main branch changed while you were working on your feature branch. For example, if you both changed the same function, Git will not know which version is correct. Merge the main branch into your feature branch first to resolve conflicts before you merge back.