I’m working with a Vue.js boilerplate project that I want to use as a base for several different applications. The problem is that GitHub only lets you fork a repository once per account.
My workflow looks like this:
- I fork the original template repo
- Clone it locally and build my first app
- When I want to start a second project using the same template, I can’t fork it again
To work around this, I tried cloning the original repo directly and then changing the remote URLs:
git clone https://github.com/original/VueBoilerplate.git
cd VueBoilerplate
git remote remove origin
git remote add origin [email protected]:myaccount/VueAppTwo.git
git remote add upstream https://github.com/original/VueBoilerplate.git
git push -u origin main
This works for getting my code up to GitHub, but the repository page doesn’t show the fork relationship like it would with a normal fork. The “forked from” text doesn’t appear at the top of the repo.
Is there any way to make GitHub recognize and display this fork relationship even though I created the repo manually? I want people to see where the project originated from.
GitHub creates fork relationships when you make the repo, not from git history. Clone and push manually? You lose that connection forever. I’ve hit this wall on tons of Vue projects. Best workaround: use GitHub’s import feature instead of cloning. Hit Sign in to GitHub · GitHub, click ‘Import a repository,’ paste the template URL. You get a clean copy without fork limits, but no fork badge. For updates, I keep a remote to the original repo and cherry-pick changes. Import beats manual cloning and lets you control which template updates actually make it into your project.
gitHub’s fork detection is annoyingly rigid - once you manually clone, that relationship’s gone for good. I’ve hit this exact issue before and just ended up crediting the original repo in my project description and readme. Not perfect, but it works for attribution. You could try gitHub CLI with gh repo fork but you’ll still bump into that one-fork-per-repo limit.
github’s API has an undocumented trick for this, but it’s super finicky. I tried the hub CLI tool with different flags but couldn’t get the fork badge working retroactively. Honestly, just create a clear badge in your README pointing to the original - looks cleaner than github’s default fork text anyway.
Hit this exact issue with multiple client projects using the same starter template. GitHub hardcodes the fork relationship when you create it - you can’t add it later through manual cloning. I’ve found a workaround using template repos plus good documentation. If you can’t convert the original to a template, keep a private fork for upstream changes and use that as your base for new projects. It’s messy but works. For attribution, I stick a clear link in the repo description and README pointing back to the source. Most devs get this approach since GitHub’s forking limits are a known headache.
Nope, you can’t retroactively create a fork relationship after manually cloning and pushing to a new repo. GitHub only recognizes forks when you use their fork button or API. Here’s what I’d do instead: convert the original boilerplate to a template repository (in settings). Then you can spin up new repos from it whenever you want. Templates don’t maintain connections to the source either, but the workflow’s much cleaner. For your current situation, just add a note in your README crediting the source project with a direct link. Not as neat as GitHub’s fork indicator, but it handles attribution and helps other devs find the original template.
GitHub bakes the fork relationship in at creation, so manual cloning kills that connection for good. The workarounds people mentioned work, but they’re tedious manual processes.
I just automate the whole thing. Set up a process that watches your template repo, auto-creates new repos when needed, handles all the git stuff, and updates your docs with proper attribution links.
The automation does cloning, remote setup, initial commits, and can sync template updates across all your projects. No more manually tracking what needs updates or fighting GitHub’s fork limits.
I use similar automation for client projects from shared templates. Saves me hours weekly and keeps everything documented.
Check out https://latenode.com for setup.