Which workflow should I use for this nested repo situation?

I am creating a git tutorial for beginners.

I'm tracking my progress such as notes, beamer slides and exercises in a git repo (repo A). I also want to create a sample git repository (repo B) with an educational commit history and ideally nest it inside repo A. I want to be able to push repo A to github including repo B.

I have found different approaches, such as submodules, subtrees and just putting repo B into repo A's .gitignore. What's the right choice in my situation?

Option A: Repo as instructions

I would recommend against trying to store the "educational git repo" as a repository at all.

As you intend to use it as an "sample git repository", I'd rather store it as a sequence of bash commands that are needed to recreate it, starting with the initial git init my-project && cd my-project.

That way, using the basic git commands already can be trained while setting up the environment. File creation can be automated, touch README.md or echo "int main() {}" > main.c, and any beginner-reachable situation should be only a few commits away.

This format is also quite common in Q&A's on this platform; example answer: Branch off master but include changes from another unmerged branch

Option B: Simply do not nest

As it is an already advanced technique to nest repos, why not prepare the possibly complex training repo as an indepdent, publically accessible repo that is only one git clone away? That way, any setup reduces to a single command, and most exercises can be reset by one call to git reset --hard origin/main (although one might need to warn against this command's frequent use outside of training situations..)

Option C: Training wheels repo webapp

There are dedicated webapps for learning more advanced branching, merging, rebasing scenarios without the "difficulty" of a real repository first. A popular one is https://learngitbranching.js.org/. In this application, you work against the visualization of the commit tree, and any real work in the working tree is simply simulated by calling git commit to create an opaque change.

The focus is on the logical relationship between commits and history manipulation. That way, one can first train oneself to mentally visualize and manipulate commit structures quickly, before going into a real repository with its added complexity of file contents and merge conflicts.