What merging does and when you need it

Merging combines the work from two branches into one. You create a branch to work on a feature without affecting the main code, then merge it back when the feature is ready. Git compares the changes in both branches, combines them, and creates a new commit that holds the result.

The most common scenario: you have a main branch (the stable version everyone uses) and a feature branch (where you added a new button, fixed a bug, or rewrote a section). When your work is done and tested, you merge the feature branch back into main so the changes become part of the official code.

Merging is also how teams share work. If two people worked on different features in different branches, merging brings both sets of changes together. Git handles the combination automatically unless both people changed the same lines — in that case, you resolve the conflict by choosing which version to keep.

Key Takeaways

  • The basic merge command is git merge branch-name, run from the branch you want to merge into (usually main).
  • Before merging, switch to the branch that will receive the changes using git checkout main or git switch main.
  • If both branches changed the same lines, Git stops and marks the conflict — you edit the file to choose which version to keep, then complete the merge.
  • A merge creates a new commit that records both parent branches, so your history shows exactly when and how the branches came together.

The basic merge in four steps

Start by switching to the branch that will receive the changes. If you are merging a feature branch into main, switch to main first. Open your terminal in your project folder and type:

git checkout main

Or if your Git version is recent (2.23 or later), the newer command is:

git switch main

Both do the same thing — they move you to the main branch. You will see your file list update to match the main version. Now pull the latest changes from the server (if you are working with others) by typing:

git pull

This ensures main is up to date before you merge. Now run the merge command, replacing feature-name with your actual branch name:

git merge feature-name

Git will either complete the merge silently (if there are no conflicts) or show you a message about conflicts that need your attention. If the merge succeeds, you will see a message like "Merge made by the 'ort' strategy" or similar. Your feature branch still exists — merging does not delete it.

Understanding what happens when there are no conflicts

When both branches changed different files or different parts of the same file, Git combines them automatically. It creates a new commit (called a merge commit) that has two parents — one from main and one from your feature branch. This commit records that the merge happened and when.

You can see this in your history by typing:

git log --oneline

You will see a line showing the merge commit, usually with a message like "Merge branch 'feature-name' into 'main'". The history now shows that both branches existed and came together at that point. This is useful later when you need to understand how the code evolved.

After a successful merge, you can delete the feature branch if you no longer need it. Type:

git branch -d feature-name

This removes the branch locally. If you pushed it to a server (like GitHub), you can delete it there too through the web interface, or by typing git push origin --delete feature-name.

Resolving conflicts when both branches changed the same lines

If you and a teammate both edited the same line in the same file, Git cannot automatically decide which version to keep. When you run the merge command, Git stops and marks the conflict in the file itself. You will see a message like "CONFLICT (content): Merge conflict in filename.txt".

Open the conflicted file in your editor. You will see sections marked with <<<<<<<, =======, and >>>>>>>. The section between <<<<<<< and ======= is your current branch's version. The section between ======= and >>>>>>> is the version from the branch you are merging in. Delete the markers and the version you do not want, keeping only the code that should be there.

For example, if the conflict looks like this:

<<<<<<< HEAD const color = "blue"; ======= const color = "red"; >>>>>>> feature-name

You decide which color is correct, delete the markers and the wrong version, and save the file. If the right answer is to keep both (for example, if they are different variables), edit it to make sense:

const primaryColor = "blue"; const secondaryColor = "red";

After you fix all conflicts in all files, tell Git you are done by typing:

git add .

Then complete the merge with:

git commit

Git will open an editor showing a default merge commit message. You can accept it or edit it to explain what you chose and why. Save and close the editor, and the merge is complete.

Checking what will merge before you commit

If you want to see what changes will come in before you actually merge, use the diff command. While on main, type:

git diff main feature-name

This shows every line that will change. Lines starting with + are additions from the feature branch. Lines starting with - are removals. This is useful if you are nervous about a merge or want to understand exactly what is coming in.

You can also see which files will be affected without seeing every line change:

git diff --name-only main feature-name

This lists just the filenames, which is faster if the changes are large. If you see a file you did not expect, you can ask the person who worked on that branch why they changed it before you merge.

Undoing a merge that went wrong

If you merged and then realized it was a mistake, you can undo it. If you have not pushed to a shared server yet, the simplest fix is:

git reset --hard HEAD~1

This moves main back one commit, erasing the merge as if it never happened. Use this only if no one else has pulled the merge yet — if teammates already have it, resetting causes problems for them.

If the merge is already on a shared server or you want to keep the history visible, use revert instead:

git revert -m 1 HEAD

This creates a new commit that undoes the merge, so the history shows that the merge happened and was then reversed. This is safer for shared work because it does not rewrite history that others might have already pulled.

Frequently Asked Questions

Do I have to delete the feature branch after merging?

No. Deleting it is optional and is usually done for cleanliness — to keep the branch list from getting cluttered with old work. If you might need to refer back to that branch later, you can leave it. Most teams delete feature branches after merging because the work is now in main and the branch is no longer needed.

What is the difference between merge and rebase?

Merge creates a new commit with two parents, showing that two branches came together. Rebase replays one branch's commits on top of another, creating a straight-line history with no merge commit. Merge is safer for shared branches because it preserves history. Rebase makes history cleaner but should not be used on branches that others are working on.

Can I merge a branch into itself?

No — Git will tell you there is nothing to merge. You can only merge one branch into a different branch. If you want to bring changes from main into your feature branch, switch to the feature branch and run git merge main.

What if I merge the wrong branch by accident?

If you have not pushed yet, use git reset --hard HEAD~1 to undo the merge commit. If it is already pushed, use git revert -m 1 HEAD to create a commit that reverses it. Either way, you can then merge the correct branch.

Why does Git ask me to resolve conflicts instead of choosing automatically?

Because Git cannot know which version is correct when both branches changed the same lines. Only you know whether the feature branch's change or main's change should win. Git stops and asks you to decide, ensuring no work is accidentally lost.