Fixing the GitHub Fork Trap: How to Recover Your Contribution Map Without Losing History

I recently ran into a massive headache while doing the 90DaysofDevOps Challenge.

😃I did what everyone does: I forked the official repository, cloned it locally to my machine, and started grinding through the daily tasks. By Day-17, my local git log showed a perfect timeline of over 160 commits.

Then I looked at my GitHub profile contribution map.

😲Completely blank. Not a single green square.

It turns out I had hit two separate silent killers that mess up GitHub portfolios.

Here is exactly what went wrong, why it happened, and the step-by-step fix I used to get my green map back without losing a single day of history.

🫥Why My Map Stayed Grey : The Two Problems

1. The Fork Trap

GitHub has a strict rule to prevent profile spam: commits made to a forked repository do not count toward your contribution graph. GitHub treats forks as temporary staging grounds. The only way they show up on your map is if they are part of an active Pull Request to the original creator's repo.

2. Misconfigured Commit Emails

Even if you fix the fork issue, GitHub won't give you credit if it doesn't know who made the commits. If your local terminal is using a default email like root@localhost or an old work email instead of your verified GitHub email, GitHub's indexing servers will simply ignore the commits because they don't match your account.

🤩The Strategy: Multi-Remote Architecture

To fix this safely, I didn't delete my folder or download a fresh, empty repository. Instead, I created a brand-new, independent repository that I completely own, and taught my local terminal to talk to both repositories at the same time.

Because Git permanently bakes timestamps and emails into your history, pushing your commits to a standalone repo causes GitHub to retroactively backdate your profile map. Everything turns green instantly.

Here is the exact implementation playbook.

Step 1: Create a Completely Blank Repo

Go to GitHub and create a new repository called 90DaysOfDevOps-Core. Set it to Public.

⚠️Warning Crucial: Do NOT check the boxes for a README, license, or .gitignore. Leave it 100% empty.

🤔Why? : If GitHub creates an initial file on their servers, it generates a commit in the cloud that your local machine doesn't know about. When you try to push your history, Git will reject it with a non-fast-forward error. Leaving it blank allows your local history to slide in cleanly.

Step 2: 🤞Reorganize Your Local Terminal Shortcuts

Open your terminal, navigate straight into your active project folder (cd ~/90daysDevops), and run these commands to swap your remote pointers:

1. Rename the old fork link so it isn't your default 'origin' anymore

   git remote rename origin fork
   

2. Add your brand new blank repo as your primary 'origin' using SSH

   git remote add origin git@github.com:Alok-Nayak/90DaysOfDevOps-Core.git
   

3. Add an upstream link to pull future assignments from the course creator

   git remote add upstream https://github.com/TrainWithShubham/90DaysOfDevOps.git
   

If you run git remote -v, your layout should now look like this:

fork	git@github.com:Alok-Nayak/90DaysOfDevOps.git (fetch)
fork	git@github.com:Alok-Nayak/90DaysOfDevOps.git (push)

origin	git@github.com:Alok-Nayak/90DaysOfDevOps-Core.git (fetch)
origin	git@github.com:Alok-Nayak/90DaysOfDevOps-Core.git (push)

upstream 
https://github.com/TrainWithShubham/90DaysOfDevOps.git (fetch)
https://github.com/TrainWithShubham/90DaysOfDevOps.git (push)

Step 3: 📭 Fix Your Commit Email

If your terminal was using the wrong email, you need to fix your past commits and lock down your future ones so GitHub recognizes you.

First, fix your identity for all future commits globally:

git config --global user.name "Alok Nayak"
git config --global user.email "alok@gmail.com"

Next, rewrite the email on your past commits instantly using a basic git amend command:

git commit --amend --reset-author --no-edit

(This command updates the author metadata on your history to match your newly configured global email without messing with your code changes).

Step 4: ✅ Push History and Light Up the Map

Now, push your entire history to your independent repository. Check your local branch name (git status will show master or main) and execute:

git push -u origin master

(The -u flag sets origin as your default tracking branch for future pulls).

Wait for sometime, refresh your main GitHub profile page, and your timeline will instantly update with all your missing green squares!

Step 5: 🧹 Clean Up Your Profile Metadata

Now that your history is pushed, you can safely add descriptions and tags to the new repository directly on the GitHub website.

🧐Why now?

• Keeping it completely blank only matters before your first push to avoid merge conflicts. Now that your history is sitting safely in the cloud, you can safely click the Gear Icon (Settings) next to the About section on your GitHub repository page and add a description.

☀️Daily Workflow Moving Forward🌙...

Now that your remotes are linked up, this is exactly what you run at the end of every day to keep both repos updated:

# 1. Commit your day's work locally
git add .
git commit -m "Day 18: Completed shell scripting tasks"

# 2. Push to your own repo to keep your contribution map green
git push origin master

# 3. Push to your fork to keep your course assignments updated
git push fork master

If the core repository templates ever updates, then grab them cleanly with:

git pull upstream master

Real-World DevOps Use Case: Enterprise Mirroring

This isn't just a workaround for a profile map.. handling multiple remotes is a daily reality in enterprise engineering.

Safe Open-Source Patching

In production, your company might rely on an open-source binary or a public Terraform module. If your security team finds a critical vulnerability, you cannot wait weeks for public maintainers to merge a patch. You have to secure your live systems today.

To handle this safely, you use this exact three-remote architecture:

• upstream: Points to the official public open-source project. You pull from here for official releases.

• origin: Points to your company’s internal, private enterprise mirror. This is where live production actually runs. Your quick security patch gets pushed here immediately to keep your infrastructure safe.

• fork: Points to your company's public staging copy on GitHub, used exclusively to submit a Pull Request back to the open-source community when you have time.

😎The Automation Cheat Code: Push URL Broadcasts

Manually running separate push commands every day in production introduces a high risk for human error. To automate this locally so you never forget to update a repository, you can tell Git to broadcast your code to multiple endpoints simultaneously:

# Set your primary origin URL
git remote set-url --add --push origin git@github.com:Alok-Nayak/90DaysOfDevOps-Core.git

# Append your fork URL to the exact same origin shortcut
git remote set-url --add --push origin git@github.com:Alok-Nayak/90DaysOfDevOps.git

This updates the local .git/config file. Now, running a single git push origin master streams the data to both locations on GitHub instantly, preventing repository drift entirely.

🥱The Panic Button: How to Undo Everything

Remotes are just text pointers. If you ever want to completely return to your previous basic setup, you can wipe out these configurations instantly without risking your local files:

git remote remove origin
git remote rename fork origin

Your local files and history will stay 100% intact on your hard device.