The Precise Meaning of "Ours" and "Theirs" in Git and Their Roles in Merge and Rebase

Introduction

In the Git version control system, the terms "ours" and "theirs" frequently appear during merge and rebase operations, but their meanings often confuse developers. Based on high-scoring Stack Overflow answers and supplementary materials, this article systematically explains the core definitions, usage contexts, and underlying mechanisms of these terms.

Basic Definitions of "Ours" and "Theirs"

In Git merge operations, "ours" refers to the current branch (i.e., the branch HEAD points to when running git merge), while "theirs" refers to the branch being merged. For example, after executing git checkout master and running git merge feature, "ours" is the master branch, and "theirs" is the feature branch. This naming stems from the operational perspective: the current branch is "ours," and the incoming branch is "theirs," even though both may belong to the same developer.

Roles in Merge Conflicts

When a merge causes conflicts, Git provides git checkout --ours <file> and git checkout --theirs <file> commands to quickly select file versions. For instance, when merging the feature branch into master, if codefile.js has a conflict, running git checkout --ours codefile.js adopts the master branch version, while git checkout --theirs codefile.js adopts the feature branch version. This corresponds to Git's index staging mechanism: stage 1 is the common ancestor, stage 2 is the "ours" version, and stage 3 is the "theirs" version, viewable via commands like git show :1:README.

Role Reversal in Rebase Operations

In rebase operations, the roles of "ours" and "theirs" are reversed compared to merges. For example, after executing git checkout feature and running git rebase master, "ours" refers to the master branch (the rebase target), and "theirs" refers to the feature branch (the branch being rebased). This is because rebase internally performs a series of cherry-pick operations in a detached HEAD state, building an anonymous branch where the target is considered "ours." Code examples include:

# Rebase scenario
git checkout feature
git rebase master
# Select master branch version
git checkout --ours codefile.js
# Select feature branch version
git checkout --theirs codefile.js

This reversal often causes confusion; it is advisable to clarify branch roles during rebase.

Applications in Complex Scenarios

Git allows merging non-branch references, such as commit IDs, where "ours" and "theirs" are still based on the current HEAD and target commit. For example:

git checkout 7777777  # Detached HEAD
git merge 1234567    # Merge specific commit

In this scenario, no branch names are involved, but "ours" is the current commit (7777777), and "theirs" is the merged commit (1234567). Additionally, merge strategies like -s ours (whole-file level) and -X ours (piecewise level) further extend the application of these terms.

Impact of .gitattributes Files

Setting merge=ours in .gitattributes can automatically resolve conflicts for specific files, but note the file's activation conditions. For instance, if config.xml merge=ours is set in the test branch, and then the test branch is merged into master, the setting may not take effect because .gitattributes is not checked out, unless manually copied to the working tree. Internally, "ours" corresponds to index stage 2, ensuring version selection consistency.

Summary and Best Practices

In Git, "ours" and "theirs" are essentially context-dependent: in merges, "ours" is the current branch; in rebases, "ours" is the target branch. Developers should familiarize themselves with these terms through practice and use tools like git mergetool (which may use aliases like "local" and "remote") to aid understanding. In complex workflows, clarifying branch states and operation types is key to avoiding confusion.