Docs Library
Setup and Clone
Handle the first low-risk setup tasks in Git: configure identity, clone a repository, and inspect what actually appears locally afterward.
- Beginners learning Git as a system
- Developers who want a reliable first collaboration loop
- Basic terminal comfort
- A rough distinction between local and remote repositories
- Skipping ahead to high-risk commands
- Running sample commands directly in the wrong repository
What this step should achieve
Before you create commits, you want three things to feel clear:
- who Git thinks you are
- how the repository arrives on your machine
- what to inspect right after clone
Beginners often know the syntax of git clone but not what clone actually created locally.
By the end of this page, you should be able to answer four basic questions without guessing:
- who Git will record as the author on this machine
- where this repository came from
- whether the current branch is clean
- what relationship exists between the current branch and its upstream
Step 1: configure identity
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
This is not just profile setup. It gives later commits an identifiable author.
You can verify immediately:
git config --global --list
git config --global user.name
git config --global user.email
If work repositories need a different email, configure it inside the repository instead of globally:
git config user.email "work@example.com"
Step 2: clone the repository
git clone <repository-url>
cd <repository-name>
After clone, local state now includes:
- a working directory
- full repository history
- a default remote called
origin - remote-tracking refs
What you should notice inside the cloned directory
After entering the directory, the obvious part is the project files. The more important part is that .git/ now exists.
Check it with:
pwd
ls -a
git rev-parse --show-toplevel
The useful mental model is:
- project files are your working tree
.git/stores repository metadata and objects- most later Git commands operate around those two areas
Step 3: run one inspection pass immediately after clone
Run:
git status
git branch -vv
git remote -v
These commands tell you:
- which branch you are on
- whether the working tree is clean
- whether the current branch tracks an upstream branch
- which URL
originpoints to
If this is your first time in a team repository, do not skip this pass. It tells you where you are before you start editing.
A complete first-machine example
git config --global user.name "Maqi"
git config --global user.email "maqi@example.com"
git clone git@github.com:example/team-repo.git
cd team-repo
git status
git branch -vv
git remote -v
If all of that works, you already have the minimum local setup for real work.
Typical exercises
Exercise 1: clone a small practice repository
git clone <repository-url>
cd <repository-name>
git status
Exercise 2: inspect branch and remote relationship
git branch -vv
git remote -v
Exercise 3: confirm that .git/ and the working tree are different layers
ls -a
git rev-parse --show-toplevel
Exercise 4: clone again into a fresh directory
This helps reinforce that clone creates a new local repository rather than “repairing” an existing folder.
A safer beginner checklist
Every time you first open a repository, confirm at least these five points:
- you are in the correct directory
git statusis clean- the branch is the branch you think it is
- the
originURL is correct - identity settings match the team expectation
Common mistakes
Mistake 1: thinking clone only copies files
It also copies repository history and establishes remote relationship.
Mistake 2: treating origin like a magic keyword
It is only the default remote name.
Mistake 3: editing files immediately without checking state
A safer habit is to look at git status and git branch -vv first.
Mistake 4: assuming clone also proves you can push
Clone only proves you can read the repository. Push permissions are a separate remote-side question.
Special cases
- On a new machine, confirm SSH keys or auth flow first
- Large repositories may clone slowly because the object set is large
- In fork-based workflows, the repo you clone may be your fork rather than the upstream source
- If the repository uses submodules, clone may be only the first step
Next step
Continue with Staging and Commit.