Optimizing GitHub Copilot for Multi-Repository Teams in VS Code

[GittBUB]

Working across multiple repositories is common. Separate repositories for environments, backend vs frontend, and infrastructure make sense for many teams. However when code that belongs together live in different places, Copilot as well as developers can struggle. I dug into this problem and put together practical guidance you can use right away to help Copilot deliver better suggestions for everyone on the team.

Why Copilot sometimes stumbles in multi‑repo setups

Indexing

Copilot works best when it fully understands your application. It understands your application best when it can index all necessary information about it. Think of it like a new developer joining your team; they need to get up to speed on the entire application before they can effectively contribute to the codebase.

The important thing to note about indexing is that it can be done more than one way. Remote indexing is recommended for very large code bases. However if you’re using GHES, remote indexing is not an option available to you. Therefore you must ensure your code is indexed locally AND verify that you are not exceeding any local index limits. If you're unfamiliar with Copilot's indexing in VS Code, you can learn more about it here.

Tip: Indexing in VS Code is not the same as indexing your Github Repository. You can read more about Github Repository indexing here.

Incomplete Workspace

Copilot can index your VS Code Workspace, which can include code from multiple repositories. To effectively use Copilot for improving, fixing, or adding new features to an application that spans several repositories, all relevant code must first be accessible within your Workspace.

When you add more than one repository to a Workspace this is called a Multi-Root Workspace. When using a Multi-Root Workspace you do not have to open each repository directory in your Workspaces each time you begin work. You can create a Workspace file, which can be used to open all relevant directories before you begin your work. For more information on VS Code Workspaces, you can read about it here.

No Repository Access

Teams frequently manage distinct repositories for various application components to restrict access to specific individuals. Access to Github repositories is managed by roles, which you can read about here.

Sometimes this practice is applied unintentionally and can be corrected by adding developers to an existing group with read-only access or creating a new group for developers that need read-only access. Other times this practice is applied to proprietary code that every developer should not be able to clone onto their local machines. In these cases your Workspace will need sufficient documentation.

Small changes that create big wins

Now that we know some potential challenges that a multi-repo strategy can create for Github Copilot, we will dive into small changes that can improve the overall developer experience.

Don’t Rely on Auto Index

Copilot automatically builds an advanced local index if you have less than 750 indexable files.

What are indexable files?

• Common code, markup, config, and doc files (e.g., .py, .js, .ts, .go, .java, .md, .json, .yaml). VS Code recognizes most programming and text-based formats.
• File types mentioned above that are located in the VS Code Workspace that you defined.
• Files not hidden by .gitignore for VS Code, files.exclude settings and search.exclude settings.

What should you do if you have more than 750 indexable files?

• Up to 2500 files can be indexed locally
• Utilize .gitignore, files.exclude settings and search.exclude settings.
• Add these files to a Developer Experience repository for other users to reference.
• Run the Build local workspace index command in the VS Code Command Palette as described here.

Make Your Incomplete Workspace Whole

When you open a repository in VS Code and your team uses the multi-repository approach, Copilot will not be able to provide accurate suggestions. To improve the accuracy of suggestions you must open all required repositories in your VS Code Workspace. To ensure all users open all required repositories following these steps:

1. Create a code workspace JSON file using the naming convention <name>.code-workspace for your application with components that span more than one repository.
2. Add this file to a Developer Experience repository for other users to reference.
3. When opening your workspace in VS Code, go to File menu then select Open Workspace from File to select the appropriate code workspace JSON file.
4. Continue to maintain this code workspace JSON file as your application evolves.

Unblock Repository Access Blockers

Above we mentioned the importance of including all repositories needed for an application in your Workspace. What should you do when a required repository is something you cannot clone?

Assuming you cannot obtain read only access to a required repository you can:

• Request codeowners to provide contract artifacts for required APIs or packages.
• For more information on OpenAPI Specification (OAS) contract artifacts for APIs you can review examples here.
• Place contract artifacts in a central repository that you can access and open as part of your VS Code Workspace.
• If contract artifacts are not available, use Copilot to generate them!

[Djeisen642]

Can you give an example of a file? It seems to point at a path. Does this mean that everyone needs to structure their repo folders the same? I've been trying to find a good way for this to work. I tried symlinks and that does not work for Cursor or GitHub Copilot in VSCode, but it does seem to work for Intellij. So, if this works for VSCode, that would be great.