Introduction

The short answer is that one filesystem directory cannot cleanly be the working tree of two unrelated Git repositories at the same time. What Git supports well is a directory tree that contains a repository at the top level and another repository inside a subdirectory, or multiple working trees for the same repository using git worktree.

What Git actually allows

Git identifies a repository by its .git directory or .git file. Once a directory is already the working tree for one repository, pointing a second unrelated repository at the exact same tracked files is not a normal or well-supported setup.

There are three common patterns that people really mean when they ask this question:

• a nested repository inside a subdirectory
• a submodule managed by the parent repository
• two separate checkouts sitting next to each other as sibling directories

Those are all valid. "Two unrelated repos controlling the same directory contents" is where trouble starts.

Nested repository inside a subdirectory

A simple valid layout is a parent folder containing one repository, plus a child folder that is its own repository.

1mkdir project
2cd project
3git init
4
5echo "root repo" > README.md
6git add README.md
7git commit -m "init root repo"
8
9mkdir plugin
10cd plugin
11git init
12echo "nested repo" > README.md
13git add README.md
14git commit -m "init nested repo"

Now project/.git controls the parent repository, and project/plugin/.git controls the nested one.

This works, but the parent repository will usually see the nested directory as just a directory unless you intentionally track it as a submodule. If you accidentally add the nested repository contents from the parent, you can create confusing states.

When a submodule is the better answer

If the inner repository is supposed to remain an independent project but still be referenced by the outer project, use a submodule.

1git init app
2cd app
3git submodule add https://example.com/shared-lib.git vendor/shared-lib
4git commit -m "add shared library as submodule"

With a submodule, the outer repository stores a pointer to a specific commit of the inner repository. That is much cleaner than copying files around or trying to make one directory belong to two repos at once.

Submodules are useful when:

• the nested code has its own lifecycle
• the outer repo should pin a specific version
• the nested code needs its own remote and commit history

They do add workflow overhead, so use them deliberately.

When you really want sibling repositories

Often the cleanest fix is not nesting at all. Put the repositories beside each other.

1mkdir workspace
2cd workspace
3git clone [email protected]:frontend.git
4git clone [email protected]:backend.git

This avoids accidental cross-tracking, confusing .gitignore behavior, and awkward tooling assumptions. If the two projects are truly separate, sibling repositories are usually simpler than any shared-directory trick.

git worktree is for one repo, not two unrelated repos

People sometimes discover git worktree and think it solves the "two repos in one directory" problem. It does not. git worktree lets one repository have multiple working trees, usually for different branches.

git clone [email protected]:app.git
cd app
git worktree add ../app-feature feature-branch

Now both directories belong to the same repository history. This is excellent for parallel branch work, but it is not a way to merge two unrelated repositories into one folder.

What not to do

You can technically abuse GIT_DIR, GIT_WORK_TREE, or manual .git file tricks to point different repository metadata at overlapping files. That tends to create fragile setups where status, ignore rules, and tooling behave unpredictably. Editors, CI scripts, and teammates will all have trouble understanding what is supposed to happen.

If you need shared history between projects, use a monorepo, submodule, subtree, or separate repositories with automation between them. Those are stable patterns. Overlapping Git control is not.

Common Pitfalls

A common mistake is nesting a repository and then forgetting that the parent repo can still try to add files from that directory. Decide whether the nested repo should be ignored or tracked as a submodule.

Another mistake is using submodules when the team is not prepared for the extra workflow. Submodules are valid, but everyone has to understand update, clone, and commit behavior.

A third mistake is using git worktree for the wrong problem. It solves multiple checkouts of one repo, not multiple unrelated repos in one working tree.

Summary

• One directory should not normally be the working tree of two unrelated Git repositories.
• Nested repositories inside subdirectories are valid, but they need careful handling.
• Use submodules when the parent repo should reference an independent child repo.
• Use sibling repositories when the projects are simply separate.
• Use git worktree only when you need multiple checkouts of the same repository.