In the labyrinthine world of Git, mastering the terminology is as crucial as understanding its commands. Among the most perplexing concepts for many are the terms “ours” and “theirs”. These terms shift meaning based on the Git operation being performed, leading to confusion. This article aims to elucidate these concepts, offering clarity through detailed examples.

The Essence of “Ours” and “Theirs”

At its core, Git is a tool for managing project versions, allowing multiple contributors to work simultaneously on different aspects of a project. The terms “ours” and “theirs” emerge prominently during merge and rebase operations, referring to different versions of the code.

In the Context of Merging

When merging two branches, “ours” and “theirs” are relatively intuitive:

  • Ours: The branch you are currently on; the destination branch where the merge will be committed.
  • Theirs: The source branch whose changes are being merged into “ours”.

Example:

Let’s consider merging changes from a feature branch (feature-branch) into the main branch (main).

git checkout main        # Switch to the main branch, making it "ours"
git merge feature-branch # Merge 'feature-branch' into 'main', making 'feature-branch' "theirs"

In this scenario, main is “ours” because it is the branch we are merging into, and feature-branch is “theirs” since it’s the branch we’re merging from.

In the Context of Rebasing

Rebasing complicates the “ours” and “theirs” concepts. Rebasing rewrites commit history by applying changes from one branch onto another, which can make the original branch appear as “theirs”.

  • Ours: The base branch onto which changes are being applied.
  • Theirs: The branch being rebased.

Example:

Suppose we want to rebase feature-branch onto main.

git checkout feature-branch # Switch to 'feature-branch', initially "ours"
git rebase main             # Rebase onto 'main', now 'main' is "ours" and 'feature-branch' becomes "theirs"

During the rebase, “ours” and “theirs” flip. Initially, feature-branch is “ours” because it’s the active branch. However, as we apply its changes onto main, in the context of each rebase step, “ours” refers to the commit from main that’s currently being applied to, and “theirs” refers to the changes from feature-branch.

Handling Merge Conflicts

Merge conflicts are a common scenario where understanding “ours” and “theirs” becomes practical. Let’s examine how to navigate a conflict during a merge.

Example Scenario:

  1. Conflict arises during a merge: Imagine a conflict has occurred while merging feature-branch into main.

  2. Resolving using “ours” or “theirs”: You can choose to resolve conflicts using versions from “ours” or “theirs”.

    • To keep the version from main (ours): 
      git checkout --ours path/to/conflicted_file
    • To accept the version from feature-branch (theirs): 
      git checkout --theirs path/to/conflicted_file

  3. Finalising the merge: After resolving conflicts, add the resolved files to the staging area and commit the merge.

    git add path/to/conflicted_file
git commit -m "Resolved merge conflict by choosing 'ours'/'theirs'"

Conclusion

Understanding “ours” and “theirs” in Git is pivotal for efficiently managing merges and rebases. This guide has aimed to demystify these terms, providing clarity through examples. Remember, the key to mastering Git lies in practising these concepts in real-world scenarios. Embrace the complexity, and you’ll find these once perplexing terms becoming second nature in your version control toolkit.