Clone (Get from VCS) and open
Beginner IntelliJ UI
Why this matters
Cloning is the first thing you do with any project. IntelliJ makes it easy and adds one wrinkle worth knowing: it indexes the project afterwards, and that indexing is not Git being slow.
Three routes
| Route | Where |
|---|---|
| Clone Repository | The Welcome screen, when no project is open |
| File → New → Project from Version Control | With a project already open |
| Git → Clone… | When the current project is already under Git |
All three open the same dialog. If you have added an account (lesson 16.2), it lists the repositories you can access; otherwise paste the URL from the platform's Code or Clone button (lesson 7.4).
The dialog also offers Shallow clone with a history truncated to a number of commits, which is worth knowing for a huge repository and worth avoiding otherwise: a shallow clone cannot see older history, which breaks git log on old files and git blame entirely.
After the clone
IntelliJ opens the project and starts indexing it, shown in the status bar. Indexing is what powers search, navigation and inspections; it has nothing to do with Git and it finishes on its own. On a large project it can take a few minutes the first time.
Once indexed, the Git tool window, the Commit tool window and the VCS widget in the header are all populated.
Opening a clone you already have
File → Open on the folder. IntelliJ detects .git and enables the Git integration by itself.
The same caution as any IDE: open the folder containing .git, not a subfolder. Opening trailguide/docs gives you an editor with no version control, which looks like a broken installation and is not.
Publishing a local project
For a project that exists only on your machine:
- Put it under Git: Enable Version Control Integration (lesson 16.1).
- Write a
.gitignorebefore the first commit (lesson 4.3). - Add and commit the files.
- With a GitHub account added, Git → GitHub → Share Project on GitHub creates the repository and pushes in one step.
- For GitLab, create the project on the web first, then Git → Push, and use the Define remote link in the push dialog to enter the URL (lesson 7.3).
Step 2 matters more than it looks. A folder that has been worked in for a year usually contains credentials, build output and personal notes, and the first commit is the moment to decide what belongs.
How to do it
$ git clone https://gitlab.com/northwind-trails/trailguide.gitThen File → Open on the resulting folder. Cloning in the terminal and opening in the IDE is a perfectly good workflow, and it avoids the wrong-folder mistake.
Git: Clone in the Command Palette, or the Clone Repository button in an empty Source Control view. See lesson 15.4.
- Clone Repository on the Welcome screen
- File → New → Project from Version Control
- Git → GitHub → Share Project on GitHub
- Find Action (⇧⌘A) → "Clone"
The Code button gives the HTTPS and SSH addresses, and Open in your IDE offers a direct handoff to JetBrains IDEs through Toolbox.
The Code button, and Open with JetBrains Toolbox where Toolbox is installed.
Common mistakes
- Opening a subfolder of the project, so no repository is detected.
- Using a shallow clone without needing to, which breaks history and blame.
- Assuming indexing is Git. It is the IDE reading the project.
- Sharing a project without a
.gitignore. - Creating the GitLab project after pushing, rather than before. The push has nowhere to go.
Try it yourself
Goal: clone, open the wrong folder on purpose, and publish something local.
- Clone your practice project from the Welcome screen or File → New → Project from Version Control.
- Wait for indexing, then confirm the VCS widget shows your branch.
- Open the project's
docssubfolder as a separate project and note that version control is absent. - Reopen the top folder.
- Create a small folder elsewhere, use Enable Version Control Integration, add a
.gitignore, commit, and publish it.
Expected result: a working clone, one deliberate wrong-folder experiment, and a new repository published from the IDE.
Show solution
Step 3 is worth doing once because the symptom is so unhelpful: no Git menu, no VCS widget, and no explanation. Recognising it as "wrong folder" rather than "broken IDE" saves the ten minutes everyone otherwise loses to it exactly once.