Best Practices for Conflict Resolution in EGit: Recovering from MERGE_RESOLVED State

Core Problem Analysis of EGit Conflict Resolution

When using EGit for version control, merge conflicts are common but often mishandled scenarios. After developers perform a pull operation and encounter file conflicts, manually resolving content conflicts is only the first step. The key issue lies in EGit's state management—when the system enters the MERGE_RESOLVED state,常规的推送和拉取操作会被阻塞。

In-depth Analysis of Error Scenarios

The four typical errors reported by users reveal the root cause of state inconsistency:

• Non-fast-forward Rejection: The local branch contains unrecorded merge commits that the remote repository cannot accept due to historical record changes
• MERGING_RESOLVED State Error: Git detects that the merge process was not properly completed, resulting in inconsistent index state
• Index Addition Failure: File permission issues or repository corruption prevent updates to the staging area
• Hard Reset Exception: Forced reset operations damage working directory integrity when uncommitted changes exist

Correct Conflict Resolution Workflow

Avoid using the Team Synchronise view and instead adopt the standard operational path through the Git Repository view:

// Simulating core logic of merge operations
public class GitMergeHandler {
    public MergeResult performMerge(Repository repo, String branch) {
        // Check repository state
        if (repo.getState() == RepositoryState.MERGING_RESOLVED) {
            throw new IllegalStateException("Must complete current merge process first");
        }
        
        // Execute merge
        MergeCommand merge = new MergeCommand();
        merge.setBranch(branch);
        return merge.execute();
    }
}

Specific operational steps:

1. Switch to the Git perspective and locate Branches → Local → master in the Git Repository view
2. Right-click and select Merge..., with the system automatically selecting origin/master as the merge target
3. After confirming the merge, check the result status. When result:conflict is displayed, proceed to the conflict file editing phase

Conflict File Identification and Handling

Conflict files contain standard Git merge markers:

<<<<<<< HEAD
Local version content
=======
Remote version content
>>>>>>> origin/master

Editing strategies include:

• Manually integrate changes from both sides and remove conflict markers
• Use "Replace With" → "Theirs" to completely accept the remote version
• Use "Replace With" → "Ours" to fully retain the local version

Index Update and State Transition

After file editing is complete, modifications must be added to the index in the Git Staging view:

// Core implementation of index addition
public class IndexManager {
    public void addToIndex(File file) throws IOException {
        DirCache index = repository.lockDirCache();
        DirCacheEditor editor = index.editor();
        
        // Add file to index
        editor.add(new DirCacheEditor.PathEdit(file.getPath()) {
            public void apply(DirCacheEntry ent) {
                ent.setFileMode(FileMode.REGULAR_FILE);
                ent.setObjectId(repository.insert(OBJ_BLOB, 
                    readFileContent(file)));
            }
        });
        editor.commit();
    }
}

This step declares to Git that conflicts have been resolved, allowing the system to exit the MERGE_RESOLVED state.

Final Commit and Push

After completing index addition for all conflict files:

1. Fill in meaningful commit messages in the Git Staging view
2. Execute the commit operation to generate merge commit records
3. Push changes to the remote repository, avoiding non-fast-forward errors

Supplementary Operational Techniques

Based on experiences from other answers, efficiency can be improved by combining the following methods:

• Use Team → Merge Tool for visual three-way merging
• Run comprehensive tests after conflict resolution to ensure functional integrity
• Regularly execute git status to check repository state

Conclusion

The key to EGit conflict resolution lies in understanding Git's state machine model. The MERGE_RESOLVED state requires a complete conflict resolution workflow to exit, including file editing, index updates, and final commits. Following the standard operational path through the Git Repository view and avoiding the limited Team Synchronise view can systematically resolve various merge conflict issues.