You can now open anything (that you have access to) on GitHub directly from VS Code with the official Remote Repositories extension.
And I do mean directly. That means no clone. No download. No looking at your dev folder and wondering why on earth you structured your projects this way and OMG SO MUCH REGRET.
Listen, it's ok. Nobody is happy with how they have cluttered up their once pristine dev environment. Inside my "c:\dev" folder is an entire season of Hoarders and no, I'm not going to delete that jQuery project. I might need it some day.
Let's look at how the new Remote Repositories extension for VS Code lets you casually interact with any project on GitHub without having to clone a thing.
How to Install the Remote Repositories Extension
First, you'll need to install GitHub's Remote Repositories extension for Visual Studio Code.
To open a GitHub repo, click on the green indicator in the lower left-hand corner of VS Code.
You'll see a new option for "Open Remote Repository".
If you have other Remote extensions for VS Code installed, you'll see a lot more options in this list, so just search for the right one.
You can also get to this option from the Command Palette if clicking on things with a mouse is too much trouble. I see you VIM people.
You can paste in the URL to a GitHub repo if you happen to just have that hanging around on your clipboard (weird) OR you can browse GitHub by selecting "Open Repository from GitHub". The third option lets you open a Pull Request branch so you can pretend to thoroughly review it.
VS Code will reopen and you'll see that repository just like you were working with it locally. But you're not. You're looking at it on GitHub through the window of VS Code.
You'll notice disclaimers about "some features" not being available and that you are in "Restricted Mode".
This is part of the new Trusted Workspace settings in VS Code.
By default, VS Code now turns off Tasks, debugging, some workspaces settings and any extensions that might try and execute something the first time you open a folder. You have to tell VS Code that it's cool, you know and trust this code and you're 100% sure it's not going to shutdown your oil pipeline.
Ok – so scary security warnings dismissed, what can we do here?
How to Work with a Remote Repository
You have full editing capabilities with a big difference being that you don't have to save anything. Your changes are just saved as you go.
They aren't automatically committed to GitHub. In order for the changes to be saved to the repo, you'd have to commit them from the source control view.
You don't have to push them because you are already on GitHub. A commit is a commit – no push required. This is the same as if you were editing the file directly on GitHub. Because you essentially are.
As far as the editing goes, you get much of what you would expect in VS Code.
Language specific intellisense works. For instance, if you started writing a fetch, VS Code will help you with that because it knows about fetch.
But you do not get the intellisense on project files that VS Code gives you when it runs your project locally.
For instance – locally, VS Code knows about useEffect which comes from the react import. It knows this because it's inspecting the import which is a node module.
But with Remote Repositories, we're looking directly at GitHub and the node_modules folder never ever gets pushed to GitHub unless you are me 10 years ago. So there is no intellisense for useEffect because that code doesn't actually exist in the repo.
You can use things like Emmet to compose HTML and you get the nice split screen Markdown preview that you probably love like I do.
You can also use "Find" and "Find in Files".
Many things that work locally work the same way when connected to a project directly on GitHub, but some do not. Which is the vaguest thing anyone has ever written on the internet, but understanding how this all works will shed some light on what you can reasonably expect.
How It Works
VS Code has a file system provider API that has been around for some time. What this API does is provide a mechanism to consume an API as if it were a physical file. In this case, the Remote Repositories extension is consuming and mapping the GitHub API to a "Virtual Workspace" in VS Code.
This means that any extension that is trying to work with physical files is not going to work until the extension author updates their extension to use the Virtual File System API. Which means that things that don't work today might work in the future as extensions are updated.
So what can you expect to work? Themes, key bindings, snippets and grammar extensions. These types of extension typically don't execute any code, so you know they aren't trying to work with files which means it's safe (internet safe) to assume they'll work in Remote Repositories.
But some things won't ever work because you need local file access to do them.
A prime example of this is Prettier. Prettier is a CLI tool that alters your local files by reformatting your code. Since there is no local file access, it doesn't currently work with Remote Repositories. So nobody is going to change those double quotes to singles automatically or put that semicolon back. Or remove it. I want out of this paragraph.
In fact, you can't run a Remote Repositories project at all. If you open the terminal while connected to a Remote Repository, it will be there. But it won't have any access to this project.
Which is legit because the project doesn't actually exist on your machine. So how do you get a terminal if you find you actually do want to run the code you are working with, or just upgrade your editing experience to full-blown VS Code?
How to Switch to Full VS Code
"Continue on my wayward son" - some band from the 70's
If you click in that green bottom left-hand part of the Status Bar that says "GitHub" right now, you'll see an option to "Continue Working On".
This option will let you either clone the project locally, or open it in a GitHub Codespace.
If you're in the Codespaces Beta (request access here), you can open the repo in a Codespace. This is VS Code running in the browser, but backed by a compute environment where you can run anything just like it was on your desktop. This works because VS Code was originally designed to be a web app. True story.
Or clone it locally! Crack open that c:\Users\you\Documents\GitHub folder that you regret choosing to put all your projects in because now your "Documents" folder is being backed up to OneDrive and it's got 900 terabytes of node_modules in it. Well - now it's got 920.
Cool. But Why?
The natural question you should be asking yourself right now is, "Very cool! But why do I need this?"
Excellent question. You are preceptive and people like you.
Consider the following scenarios...
- You want to browse a GitHub repo and look at the code. GitHub is a great site, but it's not the best way to quickly jump through files and examine a project. You really need an editor for that and Remote Repositories cuts out the cumbersome and often bandwidth intensive step of cloning simply to look at code.
- You want to make a quick update. While you would almost always do heavy coding locally, you might want to pop into a repo and make a quick change without having to sync your local environment. README's come to mind, but this could be any sort of small change.
- You are working on Markdown. If you're working on documentation, README's or other Markdown in GitHub, there's no need to clone the repo locally anymore to do that. Unless you are running a local server to preview that Markdown, using the built-in preview is a much faster way to pound out 5K words about your API.
- You want to review a PR. Seems self explanatory.
Get More Remote
Now that you have Remote Repositories, you can clean out that dev folder. Just right-click and delete something. See how good that feels?
Remote Repositories is one of several ways to do "Remote" development with VS Code. Check out these other options to use VS Code to connect to almost anything.
- Dev Containers - Use a Docker container as a full-featured development environment with
- Remote SSH - Open a remote folder in VS Code on any remote machine over an SSH connection
- Remote WSL - To use your WSL as the full-time backing runtime environment in VS Code.