What is the best way to set up respository for this development flow

Working to set up repositories for a project at work. Please bear with me while I try to accurately describe what we want to go on.

We will be using tagged releases of a github repo as our development base, and will be making mission specific changes to that code base, but never committing to the github repo, only our projects gitlab repo. There are other github repositories not included with the tagged development base releases, for configurable applications that can be imported into the development base structure, and typically live in a subdirectory (dev_base → apps). These apps will also have mission specific changes, but never committed to their respective github masters, only our projects gitlab repository. But in the case the development base or other imported applications have code updates, we still need to be able to pull those changes in and merge them with what he have been developing in our repositories.

Do I just:

cd my_repo
remote -set_url origin git@my_repo.git

clone tagged release dev_base
cd dev_base
remote rename origin upstream

cd dev_base/apps
clone appX
cd appX
remote rename origin upstream

cd my_repo, git add . , commit, push origin master

checkout -b feature_b1
does development on files inside dev_base/
cd my_repo, git add . , commit, push origin feature_b1
checkout master / merge feature_b1

checkout -b feature_b2
does development on files inside dev_base/apps/appX
cd my_repo, git add . , commit, push origin feature_b2
checkout master / merge feature_b2

Then when a baseline has been updated and we need the changes:

checkout -b update_baseline_appX_branch
cd dev_base/apps/appX
git pull upstream master --allow_unrelated_histories
(resolve impending merge)

then merge back into our project master?

Or is there a better, cleaner way to do this?

Hi @mgerton13
so basically you will be maintaining your own fork of upstream repository. you can use your favourite search engine to look for some blogs like this one

What I would do differently is that I would maintain each upstream repo in separate repository and use git submodule to have it in the main app.

+1 for this. Git submodules are a bit annoying, but this scenario is exactly what they are designed for.