Ours vs theirs in conflicts in Git - Trade-offs & Expert Analysis

Overview - Ours vs theirs in conflicts

What is it?

When two people change the same part of a file in Git, a conflict happens. 'Ours' and 'theirs' are ways to decide which change to keep. 'Ours' means keeping your version, and 'theirs' means keeping the other person's version. This helps fix conflicts quickly and clearly.

Why it matters

Without understanding 'ours' and 'theirs', resolving conflicts can be confusing and error-prone. This can slow down teamwork and cause mistakes in code. Knowing these terms helps teams work smoothly and avoid losing important changes.

Where it fits

You should know basic Git commands like commit, branch, and merge before learning this. After this, you can learn advanced conflict resolution tools and strategies for smoother collaboration.

Mental Model

Core Idea

'Ours' means your current branch's changes, and 'theirs' means the other branch's changes during a conflict.

Think of it like...

Imagine two friends writing on the same page of a notebook at the same time. 'Ours' is what you wrote, and 'theirs' is what your friend wrote. Choosing 'ours' keeps your words; choosing 'theirs' keeps your friend's words.

Conflict in Git Merge
┌───────────────┐
│   Base File   │
└──────┬────────┘
       │
       ▼
┌───────────────┐       ┌───────────────┐
│   Our Branch  │       │ Their Branch  │
│   (Ours)      │       │   (Theirs)    │
└──────┬────────┘       └──────┬────────┘
       │                       │
       └───────────┬───────────┘
                   ▼
             Merge Conflict
                   │
          Choose 'Ours' or 'Theirs'
                   │
          Resolved File Saved

Build-Up - 6 Steps

1

Foundation

What is a Git conflict?

Concept: Introduce the idea of a conflict when merging branches.

When you try to combine two branches in Git, sometimes both branches change the same lines in a file. Git cannot decide which change to keep and stops with a conflict. You must fix this before continuing.

Result

Git shows conflict markers in the file and stops the merge until you fix it.

Understanding conflicts is the first step to knowing why 'ours' and 'theirs' choices exist.

2

Foundation

Understanding 'ours' and 'theirs' terms

Concept: 'Ours' and 'theirs' refer to the two versions in conflict.

'Ours' means the version from the branch you currently have checked out. 'Theirs' means the version from the branch you are merging in. These labels help you decide which change to keep.

Result

You can now identify which side of the conflict is yours and which is the other person's.

Knowing these terms helps you communicate clearly when resolving conflicts.

3

Intermediate

Using 'ours' and 'theirs' in git checkout

🤔Before reading on: do you think 'git checkout --ours ' replaces the whole file or just the conflicted parts? Commit to your answer.

Concept: Learn how to pick one side's version using git checkout commands.

During a conflict, you can run 'git checkout --ours ' to keep your branch's version of the file. Or 'git checkout --theirs ' to keep the other branch's version. This replaces the conflicted file with the chosen version.

Result

The conflicted file is replaced by the chosen side's version, ready to be staged and committed.

Knowing these commands speeds up conflict resolution by letting you pick a whole side quickly.

4

Intermediate

Manual conflict markers and editing

🤔Before reading on: do you think manually editing conflict markers is safer or riskier than using 'ours'/'theirs' commands? Commit to your answer.

Concept: Understand how Git marks conflicts inside files and how to edit them manually.

Git adds markers like <<<<<<<, =======, and >>>>>>> around conflicting parts. You can open the file and choose which lines to keep or combine both. After editing, remove the markers and save the file.

Result

The conflict is resolved manually, allowing a mix of both changes if desired.

Manual editing gives fine control but requires careful attention to avoid mistakes.

5

Advanced

Using git merge strategies with ours/theirs

🤔Before reading on: does the 'ours' merge strategy keep your changes or discard them? Commit to your answer.

Concept: Learn about merge strategies that automate conflict resolution using 'ours' or 'theirs'.

Git has merge strategies like 'ours' that keep your branch's changes entirely, ignoring the other branch. You can run 'git merge -s ours ' to do this. There is no built-in 'theirs' strategy, but you can simulate it with other commands.

Result

Merge completes automatically by choosing one side's changes for all conflicts.

Knowing these strategies helps automate conflict resolution in special cases, saving time.

6

Expert

Surprises in 'ours' and 'theirs' meanings

🤔Before reading on: do you think 'ours' always means your local changes, even in rebase? Commit to your answer.

Concept: Explore how 'ours' and 'theirs' meanings change depending on Git commands like merge or rebase.

In a merge, 'ours' is your current branch, and 'theirs' is the branch being merged. But in a rebase conflict, 'ours' is the branch being rebased (the new commits), and 'theirs' is the base branch. This can confuse users and cause wrong conflict resolutions.

Result

Understanding this prevents mistakes when resolving conflicts during rebase versus merge.

Knowing context-dependent meanings avoids costly errors in complex workflows.

Under the Hood

