Git Merge Theirs Explained

The Git merge ‘theirs’ command -Xtheirs overrides changes in the master branch with changes in your feature branch, resolving git merge conflicts. Here’s how. 

Written by Amandeep Singh
Published on Jul. 15, 2024
Developer merging two branches on laptop
Image: Shutterstock / Built In
Brand Studio Logo

When you’re on a master branch, the Git merge -Xtheirs command allows you to override the changes in the master branch with your feature branch. You could also use -Xours command to override changes in the feature branch with the master branch.

This is useful because Git branching allows developers to work in isolation. Once your work is completed, you can merge your branch back into the master. In a few cases, it could cause merge conflicts in which Git doesn’t know what to do and hands control back to you.

What Are Ours and Theirs Merge Options in Git?

  • -Xtheirs: This command in Git allows users to override changes in the master branch with the changes in the feature branch.
  • -Xours: This Git command allows users to override changes in the feature branch with changes in the master branch. 

What if you just want to override your changes in master with another branch, or vice-versa? You could resolve all the conflicts manually by navigating to each file and accepting all incoming changes to the master, but that would be a little time-consuming. 

In this article, I'll first explain the reasoning behind the conflicts, and then we’ll discuss how to implement Git merge -Xtheirs and -Xours.

 

What Causes a Git Merge Conflict? 

A branch is just a lightweight, movable pointer to one of the commits you are on. When you create a new branch off from master with git branch feature, a new pointer is created as shown in the figure below:

feature
   |
   A
   |
 master
   |
 HEAD

And when you switch branch with git checkout feature, Git moves the HEAD pointer, which was initially pointing to master, to your branch. This is how Git knows which branch you are on.

  HEAD
   |
 feature
   |
   A
   |
 master

While you are happily working on your branch, or feature, the master (pointer) can move forward. Your colleague’s branch (testing) has been merged into the master already. The scenario now looks like this.

   E---F---G feature
  /
 A---B---C master

It’s time to merge your branch to master. You’ll run git checkout master followed by git merge feature. The git merge feature will try to replay changes made on the feature branch, since it diverged from master (i.e “A”) until its current commit (i.e “G”). But you’ll be met with some merge conflicts. This is because the feature and testing branch both have modified the same file. And now Git doesn't know what changes to keep and what to discard. It handles the control back to you instead of overriding things on its own, which might not be desirable.

You can use git merge --abort command to abort the merge process when a merge conflict has already occurred.

More on GitHow to Fix the GitHub Error ‘Remote Host Identification Has Changed’

 

What Is Git Merge Theirs and Ours?

In situations where you want to override changes from one branch to another, you can use two merge strategy options: -Xtheirs and -Xours.

If you want to override the changes in the master branch with your feature branch, you can run the following command after checking out to master:

git merge -Xtheirs feature

And to keep the master branch changes, you can use:

git merge -Xours feature

Interestingly, it works in reverse order if you want to do rebasing of your branch onto the master and keep your changes over the master. 

So, if you are on your feature branch, the command you need to run will be:

git rebase master -Xtheirs

And to keep master branch changes over yours, you need to do:

git rebase master -Xours
A tutorial on solving Git merge conflicts. | Video: JetBrains

More on Software EngineeringJava Switch Case Explained

Why the Order is Reversed in Rebasing

If you wish to understand the reasoning behind why the order was reversed, you need to first understand how rebasing works.

Let’s assume we have the following history with the feature branch checked out:

   E---F---G feature
  /    
 A---B---C master

When you rebase onto master via git rebase master, the process goes through the following steps:

  • Roll back to the common ancestor commit of the feature and the master branch (i.e “A”).
  • Save all changes made by commits in the feature branch but that aren’t in the master to a temporary area.
  • Reset feature branch to current commit on master.

The intermediate history looks like this now:

 E---F---G (saved in a temporary area)

         feature
          /    
 A---B---C master

After the reset, all the changes in the temporarily saved area (i.e “E”, “F” and “G”), are applied in turn onto the master branch. 

The final new history looks like this:

           E---F---G feature
         /    
A---B---C master

The key point to remember is that the feature branch was reset to the current master, and changes were applied from there onwards. So, theirs refers to the feature branch but not master and ours will be the master branch as internally we're on this master branch already. 

The following table would make it easier to understand and remember -Xtheirs and -Xours strategies.

A table showing when to use git merge theirs vs ours
A table showing when to use Git merge -Xtheirs and -Xours. | Image: Amandeep Singh

Frequently Asked Questions

Git merge -Xtheirs is used to override changes in the master branch with changes in the feature branch. The syntax is: git merge -Xtheirs feature

Git merge -Xours is used to override changes in the feature branch with those from the master branch. The syntax for -Xours is: git merge -Xours feature

 

Explore Job Matches.