why does the Pull Request resolve merge conflict window has a timer?

[misterjcvela]

I spent quite a bit of time resolving merge conflicts across several pages, and when I finally clicked the merge button, the system told me my time was up and I had to start over. So... I had to start over indeed.

[AbhinavPabbaraju]

This behavior is actually intentional and relates to how GitHub handles conflict resolution sessions behind the scenes.

Why there is a timer

When you click “Resolve conflicts” in a Pull Request, GitHub:

• Creates a temporary working state of the repository
• Locks in the current base + head commits
• Lets you edit files in the browser

This session is not permanent — it has a timeout.

---

Why your changes were lost

While you were resolving conflicts:

• The session likely expired due to inactivity or time limit
• OR the base branch may have changed (new commits pushed)

When that happens:

• GitHub invalidates your merge state
• You’re forced to restart conflict resolution

---

Why GitHub does this

This design exists to ensure:

1. Consistency
   The merge is based on a specific snapshot of the repo. If things change mid-way, your resolution may become invalid.

2. Concurrency safety
   Multiple contributors might push changes while you're editing conflicts.

3. Performance & resource management
   GitHub cannot keep temporary merge environments alive indefinitely.

---

How to avoid this issue

1. Resolve conflicts locally (recommended)

Instead of using the web UI:

git checkout your-branch
git pull origin main
# resolve conflicts in your editor
git add .
git commit
git push

This way:

• No time limit
• Full control
• Better tools for resolving conflicts

---

2. Work quickly in the web editor

If using GitHub UI:

• Avoid switching tabs for too long
• Resolve conflicts in one go

---

3. Keep your branch updated

Before resolving:

git fetch origin
git rebase origin/main

This reduces chances of conflicts changing mid-process.

---

Summary

The timer exists because GitHub’s conflict editor is a temporary session, not a persistent environment.
If the session expires or the base changes, GitHub forces a restart to ensure correctness.

---

Pro Tip

For anything beyond very small conflicts, always prefer resolving locally — it’s faster, safer, and much more reliable.