Clone and open
Beginner VS Code UI
Why this matters
Cloning is the first thing you do with any project, and the first thing that can go quietly wrong: open the wrong folder and the editor shows no source control, which looks like a broken installation and is not.
Four ways to clone
| Route | Use when |
|---|---|
| Clone Repository button in an empty Source Control view | The usual way |
| Command Palette → Git: Clone | The same thing, from anywhere |
| Signed in: pick from a list | You do not remember the URL |
git clone <url> in a terminal, then File → Open Folder |
You already have the URL and a terminal open |
All four run the same command. Being signed in adds the list of repositories you can access; without it, paste the URL from the platform's Code or Clone button (lesson 7.4).
VS Code asks where to put the clone, then offers to open it. Say yes; the clone is useless unopened.
Open the right folder
This is the part that catches people. The folder you open must be the one containing .git, which is the folder the clone created.
| You opened | Source Control shows |
|---|---|
trailguide/ |
Everything, correctly |
trailguide/docs/ |
Nothing: no .git here |
The folder above trailguide/ |
Nothing, or the wrong repository |
If the Source Control view says "The folder currently open doesn't have a Git repository", check which folder is open in the Explorer's title before assuming anything is broken.
Folders and workspaces
| What it is | When you need it | |
|---|---|---|
| Folder | One directory open in the editor | Almost always |
| Workspace | Several folders open together, saved as a .code-workspace file |
Working across two or three repositories at once |
In a multi-root workspace, the Source Control view shows one section per repository, each with its own branch and its own staged changes, which is exactly what you want and briefly disorienting the first time.
Publishing a local folder
The reverse direction: you have a folder that is not yet a repository.
- File → Open Folder on the folder.
- Source Control shows Initialize Repository; click it. That is
git init. - Stage and commit the files.
- Publish Branch appears; signed in to GitHub, it offers to create the repository and choose public or private.
- For GitLab, create the project on the web first, then add the remote (lesson 7.3).
Before publishing anything, check what you are about to include. A folder that has been worked in for a while often contains credentials, build output or personal notes; a .gitignore first, then the first commit (lesson 4.3).
How to do it
$ git clone https://gitlab.com/northwind-trails/trailguide.git
$ cd trailguide
$ code .The last line opens exactly the right folder, which avoids the mistake above entirely.
- Git: Clone in the Command Palette
- File → Open Folder to open a clone you already have
- File → Add Folder to Workspace for a second repository
- Git: Initialize Repository for a folder that is not one yet
File → New → Project from Version Control, which offers your accounts' repositories or a URL. See lesson 16.3.
The Code button on the project page gives HTTPS and SSH addresses, and Open in your IDE offers VS Code directly.
The Code button above the file list, with HTTPS, SSH and Open with GitHub Desktop; Code → Codespaces opens a cloud machine instead (lesson 10.11).
Common mistakes
- Opening a subfolder of the project, so no repository is found.
- Cloning inside another repository, which creates a nested repository that Git treats oddly.
- Cloning into a synced folder such as a cloud drive, which corrupts
.gitin interesting ways over time. - Publishing a folder without a
.gitignore, committing whatever was lying around. - Publishing as public by mistake. The choice is on the publish dialog and is easy to click past.
Try it yourself
Goal: clone, open the wrong folder on purpose, then fix it.
- Clone your practice project with Git: Clone, and let VS Code open it.
- Confirm the Source Control view shows your branch and any changes.
- Now File → Open Folder on the project's
docssubfolder, and read what Source Control says. - Reopen the project's top folder.
- Create a new empty folder elsewhere, open it, and use Initialize Repository, then look at what appears in Changes.
Expected result: you have seen the empty-view symptom and its cause, and you have turned a plain folder into a repository from the interface.
Show solution
Step 5 is worth doing once. Initialize Repository is git init, and everything in the folder immediately appears as untracked, which is the clearest demonstration of what "untracked" means: Git can see the files and has recorded none of them.