Comprehensive Guide to Resolving Git Merge Conflicts: Accepting Ours or Theirs Version Entirely

Fundamental Concepts of Git Merge Conflicts

In software development, merge operations in version control system Git are fundamental to team collaboration. When multiple developers modify the same sections of a file, Git cannot automatically determine which version to retain, resulting in merge conflicts. These conflicts typically manifest as special markers within files that require manual intervention to resolve.

Merge conflicts commonly appear with markers such as <<<<<<<, =======, and >>>>>>> dividing the file content into three regions: current branch modifications (our version), conflict separators, and incoming branch modifications (their version). Understanding these markers is the first step in conflict resolution.

Solutions for Accepting Our Version

When developers decide to completely retain current branch modifications, several commands can be used to accept our version:

git checkout HEAD -- <filename>

This command checks out the specified file directly from the current commit (HEAD), overwriting the conflicted file in the working directory. Since HEAD points to the latest commit in the current branch, this operation restores the file to our pre-merge state.

An equivalent approach is:

git checkout --ours -- <filename>

The --ours option is specifically designed for merge conflict scenarios, indicating the selection of our version. It's important to note that during rebase operations, the meanings of --ours and --theirs are swapped, which is a common point of confusion in Git design.

For developers seeking deeper understanding of Git internals, the low-level command approach is available:

git show :2:<filename> > <filename>

This command utilizes Git's staging concept. During merge conflicts, files exist in three stages in the index: stage 1 represents the common ancestor version, stage 2 contains our version, and stage 3 holds their version. Using :2:<filename> specifies checking out stage 2 content.

Solutions for Accepting Their Version

When deciding to adopt the incoming branch's modifications, the corresponding commands are:

git checkout test-branch -- <filename>

This command checks out the file directly from the specified branch (e.g., test-branch), overwriting the current working directory file with their branch's version.

A more concise notation is:

git checkout --theirs -- <filename>

The --theirs option explicitly indicates selection of their version, making the code intention clearer. Again, semantic changes during rebase operations should be noted.

The low-level implementation approach is:

git show :3:<filename> > <filename>

Here, :3:<filename> specifies checking out stage 3 content from the index, representing their version.

Complete Conflict Resolution Workflow

Regardless of which version selection approach is chosen, identical subsequent steps must be performed after file checkout:

git add <filename>

This command adds the resolved file to the staging area, marking the file's conflict as resolved. Git uses this operation to track which files' conflicts have been addressed.

After resolving all conflicted files, execute:

git commit

This completes the merge commit, creating a new commit record to document the merge operation. Git automatically generates commit messages containing conflict resolution information, which developers can modify as needed.

Practical Application Scenarios

In team development environments, complete version acceptance strategies apply to various scenarios. The most common situation occurs when feature modifications already exist in the upstream repository but encounter minor conflicts during pull operations. Developers typically prefer to completely accept the upstream version to avoid redundant work.

Another typical scenario involves merging feature branches into the main branch. If the feature branch modifications are more complete and thoroughly tested, main branch maintainers might choose to completely accept the feature branch version.

Developers can create aliases to streamline these frequent operations:

# Accept ours alias
git config --global alias.am '!f() { git checkout --ours -- "$@" && git add "$@"; }; f'

# Accept theirs alias
git config --global alias.at '!f() { git checkout --theirs -- "$@" && git add "$@"; }; f'

These aliases encapsulate the complete workflow, enabling developers to quickly resolve conflicts using simple commands like git am Makefile or git at Makefile.

Error Handling and Best Practices

When using these commands, several common error scenarios require attention. If file paths contain spaces or special characters, filenames should be enclosed in quotes:

git checkout --ours -- "file with spaces.txt"

For batch processing multiple file conflicts, wildcards can be employed:

git checkout --ours -- *.java

However, wildcard matching scope should be carefully considered to avoid accidentally overwriting files that shouldn't be modified.

Best practices include: understanding conflict content before resolution to ensure complete version acceptance is appropriate; establishing unified conflict resolution standards within teams; conducting regular code reviews to validate conflict resolution rationality.

Integration with Other Tools

In modern development environments, Git conflict resolution can be better integrated with other development tools. For instance, continuous integration workflows can be configured with automated conflict detection and resolution strategies. For complex codebases, combining code analysis tools helps developers better understand conflict impact scope.

By mastering these Git conflict resolution techniques, developers can more efficiently handle code merging issues in team collaboration, improving development efficiency and code quality.