Git stores snapshots of files for each commit. When merging, it compares the base commit, 'ours' commit, and 'theirs' commit to find differences. Conflicts happen when the same lines differ between 'ours' and 'theirs'. Git marks these conflicts in files and waits for user input to resolve them.

Why designed this way?

Git uses 'ours' and 'theirs' to give users clear control over which changes to keep. This design balances automation with manual control, allowing safe merges without losing work. Alternatives like automatic overwrites risk losing important changes.

Git Merge Conflict Flow
┌───────────────┐
│   Base Commit │
└──────┬────────┘
       │
       ▼
┌───────────────┐       ┌───────────────┐
│   Our Commit  │       │ Their Commit  │
│   (Ours)      │       │   (Theirs)    │
└──────┬────────┘       └──────┬────────┘
       │                       │
       └───────────┬───────────┘
                   ▼
          Compare Changes
                   │
          Conflict Detected?
                   │
          ┌────────┴────────┐
          │                 │
        Yes                No
          │                 │
  Mark Conflict       Auto Merge
  in Files & Stop     and Commit
  for User

Myth Busters - 4 Common Misconceptions

Quick: Does 'ours' always mean your local changes no matter the Git command? Commit to yes or no.

Common Belief: Many think 'ours' always means the local branch's changes.

Reality: In rebase conflicts, 'ours' refers to the rebased commits, not the local branch, which can be confusing.

Why it matters: Misunderstanding this causes wrong conflict resolutions during rebase, leading to lost or incorrect code.

Quick: Does 'git merge -s theirs' exist as a built-in strategy? Commit to yes or no.

Common Belief: Some believe Git has a 'theirs' merge strategy like 'ours'.

Reality: Git does not have a built-in 'theirs' merge strategy; you must use other commands to simulate it.

Why it matters: Expecting a 'theirs' strategy can waste time and cause confusion during merges.

Quick: Can you safely resolve conflicts by always choosing 'ours' without reviewing? Commit to yes or no.

Common Belief: Choosing 'ours' blindly is safe and fast.

Reality: Blindly choosing 'ours' can discard important changes from others, causing bugs or missing features.

Why it matters: Ignoring others' changes risks breaking the project and losing teamwork benefits.

Quick: Does manual editing of conflict markers always produce better results than automated commands? Commit to yes or no.

Common Belief: Manual editing is always better than using 'ours' or 'theirs' commands.

Reality: Manual editing is powerful but error-prone; sometimes automated commands are safer and faster.

Why it matters: Over-relying on manual edits can introduce syntax errors or miss conflicts.

Expert Zone

1

During rebase conflicts, 'ours' and 'theirs' swap meanings compared to merge, which can confuse even experienced users.

2

The 'ours' merge strategy ignores all changes from the other branch, which is useful for keeping your branch's history but can hide important updates.

3

Using 'git checkout --ours' or '--theirs' only replaces conflicted files, not partial hunks, so sometimes manual edits are still needed.

When NOT to use

Avoid using 'ours' or 'theirs' blindly when both sides have important changes; instead, manually merge or use specialized merge tools. Also, do not use the 'ours' merge strategy if you want to keep updates from both branches.

Production Patterns

Teams often use 'ours' and 'theirs' commands during hotfix merges to quickly keep urgent fixes. In complex rebases, they carefully check meanings to avoid mistakes. Automated CI tools sometimes run scripts to auto-resolve trivial conflicts using these options.

Connections

Conflict resolution in human communication

Both involve choosing between competing versions or opinions.

Understanding how to fairly choose or combine conflicting ideas in communication helps grasp why Git offers 'ours' and 'theirs' options.

Version control branching models

Ours/theirs decisions happen during merges in branching workflows.

Knowing branching models like Git Flow clarifies when and why conflicts arise and how to resolve them effectively.

Database transaction conflict handling

Both handle conflicts between concurrent changes to shared data.

Seeing how databases use locks or rollbacks to resolve conflicts helps understand Git's manual conflict resolution approach.

Common Pitfalls

#1 Choosing 'ours' without reviewing the other branch's changes.

Wrong approach:

git checkout --ours conflicted_file
git add conflicted_file
git commit -m "Resolved conflict by choosing ours"

Correct approach:

Review conflicted_file carefully before choosing 'ours' or manually merge changes.
Use git diff to compare versions.

Root cause:

Assuming your changes are always correct and ignoring others' contributions.

#2 Confusing 'ours' and 'theirs' meanings during rebase conflicts.

Wrong approach:

During rebase conflict, running 'git checkout --ours file' expecting local branch version.

Correct approach:

Understand that during rebase, 'ours' is the rebased commit; check carefully before resolving.

Root cause:

Not knowing that 'ours' and 'theirs' meanings depend on the Git operation context.

#3 Expecting a 'theirs' merge strategy to exist and trying to use it.

Wrong approach:

git merge -s theirs feature_branch

Correct approach:

Use 'git checkout --theirs ' on conflicts or other commands to simulate 'theirs' behavior.

Root cause:

Misunderstanding Git's available merge strategies.

Key Takeaways

'Ours' and 'theirs' help you decide which side's changes to keep during Git conflicts.

