Git Branch Overwrite: Using the 'ours' Merge Strategy for Complete Branch Replacement

Problem Context and Requirements Analysis

In Git version control systems, branch management represents a fundamental aspect of daily development workflows. When developers encounter scenarios requiring complete replacement of one branch's content with another's content, traditional merge operations often prove inadequate. The specific situation involves two branches, email and staging, where staging contains the latest changes, while the old changes in the email branch are no longer needed but cannot be deleted due to historical preservation requirements.

Such requirements frequently arise during project refactoring, technology stack upgrades, or feature rewrites. For instance, when development teams decide to adopt new framework versions while old branches rely on outdated technical implementations, complete content overwriting from new branches to old branches becomes necessary while maintaining commit history integrity.

Core Solution: The 'ours' Merge Strategy

Git provides specialized merge strategies to address such branch overwrite requirements. The git merge -s ours command enables complete replacement of target branch content with current branch content while creating a merge commit to record this operation.

The detailed operational procedure consists of:

$ git checkout staging
$ git merge -s ours email
$ git checkout email  
$ git merge staging

The core of this four-step process lies in the second step: git merge -s ours email. When executing this command, Git creates a new merge commit, but this commit's tree object originates entirely from the staging branch, i.e., the current working branch. This ensures all file changes from the email branch are completely overwritten by staging branch content.

Technical Principle Deep Dive

Understanding the working mechanism of the -s ours strategy requires comprehensive knowledge of Git's merge architecture. Git merge operations involve three critical components: base commit, our commit, and their commit. In standard merges, Git attempts automatic reconciliation of differences among these three versions.

However, the -s ours strategy employs a different approach:

// Simulating core merge strategy logic
function oursMergeStrategy(oursTree, theirsTree, baseTree) {
    // Completely ignore theirsTree and baseTree
    return oursTree; // Directly return our tree object
}

This strategy guarantees the final file tree derives entirely from the staging branch, while changes from the email branch are completely discarded. Importantly, the merge commit itself retains parent commit information from both branches, ensuring historical record preservation.

Comparative Analysis with Alternative Methods

Multiple approaches exist in Git for achieving branch overwrites, each with specific application scenarios and limitations.

Reset Method (git reset)

Using git reset --hard enables rapid branch pointer movement:

$ git checkout email
$ git reset --hard staging

While this method offers simplicity, it carries significant drawbacks: it renders original email branch commits unreachable unless tags or branches are created beforehand for backup. This contradicts the requirement of "not wanting to delete old changes."

Merge Strategy Option (-X ours) vs Merge Strategy (-s ours) Distinction

A common point of confusion involves distinguishing between -X ours (strategy option) and -s ours (merge strategy). Concrete examples clearly demonstrate their differences:

// Initialize test repository
$ git init
$ echo 'original' | tee file1 file2 file3
$ git commit -m 'initial commit'
$ git branch A
$ git branch B

// Modify file1 on branch A
$ git checkout A
$ echo 'A' > file1
$ git commit -m 'change on branch A' file1

// Modify file2 on branch B  
$ git checkout B
$ echo 'B' > file2
$ git commit -m 'change on branch B' file2

Merge using strategy option:

$ git merge -X ours A
$ cat file*
// Output: A B original

Merge using merge strategy:

$ git merge -s ours A  
$ cat file*
// Output: original B original

The output reveals that -X ours performs genuine merge operations, merely preferring "our" version during conflict resolution. In contrast, -s ours completely ignores changes from the other branch, directly utilizing current branch content.

Advanced Applications: Plumbing Command Implementation

For scenarios requiring finer control, Git's plumbing commands can achieve identical results:

$ git checkout A
$ git merge --ff-only $(git commit-tree -m "Throw away branch 'A'" -p A -p B B^{tree})

This command combination uses commit-tree to create a new commit with parents including both A and B, but the tree object originates entirely from branch B. Subsequently, merge --ff-only fast-forwards to this commit.

Although complex, this approach provides complete control, suitable for automation scripts or specialized workflow requirements.

Practical Application Scenarios and Best Practices

In practical development, branch overwrite operations apply to multiple scenarios:

Technology Stack Upgrades: When projects require migration from old to new technology stacks, complete code rewrites can occur on new branches, followed by -s ours strategy application to overwrite changes to main branches.

Feature Rewrites: When specific feature implementations require complete refactoring, rewrites can occur on feature branches, subsequently overwriting original feature branches.

Error Recovery: When branches contain irreparable critical errors, content overwriting from healthy branches enables rapid recovery.

Recommended best practices:

• Ensure important changes are backed up before performing overwrite operations
• Communicate overwrite intentions in team collaboration environments
• Use descriptive commit messages explaining overwrite rationales
• Consider using tags to mark significant historical nodes

Conclusion

The git merge -s ours strategy provides Git users with an elegant branch overwrite solution. It satisfies content replacement requirements while maintaining version history integrity. Compared to reset or force-push methods, this approach offers enhanced safety and reliability, particularly suitable for projects requiring clear version history maintenance.

Through deep understanding of distinctions between merge strategies and strategy options, developers can more precisely select Git operations appropriate for current scenarios, improving version control management efficiency and reliability.