How Do You Convert a Forked Jekyll Repository into a Fully Independent Clone?

By -

Forked Your Jekyll Theme but Now Want Full Control?

Forking a Jekyll theme from GitHub is a great way to start quickly. But over time, many developers realize that being tied to an upstream repository limits their ability to customize, scale, or move platforms.

Thankfully, it’s possible to safely convert your forked repo into a clean, standalone clone — without losing any code, posts, or history.

Why Convert a Forked Repo Into a Clone?

Here are some common reasons:

  • You want to use unsupported plugins, layouts, or build tools
  • You plan to migrate to Netlify, Cloudflare Pages, or self-hosting
  • You're tired of upstream merge conflicts when the theme updates
  • You want to build a private or commercial product from the base theme

Step-by-Step: Detach and Convert Fork to Clone

Step 1: Clone Your Forked Repository Locally

Start by cloning your forked project to your local machine:

git clone https://github.com/yourusername/your-forked-repo.git
cd your-forked-repo

This gives you a working directory with the full commit history.

Step 2: Remove GitHub's Fork Relationship

GitHub doesn’t let you remove a fork status manually. So you’ll need to push your local code into a brand-new, non-forked repository.

  1. Create a new repo on GitHub (don’t fork — click "New Repository")
  2. Note the remote URL (e.g. https://github.com/yourusername/my-independent-site.git)

Step 3: Remove the Existing Remote and Add the New One

git remote remove origin
git remote add origin https://github.com/yourusername/my-independent-site.git

This detaches your project from the forked repo and prepares it for the new target.

Step 4: Push Everything to the New Repo

git push -u origin main

Or if your default branch is master:

git push -u origin master

Now your entire history, branches, and commits live in a clean repo — no longer tied to the upstream theme.

Step 5: Optional — Delete the Old Fork

If you want to avoid confusion or accidental edits, go to your forked GitHub repository and delete it (or archive it).

Bonus: Clean Up Upstream References

Check if You Still Have the Upstream Remote:

git remote -v

If Needed, Remove It:

git remote remove upstream

Now What? Own and Rebuild with Freedom

You’re now free to:

  • Add any plugins — including custom or unofficial ones
  • Refactor layouts without worrying about theme updates breaking your work
  • Integrate GitHub Actions or Netlify build pipelines
  • Convert into a modular Jekyll structure with collections and reusable includes
  • Prepare for custom domains, SEO tools, multilingual architecture, and more

Advanced: Rename Git History (If Needed)

If you want to scrub all evidence of the original fork in your history (e.g., for white-labeling), consider using:

  • git rebase -i to edit commits manually
  • git filter-repo (for advanced full-history rewrite)

This step is optional and often unnecessary unless you're reselling the theme.

Final Tips for Going Fully Independent

  • Set up a Gemfile and manage plugins with Bundler
  • Break out your layout into components under _includes
  • Use _config.dev.yml and _config.prod.yml for multiple environments
  • Document your new architecture in a README.md for future collaborators

Conclusion: Don’t Let the Fork Define You

Starting with a fork was a great shortcut. But now, it’s time to take full ownership of your Jekyll site. Converting to a standalone clone gives you the flexibility to grow, innovate, and deploy however you want — no upstream strings attached.

It’s not just about changing Git remotes. It’s about changing your mindset: from inheriting code to owning your platform.