Fake forking your own repo for maintainability purpose

Question

I am not sure how to precisely describe the issue so I will use an example, say i have the following:

• RepoA - original repo with some base code, libs, framework, folder structure, etc
• RepoB - ideally a fork/branch... but can't fork your own repos and I want a separate repo, so branch doesn't work

The goal is to work on RepoB and be able to merge changes that have been made inside RepoA into the code, so if a new feature is developed on RepoA I can just merge it into the RepoB and continue development. Essentially it is a "branch" of a different repo.

Is this somehow possible?

I've also thought of maybe somehow using NPM to get this functionality but I am not sure at all how to/how it works with NPM, all my work on company projects would have a single repo and feature branches, so I've never encountered this problem.

EDIT: As per comments

The idea is to setup a repo structure with all the things that I commonly use in multiple projects, such as boilerplate, UI components, blank server, router configurations, basically create a "framework" that has no features, other than being a "work environment" that can be built upon.

Then, for each project, i'd create a specific repo and drag in the framework, for lack of the better words. But I want to be able to "merge" additional things that might get added to framework at a later point into the repo.

I do not want to branch this framework repo because I want the repositories on github to be separate. I'd be fine with somehow adding some form of dependency, or even use NPM, but I do not know how would I use NPM for this.

Answer 1

So after some fiddling around with what Mohana Rao suggested I've managed to get what I need.

One-time-use

We are doing all our work inside RepoB , say, on a master branch:

git remote add base <link-to-RepoA>
git checkout -b new-feature-import
git pull base master --allow-unrelated-histories
git checkout master
git merge new-feature-import
git branch -D new-feature-import

Saving for future usage:

git remote add base <link-to-RepoA>
git fetch base
git checkout -b base-integration
git branch --set-upstream-to=base/master
git pull --allow-unrelated-histories
git checkout master
git merge base-integration

With the second method allowing you to switch to a branch at a later point and just do a pull to get the latest changes. Obviously any merge conflicts you'd have to resolve and obviously you should not be pushing from the base-integration branch back to your RepoA if you opt to go with this "more convenient" solution.