What Causes Merge Conflicts and How to Resolve Them

A merge conflict occurs when Git cannot automatically combine changes from two branches because both branches have modified the same lines of the same file differently or when one branch deletes a file that another branch modifies.

Git pauses the merge and asks you to manually resolve the conflicting changes before the merge can be completed.

Interview Answer

"A merge conflict occurs when Git cannot automatically merge changes because two branches modify the same lines of a file differently or when one branch deletes a file that another branch modifies. I resolve conflicts by identifying the conflicting files using git status, editing the files to remove the conflict markers, staging the resolved files, and completing the merge with a commit."

Advertisement

Common Causes of Merge Conflicts

Merge conflicts typically occur when:

  • Two developers modify the same lines of the same file.
  • One branch deletes a file while another branch edits it.
  • Long-lived branches diverge significantly.
  • Developers do not pull the latest changes before merging.

Merge Conflict Workflow

 
Feature Branch
      │
      ├─────────────┐
      │             │
      ▼             ▼
Modify File     Modify Same File
      │             │
      └──────┬──────┘
             ▼
        Git Merge
             │
             ▼
      Merge Conflict
             │
             ▼
 Manual Conflict Resolution
             │
             ▼
      Commit Merge
 

Conflict Markers

When a conflict occurs, Git inserts conflict markers into the file.

 
<<<<<<< HEAD
Current branch changes
=======
Incoming branch changes
>>>>>>> feature-branch
 

Steps to Resolve a Merge Conflict

Step 1: Check Conflicting Files

 
git status
 

Step 2: Edit the File

  • Remove the conflict markers.
  • Keep the correct code.
  • Save the file.

Step 3: Stage the Resolved File

 
git add <resolved-file>
 

Step 4: Complete the Merge

 
git commit
 

Real-Time Example

While merging a feature branch into the development branch, another developer had modified the same method. Git reported a merge conflict. I reviewed both implementations, merged the required logic, removed the conflict markers, staged the resolved file using git add, and completed the merge with a commit.

Best Practices to Avoid Merge Conflicts

  • Create small feature branches.
  • Pull the latest changes frequently.
  • Merge regularly.
  • Keep commits small and focused.
  • Avoid working on the same files simultaneously whenever possible.

Detached HEAD State

A Detached HEAD state occurs when Git's HEAD points directly to a specific commit instead of pointing to a branch.

In this state, any commits you create are not attached to any branch and may become inaccessible if you switch branches without saving them.

Interview Answer

"A detached HEAD state occurs when HEAD points directly to a commit instead of a branch. If I need to preserve my work, I create a new branch from the current commit. Otherwise, I simply switch back to an existing branch."

How Does Detached HEAD Happen?

Examples:

 
git checkout <commit-hash>
 

or

 
git checkout tags/<tag-name>
 

Detached HEAD Workflow

 
Branch
   │
   ▼
Commit A
   │
   ▼
Commit B
   │
   ▼
Commit C
   │
   ▼
Checkout Commit B
   │
   ▼
Detached HEAD
 

How to Fix Detached HEAD

Option 1: Create a New Branch

 
git checkout -b <new-branch-name>
 

This preserves your work.

Option 2: Return to an Existing Branch

 
git checkout <branch-name>
 

Real-Time Example

If I accidentally enter a detached HEAD state while investigating an old commit and decide to keep my changes, I immediately create a new branch from that commit. Otherwise, I simply switch back to the appropriate working branch.

Best Practices

  • Avoid committing work while in a detached HEAD state unless you intend to create a branch.
  • Create a branch immediately if valuable work has been done.
  • Verify your current branch using:
 
git branch
 

Recovering a Deleted Branch or File

Git maintains a history of commits, making it possible to recover deleted branches and files in most situations.

Recovery depends on whether the branch or file had been committed before deletion.

Recovering a Deleted Branch

Step 1: View Reference Log

 
git reflog
 

Step 2: Recreate the Branch

 
git checkout -b <branch-name> <commit-hash>
 

Branch Recovery Workflow

 
Deleted Branch
       │
       ▼
git reflog
       │
       ▼
Locate Commit
       │
       ▼
Create Branch
       │
       ▼
Branch Restored
 

Recovering a Deleted File

File Deleted Before Commit

 
git checkout -- <file-name>
 

File Deleted After Commit

 
git checkout <commit-hash> -- <file-name>
 

Real-Time Example

If a teammate accidentally deletes a branch, I first use git reflog to locate the commit where the branch previously pointed. I then recreate the branch using git checkout -b. For deleted files, I restore them from the appropriate commit without affecting the rest of the project.

