프로덕션 서버에서 “Git Divergent Branch” 수정 (실제 DevOps 디버깅 연습)

One of the most confusing errors you can face while deploying a Node.js or Docker-based application is:

fatal: Need to specify how to reconcile divergent branches

Enter fullscreen mode Exit fullscreen mode

At first glance, it looks like a Git bug. In reality, it is Git doing exactly what it should do, protecting you from overwriting history.

In this article, I’ll break down a real production incident where a deployment failed due to divergent Git branches, how we diagnosed it, and the correct DevOps fix.

The Problem

A simple deployment script was running:

git pull
docker compose down --remove-orphans
docker compose up --build -d

Enter fullscreen mode Exit fullscreen mode

But it failed with:

fatal: Need to specify how to reconcile divergent branches

Enter fullscreen mode Exit fullscreen mode

This stopped deployment completely.

What Git Was Telling Us

To understand the issue, we ran:

git rev-list --left-right --count HEAD...origin/main

Enter fullscreen mode Exit fullscreen mode

Output:

1       16

Enter fullscreen mode Exit fullscreen mode

This means:

• 1 commit exists locally on the server
• 16 commits exist on GitHub

So the branches had diverged.

Why This Happens (Important)

This usually happens when:

• Someone runs git commit directly on a server
• A previous deployment used git pull with merge commits
• History between local and remote is no longer linear

Git refuses to guess whether you want to:

• Merge
• Rebase
• Or reject changes

So it throws an error.

Deep Diagnosis

We inspected the commits:

git log --oneline origin/main..HEAD

Enter fullscreen mode Exit fullscreen mode

Result:

6d9046b Merge pull request #222

Enter fullscreen mode Exit fullscreen mode

Then:

git log --oneline HEAD..origin/main

Enter fullscreen mode Exit fullscreen mode

Showed multiple new GitHub PR merges.

Conclusion:

The server was behind GitHub
The “local commit” was already part of repo history
No real production changes existed on server

The Real Fix (Production Safe)

For deployment servers, you should NEVER rely on git pull.

Instead, use a deterministic reset:

git fetch origin
git reset --hard origin/main

Enter fullscreen mode Exit fullscreen mode

Then redeploy:

docker compose down --remove-orphans
docker compose up --build -d

Enter fullscreen mode Exit fullscreen mode

Why This Works

This approach ensures:

• Server always matches GitHub exactly
• No merge conflicts in production
• No accidental local commits survive
• Fully reproducible deployments

This is the standard CI/CD pattern used in production environments.

The Broken Approach

Avoid this on servers:

git pull

Enter fullscreen mode Exit fullscreen mode

Why?

Because it:

• May trigger merge conflicts
• Depends on local history state
• Can break deployments unexpectedly

Best Practice Deployment Script

cd opt/yourprojectdirectory

echo "Fetching latest code..."
git fetch origin

echo "Resetting to latest main..."
git reset --hard origin/main

echo "Rebuilding containers..."
docker compose down --remove-orphans
docker compose up --build -d

echo "Deployment successful"

Enter fullscreen mode Exit fullscreen mode

Key Lesson

Production servers should not “merge code.”
They should mirror GitHub exactly.

Conclusion

This issue looks scary at first, but it’s actually a simple Git history mismatch problem.

Once you understand:

• HEAD
• origin/main
• divergence

…you can fix it in under 30 seconds.

If you’re doing DevOps or managing deployments, this is one of those fundamentals that will save you from late-night production panic.

If you enjoyed this breakdown, I’ll share more real-world DevOps debugging stories like this.