I have some questions about GitHub Workspaces

[rfalanga]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Other

Body

I've seen GitHub Workspaces mentioned here and there, but haven't had a chance to read about them until now. I get the impression that this is only for teams using Visual Studio Code (VS Code). So, Visual Studio or Rider are out.

Where I am struggling to understand is in the case of multi-root workspace, which involves more than one folder that comprise projects within the workspace. For example, suppose I have 10 repositories named Dir1, Dir2, ..., Dir10. Then I add them to a GitHub Workspace. Since each of those Dir(x) folders is its own repo, which repo contains the workspace? Do they all? Is it only the first one added to the workspace that the workspace is in that repo? Obviously, all 10 of those repos will be on their own branch, so how do I, as a developer, keep straight in the workspace which branch each is being used? Honestly, I foresee a lot of confusion using workspaces, if each of those 10 repos has its own understanding of what's going on in that workspace.

Please provide me with some clarity.

[azunox]

Hi, @rfalanga

To clarify how workspaces work, especially when dealing with multi-root environments:

• IDE Support: Multi-root workspace structures are primarily native to Visual Studio Code (and VS Code-based environments like Codespaces or GitHub Copilot Workspace). Other IDEs like Visual Studio or JetBrains Rider handle multi-repository projects differently and do not use the same workspace configuration files.

• Workspace File Location: A workspace configuration is not stored inside any single repository by default. Instead, it is saved as a separate .code-workspace file (or managed centrally by the platform if running in a cloud workspace). This file simply holds relative file paths pointing to each repository (Dir1 through Dir10) without modifying or polluting the repositories themselves.

• Managing Multiple Repositories and Branches: Each folder/repository added to the workspace remains completely independent. Each repo retains its own .git folder, commit history, and active branch. The Source Control panel displays all 10 repositories in a single sidebar, clearly showing which branch each specific repository is currently on. Changing branches or committing changes in Dir1 will not impact Dir2 or any other repository in the workspace.

[rfalanga]

Thank you very much for this! It helps clear up workspaces for me. Then I will not try to shoehorn a workspace into a git repo.

[Alfredo-vdk]

Yo, so I looked into this a bit, here's the deal:

The workspace itself isn't "inside" any of your 10 repos. When you make a multi-root workspace, you're just creating a separate file called something.code-workspace (just a JSON file) that lists paths to each of the 10 folders. That file can literally live anywhere on your machine, doesn't have to be in Dir1 or Dir2 or wherever. A lot of teams just keep it in its own little repo or folder specifically for this, so nobody's confused about "which repo owns the workspace." None of them own it, it's its own thing sitting on top of all of them.

As for the branch confusion, don't worry, that part's actually handled fine by VS Code. Even though you've got 10 repos open together, each one keeps track of its own git state completely separately. If you open the Source Control panel, you'll see each folder listed separately with its own branch, its own changes, its own commit history. So Dir1 can be on main and Dir3 can be on some feature branch and VS Code won't mix that up or get confused, it treats each root as its own independent git repo, it just happens to show them all in one window for convenience.

Basically think of a multi-root workspace less like "one big project" and more like "10 tabs pinned together so I don't have to keep opening/closing folders all day." It's just a UI convenience layer, git still works normally underneath, repo by repo.

And yeah you're right that Visual Studio (the big one) and Rider don't support this, it's a VS Code specific feature, JetBrains and Visual Studio have their own totally different ways of handling multi-project setups.