Their meanings depend on the Git command context, especially between merge and rebase.

Using 'git checkout --ours' or '--theirs' replaces conflicted files with one side's version quickly.

Manual editing of conflict markers allows fine control but requires care to avoid errors.

Blindly choosing one side can cause lost work; always review changes before resolving.

Practice

1. In a Git merge conflict, what does ours refer to?

easy

A. A backup copy of the file before the merge

B. The version of the file in the branch you are merging

C. The common ancestor version of the file

D. The version of the file in your current branch

Solution

1. Step 1: Understand the meaning of 'ours' in Git conflicts

   'Ours' means the version of the file in your current branch where you started the merge.

2. Step 2: Differentiate from 'theirs'

   'Theirs' refers to the version from the branch you are merging into your current branch.

3. Final Answer:

   The version of the file in your current branch -> Option D

4. Quick Check:

   Ours = current branch version [OK]

Hint: Ours = your branch, theirs = merging branch [OK]

Common Mistakes:

• Confusing 'ours' with 'theirs'
• Thinking 'ours' means the common ancestor
• Assuming 'ours' is a backup copy

2. Which Git command correctly chooses the 'theirs' version of a conflicted file named app.js?

easy

A. git checkout --ours app.js

B. git checkout --theirs app.js

C. git reset --theirs app.js

D. git merge --theirs app.js

Solution

1. Step 1: Identify the correct command to pick 'theirs'

   The command to choose the 'theirs' version during conflict is git checkout --theirs <file>.

2. Step 2: Verify the file name usage

   Using app.js after the command specifies the file to resolve.

3. Final Answer:

   git checkout --theirs app.js -> Option B

4. Quick Check:

   Use 'git checkout --theirs' to pick theirs [OK]

Hint: Use 'git checkout --theirs <file>' to pick theirs version [OK]

Common Mistakes:

• Using 'git reset' instead of 'git checkout'
• Confusing '--ours' with '--theirs'
• Trying 'git merge --theirs' which is invalid

3. After a merge conflict on index.html, you run:
git checkout --ours index.html
What will be the content of index.html after this command?

medium

A. The version from your current branch before the merge

B. The version from the branch you are merging

C. The common ancestor version

D. An empty file

Solution

1. Step 1: Understand what 'git checkout --ours' does in conflict

   This command replaces the conflicted file with the version from your current branch before the merge.

2. Step 2: Confirm the file content after the command

   After running it, index.html will have your branch's original content, ignoring the other branch's changes.

3. Final Answer:

   The version from your current branch before the merge -> Option A

4. Quick Check:

   'git checkout --ours' = current branch content [OK]

Hint: Checkout --ours picks your branch's file version [OK]

Common Mistakes:

• Thinking it picks the other branch's version
• Assuming it resets to common ancestor
• Expecting it to merge both versions automatically

4. You tried to resolve a conflict by running git checkout --theirs main.js but the file did not update. What is the likely cause?

medium

A. You need to commit before checking out

B. You used the wrong file name

C. You are not in a conflicted merge state

D. The command only works after resolving conflicts manually

Solution

1. Step 1: Check the merge state requirement

   The git checkout --theirs command only works when Git detects a conflict during a merge.

2. Step 2: Understand why the file didn't update

   If you are not in a conflicted state, Git has no 'theirs' version to apply, so the file stays unchanged.

3. Final Answer:

   You are not in a conflicted merge state -> Option C

4. Quick Check:

   'git checkout --theirs' needs conflict state [OK]

Hint: Use 'git status' to confirm conflict before checkout --theirs [OK]

Common Mistakes:

• Trying to use --theirs outside a merge conflict
• Assuming checkout updates file without conflict
• Not verifying current branch or file name

5. During a complex merge conflict involving multiple files, you want to keep your current branch's version for config.yaml but accept the other branch's version for README.md. Which sequence of commands correctly resolves this?

hard

A. git checkout --ours config.yaml && git checkout --theirs README.md && git add config.yaml README.md

B. git checkout --theirs config.yaml && git checkout --ours README.md && git add config.yaml README.md

C. git reset --ours config.yaml && git reset --theirs README.md && git commit -m 'Resolve conflicts'

D. git merge --ours config.yaml README.md

Solution

1. Step 1: Use correct commands to pick versions per file

   To keep your branch's version for config.yaml, use git checkout --ours config.yaml. To accept the other branch's version for README.md, use git checkout --theirs README.md.

2. Step 2: Stage the resolved files

   After choosing versions, add both files to the staging area with git add config.yaml README.md to mark conflicts resolved.

3. Final Answer:

   git checkout --ours config.yaml && git checkout --theirs README.md && git add config.yaml README.md -> Option A

4. Quick Check:

   Use checkout --ours/theirs per file, then git add [OK]

Hint: Pick versions per file with checkout, then git add to resolve [OK]

Common Mistakes:

• Mixing up --ours and --theirs for files
• Forgetting to git add after checkout
• Using git reset or git merge incorrectly