Best Practices

  • Check git status before attempting recovery.
  • Use git reflog to identify recent branch history.
  • Avoid deleting branches until they have been merged successfully.
  • Verify restored files before committing.

Force Push: What Happens and When Is It Safe?

A force push replaces the remote branch history with your local branch history.

Command:

 
git push --force
 

or

 
git push -f
 

Since force push rewrites Git history, it should be used carefully.

Interview Answer

"Force push overwrites the remote branch with my local branch history. I use it only on my private feature branches. For shared branches such as main or develop, I avoid force push and prefer safer approaches like git revert or git push --force-with-lease."

When Is Force Push Safe?

Force push is generally safe when:

  • Working on a private feature branch.
  • No other developers are using the branch.
  • The team has agreed to rewrite history.

When Should You Avoid Force Push?

Avoid force pushing on:

  • main
  • master
  • develop
  • Shared release branches

Force pushing to shared branches may overwrite teammates' commits and cause data loss.

Safer Alternative

 
git push --force-with-lease
 

Unlike --force, this command refuses to overwrite the remote branch if new commits have been pushed by someone else.

Force Push Workflow

 
Local Branch
      │
      ▼
Force Push
      │
      ▼
Remote Branch History
      │
      ▼
History Rewritten
 

Real-Time Example

During feature development, I occasionally rewrite commit history using interactive rebase. Before merging, I use git push --force-with-lease on my own feature branch to safely update the remote without risking other developers' work.

Recovering from a Bad Merge

Sometimes a merge introduces compilation errors, broken functionality, or incorrect code.

Git provides several ways to recover, depending on whether the merge has already been shared.

Interview Answer

"If the merge is local and hasn't been pushed, I use git reflog to identify the previous commit and git reset --hard to restore the branch. If the merge has already been pushed to a shared repository, I use git revert to safely undo the merge without rewriting Git history."

Local Merge Recovery

Step 1: Find Previous Commit

 
git reflog
 

Step 2: Reset

 
git reset --hard <commit-hash>
 

Shared Repository Recovery

Instead of resetting shared history, use:

 
git revert <merge-commit-hash>
 

This creates a new commit that reverses the merge while preserving project history.

Recovery Workflow

 
Bad Merge
     │
     ▼
Already Pushed?
     │
 ┌───┴────┐
 │        │
No       Yes
 │        │
 ▼        ▼
git reset   git revert
 

Best Practices

  • Use git reset --hard only for local branches.
  • Use git revert for shared repositories.
  • Verify the previous commit using git reflog.
  • Communicate with teammates before undoing shared merges.

Frequently Asked Questions (FAQs)

1. What causes merge conflicts and how do you resolve them?

Merge conflicts occur when Git cannot automatically merge changes because multiple branches modify the same lines of a file differently or when one branch deletes a file that another branch modifies.

To resolve them:

  1. Run:
 
git status
 
  1. Open the conflicting files.
  2. Remove the conflict markers.
  3. Save the correct code.
  4. Stage the resolved files.
 
git add <file-name>
 
  1. Complete the merge.
 
git commit
 

2. What is a Detached HEAD state and how do you fix it?

A Detached HEAD occurs when HEAD points directly to a commit instead of a branch.

To fix it:

Create a new branch:

 
git checkout -b <new-branch-name>
 

or return to an existing branch:

 
git checkout <branch-name>
 

Creating a new branch preserves any work performed while in the detached HEAD state.

3. How do you recover a deleted branch?

Use the Git reference log:

 
git reflog
 

Locate the commit and recreate the branch:

 
git checkout -b <branch-name> <commit-hash>
 

4. How do you recover a deleted file?

If the file was deleted before committing:

 
git checkout -- <file-name>
 

If the deletion was committed:

 
git checkout <commit-hash> -- <file-name>
 

5. What happens if you force push, and when is it safe?

A force push replaces the remote branch history with your local history.

It is generally safe only when:

  • Working on your own feature branch.
  • No one else is using that branch.
  • The team agrees to rewrite history.

Avoid force pushing to shared branches like main, master, or develop, as it may overwrite teammates' commits.

6. How do you recover from a bad merge?

For a local merge that has not been pushed:

 
git reflog
 
 
git reset --hard <commit-hash>
 

For a merge that has already been pushed:

 
git revert <merge-commit-hash>
 

git revert safely undoes the merge by creating a new commit without rewriting Git history, making it the preferred approach for shared repositories.