init vs clone; the .git folder
Beginner Git CLI VS Code UI IntelliJ UI GitLab UI GitHub UI
Why this matters
Every repository on your computer got there in one of two ways. Choosing the right one decides whether Git already knows where the remote is, and understanding the hidden folder both create prevents the one mistake that actually destroys history.
Two ways in
git init |
git clone <url> |
|
|---|---|---|
| Use when | You have a folder of files and no repository yet | The repository already exists on GitLab or GitHub |
| Creates | An empty .git in the current folder; no commits |
A new folder with the full history and the files of the default branch |
| Remote | None; you add one later (git remote add origin <url>) |
origin set to the URL; main tracks origin/main |
| Typical for | A brand-new project, a personal notes folder | Joining any existing project (by far the most common) |
You did git init on the playground; you will git clone almost everything else in your working life.
Start a new repository in an existing folder:
$ cd ~/git-practice/trailguide
$ git initInitialized empty Git repository in /Users/you/git-practice/trailguide/.git/Nothing is committed yet; the files are untracked until you git add and git commit them.
Get an existing repository (the URL comes from the project's page; the Code or Clone button shows it):
$ cd ~/git-practice
$ git clone https://gitlab.com/northwind-trails/trailguide.gitCloning into 'trailguide'...
done.Real clones also print progress lines (remote: Enumerating objects…, Receiving objects: 100%). A folder named after the repository appears, with the files and a .git inside, and the remote is already configured:
$ cd trailguide
$ git remote -vorigin https://gitlab.com/northwind-trails/trailguide.git (fetch)
origin https://gitlab.com/northwind-trails/trailguide.git (push)To clone into a folder with a different name, add it: git clone <url> my-folder.
New repository: open the folder (File → Open Folder…), open Source Control, click Initialize Repository.
Existing repository: with no folder open, the Source Control view shows Clone Repository; or Command Palette → Git: Clone. Paste the URL, choose a parent folder (for example git-practice), and click Open when VS Code offers to open the clone. If you signed in to GitHub in VS Code, Clone from GitHub lists your repositories.
New repository: open the folder, then VCS → Create Git Repository… (older versions: Enable Version Control Integration).
Existing repository: on the welcome screen Get from VCS (or File → New → Project from Version Control…). Paste the URL, choose the directory, click Clone. With a GitLab or GitHub account added under Settings → Version Control, the dialog lists your projects.
On the project page, the Code button (top right of the file list) shows the URLs: Clone with SSH and Clone with HTTPS. Copy the HTTPS one for now (SSH comes in Section 8) and use it with git clone. The same menu offers Open in your IDE (VS Code, IntelliJ) which triggers the clone dialog in the IDE.
To create a brand-new project from the web instead of git init: New project → Create blank project; then follow the "Push an existing folder" instructions GitLab shows.
The Code button above the file list shows HTTPS, SSH and GitHub CLI tabs with the URL, plus Open with GitHub Desktop and Download ZIP. Download ZIP gives the files without history or a .git folder — useful for reading, useless for contributing. Clone instead.
Inside .git
Both commands create the hidden .git folder. It is the repository:
$ ls .gitCOMMIT_EDITMSG
HEAD
config
description
hooks
index
info
logs
objects
refs| Item | What it holds |
|---|---|
objects/ |
Every commit and every version of every file, compressed |
refs/ |
Branches (heads/), tags (tags/), remote-tracking branches (remotes/) |
HEAD |
Which branch you are on |
index |
The staging area |
config |
The repository's local configuration, including origin's URL |
logs/ |
The reflog: a diary of where HEAD and branches pointed (lesson 12.1) |
hooks/ |
Optional scripts Git runs at certain moments (lesson 18.4) |
The working tree is everything outside .git. Deleting the working tree while keeping .git loses nothing: git restore . rebuilds the files from the last commit.
Common mistakes
- Cloning inside another repository. A repository inside a repository confuses both. Clone into a plain folder such as
git-practice. - Downloading the ZIP and wondering why
git statusfails. The ZIP has no.git. Clone. git initin your home folder by accident. Every file you own becomes untracked in one giant repository. Fix: delete the.gitfolder thatgit initjust created in your home folder (this one time, that is the right move, and it is the only.gityou should ever delete), thencdinto the intended folder.- Cloning with a URL that is not yours to push to. You can clone any public repository, but pushing needs permission; Section 7 covers forks for that case.
Try it yourself
Goal: see the difference between a clone and a ZIP download, without leaving your computer.
- Clone your own playground into a second folder:
cd ~/git-practice && git clone trailguide trailguide-copy(Git can clone from a local path). - In
trailguide-copy, rungit remote -vandgit log --oneline. - Delete the copy when done:
rm -rf ~/git-practice/trailguide-copy.
Expected result: the copy has the full history and an origin pointing at your original folder; a ZIP would have had neither.
Show solution
$ git clone trailguide trailguide-copyCloning into 'trailguide-copy'...
done.git remote -v shows origin as the path to your original trailguide; git log --oneline shows the same commits. That is what a clone is: a complete, independent copy that remembers where it came from.