Perhaps you would like one of the monorepo management tools like Lerna?

In general, the best advice is to avoid nested git projects as much as possible (even though tools like git submodules exist, they are more footguns than you want them to be). You either want to reorganize your folder tree so that your git projects are only ever side-by-side rather than nested, or that there is only one repo for all of them ("monorepo"), depending on your preferences and when/how you expect to share them.

Perhaps you're looking for something like submodules?

Just create a Git submodule, and then push from within the submodule, like so: https://stackoverflow.com/a/5814351.

Ten years ago I was told to never use Git submodules.

Five years ago I inherited a project that had four repos sharing a Git submodule.

Now I tell people to never use Git submodules.

I think it very much depends how you use them. A great option to manage submodules is TwoSigma's "git-meta" https://github.com/twosigma/git-meta.

There's also just "meta" which is a cleaner way to approach the functionality of submodules https://github.com/mateodelnorte/meta.

I've not used them myself but a lot of people strongly dislike git submodules. A recent thread on the topic: https://news.ycombinator.com/item?id=26165445

I’ve some ideas based on recent work, but I want to make sure I understand your use case: should changes to A and B be independent, but A and B require each other to do useful work?

While mid-reply and defining what the problem is, I realized a solution would be to just ignore the nested git project B, and deal with them separately. I must admit my original question wasn't well thought out, as I can't recall why it was important that there be a relationship between A and B at all, even if they are of the same project.

Mid-reply context preserved below.

----

I have a git-inited folder A, called 'Build my web app'. Inside it, it has non-source-code stuff like pictures, pdfs, notes. Also inside it is a folder B, called 'my-web-app-js', which is source code.

[Problem was that making a commit in project B would trigger unexpected changes in A]

The non-source code stuff can be ignored via .gitignore (more on that in a moment), assuming you do not want it in the repo at all.

Your 'B' use case sounds like one we have right now: A framework, if you will ('A') and apps delivered via that framework ('B', 'C', etc.). Eventually, we will deliver A as a package and the apps as plug-ins to that package (more or less) but right now they all live together (npm run start in A brings in the apps in B, C, etc.).

Our top-level folder has a .gitignore that looks like this:

  *
  !thisProjectFile.js
  !that.css
  !images/\*
  !otherArtefacts/\*

where the items preceded by ! are all in the A repo, things we want git to consider when in A but not in B, C, etc.

In A's top-level folder, do a git clone of the repos for B, C, etc., and their folders will be created in that folder, but

  1. All git operations in A will ignore B, C, etc., because of the .gitignore, and

  2. Operations in B, C, etc., will ignore A, because it is "outside"

Works well enough for now.