If you’ve ever felt a moment of panic when your Git repository suddenly seems to have dangling commits with the upstream right after your maintainer squash-merged, you are not alone. It’s not a sign that you’ve broken anything; it’s a collision of two different philosophies of history. Your branch tells the epic story of your journey, with every trial and error documented. In my situation, the upstream maintainer — also happens to be my manager, who has a sixth sense for when I’m unsure about something, often prefers a clear and concise summary. The result? My fork is left holding the full, detailed history, while upstream has only the final release. While there are many paths to reconcile, I will reveal the one that worked best for me - after a Google search. Let’s break down a typical scenario to understand what’s really happening. Scenario: Implementing a New Feature Scenario: Implementing a New Feature You are contributing to a project, and you are implementing a new feature. Your workflow looks like this: You implement a new feature: You started to develop a new feature in the master branch instead of creating a new branch. At your local branch, you diligently create a commit with the core implementation. You implement a new feature: You received feedback: You submitted a Merge Request(MR). The maintainers review your code and request some refactoring as you made 200 lines of code unnecessarily. You make the changes and create a follow-up commit. At this point, your branch has a clean, detailed history of work. You received feedback: The Maintainer squashes and merges: To keep the main project’s history linear and clean, the maintainer uses the “Squash and Merge” option. This action takes all the commits that you push and combines them into a single commit on the project’s main or master branch. The Maintainer squashes and merges: The Aftermath: A tale of two histories: This is where the apparent “out of sync issue” arises. Let’s visualize the divergence to check the final state of the repositories: upstream(main) and origin. The out-of-sync problem: The out-of-sync problem: origin/master branch: Has 2 commits -> agent handoff -> update agent handoffupstream/master: Has 1 commit-> squashed merge (which contains both changes)Result: Your origin has 2 commits that upstream doesn’t have as individual commits origin/master branch: Has 2 commits -> agent handoff -> update agent handoff upstream/master: Has 1 commit-> squashed merge (which contains both changes) Result: Your origin has 2 commits that upstream doesn’t have as individual commits Let’s get this fixed before my manager’s frown becomes a permanent feature on his face 😉 .    .    . .    .    . 1. Hard Reset 1. Hard Reset A hard reset resolves the divergence by rewinding your local main branch to the ancestor commit 019b52b. This effectively removes the conflicting two local commits that were causing the divergence, and there will be a clean, conflict-free state that mirrors the upstream. git reset --hard 019b52b git reset --hard 019b52b However, be cautious when you use --hard option, it will permanently discard your uncommitted changes in your local branch. Your current state looks like this: After the git reset: After the git reset: 2. Fetch Let’s update all the newest commits, branches from the upstream repository without merging them into your local branches. It’s a safe and read-only synchronization with the upstream repository. While it updates your repository’s knowledge of the upstream changes, the magic lies in what it leaves alone: your half-baked local branches, experimental code, and working files will remain completely untouched. git fetch sets the next stage for you — integrate changes with a merge? Prefer a clean, linear history with rebase? Whatever you choose to do, you should be able to proceed with perfect information and zero surprises. git fetch git fetch git fetch upstream git fetch upstream Before git fetch: Before git fetch: After git fetch: After git fetch: 3. Rebase 3. Rebase Since you had no local commits after the reset, this simply fast-forwarded your local branch with a sequence of commits to match upstream/master exactly. It creates a linear, clean project history. Unlike merging, which creates an unnecessary merge commit. git rebase upstream/master git rebase upstream/master 4. Push 4. Push git push --force-with-lease origin master git push --force-with-lease origin master The final step is to publish this clean history on the local branch to the remote repository. This command will replace the outdated, conflicting commit history with the new, linear timeline, fully resolving the synchronization issue between your fork and the upstream source. As a result, the personal fork’s branch is realigned, now mirroring the desired linear project history and eliminating the previous divergence. Unlike a standard force-push, the — force-with-lease flag provides a safety check by ensuring that no unexpected changes have been made to the remote branch by others. .    .    . .    .    . Issues Issues When you try to force-update, you might encounter the following issues if your branch is protected in the personal origin repository: Failed to push some refers to ‘git.your-company.net: username/repository.git’ Failed to push some refers to ‘git.your-company.net: username/repository.git’ Failed to push some refers to ‘git.your-company.net: username/repository.git’ To make it a temporarily unprotected branch, 1. Go to Project > Settings > Repository. Click ‘Expand’ from the ‘Protected branches’ section. 1. Go to Project > Settings > Repository. Click ‘Expand’ from the ‘Protected branches’ section. 2. Click the 'Unprotect' button. 2. Click the 'Unprotect' button. 3. Run the command again, 3. Run the command again, git push --force-with-lease origin master git push --force-with-lease origin master .    .    . .    .    . The Current State of Origin and Upstream The Current State of Origin and Upstream git branch -avv
* master                     8713289 [origin/master] update agent handoff
  remotes/origin/HEAD        -> origin/master
  remotes/origin/master      8713289 update agent handoff
  remotes/upstream/master    8713289 update agent handoff git branch -avv
* master                     8713289 [origin/master] update agent handoff
  remotes/origin/HEAD        -> origin/master
  remotes/origin/master      8713289 update agent handoff
  remotes/upstream/master    8713289 update agent handoff The local master branch (commit 8713289) is perfectly in sync with both origin/master and upstream/master. This is the ideal state after a successful sync operation, which is a standard and healthy forking workflow. .    .    . .    .    . Important Notes for Future This was essentially a nuclear option that completely wiped the divergent history and started fresh from the upstream. You’ve resolved the issue; it’s time to re-protect your master branch again. Browse to repository settings and create a new branch protection rule.Consider using feature branches next time to avoid such unnecessary troubles.Always git fetch upstream before starting work to ensure you’re starting from the latest code. You’ve resolved the issue; it’s time to re-protect your master branch again. Browse to repository settings and create a new branch protection rule. Consider using feature branches next time to avoid such unnecessary troubles. Always git fetch upstream before starting work to ensure you’re starting from the latest code.

How to Deal With A Diverged Git Repository: A Guide

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

How to Contribute to GitHub Without Breaking Anything

You Don’t Hate Coding — You Hate Following Tutorials

Journalot – Building a Git-Backed Journaling CLI That Developers Actually Use

Pocket Guide to SEO: Title, Keywords, Headings, and Meta Descriptions

8 underrated Git commands every programmer should know (not the usual pull, push, add, commit)

A Guide to Staying Sane While Working with Git

How to Contribute to GitHub Without Breaking Anything

You Don’t Hate Coding — You Hate Following Tutorials

Journalot – Building a Git-Backed Journaling CLI That Developers Actually Use

Pocket Guide to SEO: Title, Keywords, Headings, and Meta Descriptions

8 underrated Git commands every programmer should know (not the usual pull, push, add, commit)

A Guide to Staying Sane While Working with Git

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps