Getting Started with Git: Initializing and Cloning Repositories

Initializing and cloning repositories are the two basic ways you start working with Git. You either turn an existing folder into a Git repository, or you copy an existing repository so you can work with its files and history.

These commands look simple, but the choices you make at the start affect remotes, branches, ignored files, and team workflows. A clean setup prevents confusion later.

What a Git Repository Contains

A Git repository is a project folder with a hidden .git directory inside it. That .git directory stores commit history, branch references, remote information, configuration, and Git's internal object database.

You normally do not edit .git files by hand. You use Git commands, and Git updates that internal data for you.

To check whether a folder is already a repository, run:

git status

If Git says the folder is not a repository, you can initialize one. If it shows a branch, changed files, or a clean working tree, Git is already tracking that folder.

It helps to understand three common areas:

• Working tree: the files you can see and edit.
• Staging area: the changes selected for the next commit.
• Repository history: the commits Git has already recorded.

When you initialize or clone a repository, Git sets up those pieces so you can start making commits.

Initializing a New Repository

Use git init when you have a local project folder that is not tracked by Git yet.

Create a folder and initialize it:

mkdir my-app
cd my-app
git init

Git creates the hidden .git directory. You can now add files and make your first commit:

echo "# My App" > README.md
git add README.md
git commit -m "Add README"

If your default branch should be named main, you can set that globally before creating new repositories:

git config --global init.defaultBranch main

Or rename the current branch after initialization:

git branch -M main

For a real project, create a .gitignore before your first broad commit. That prevents dependency folders, build output, logs, and local secrets from entering history:

node_modules/
dist/
.env
*.log

Once a file is committed, adding it to .gitignore later does not remove it from history. That is why early ignore rules matter.

If you plan to publish the repository to a hosting service, create the empty remote repository there first, then connect it:

git remote add origin [email protected]:example/my-app.git
git push -u origin main

The -u option sets upstream tracking. After that, plain git push and git pull know which remote branch to use.

Cloning an Existing Repository

Use git clone when a repository already exists somewhere else. Cloning copies the project files, history, and remote configuration.

The basic command is:

git clone [email protected]:example/my-app.git

Git creates a folder named after the repository. To choose a different local folder name, add it at the end:

git clone [email protected]:example/my-app.git worktree-app

After cloning, move into the folder and inspect it:

cd worktree-app
git status
git remote -v
git branch

By default, the remote is usually named origin. That name is conventional, not magic. It points to the URL Git will use for fetches and pushes.

You may see either HTTPS or SSH clone URLs. HTTPS is easy to start with, especially for public repositories. SSH is common for daily development because it uses keys and avoids repeated password prompts when configured correctly.

For a large repository, you might use a shallow clone:

git clone --depth 1 https://example.com/repo.git

That downloads only recent history. It is useful for CI jobs or quick inspection, but it can limit commands that need older commits, tags, or full history. For normal development, a full clone is usually better.

If the repository uses submodules, clone with:

git clone --recurse-submodules [email protected]:example/platform.git

Or initialize them after cloning:

git submodule update --init --recursive

Submodules add another layer of repository management, so read the project's setup documentation before making changes.

Common First Checks After Setup

After initializing or cloning, run a few checks before you start coding. They help catch misconfiguration early.

Check your identity:

git config user.name
git config user.email

If this is a work repository, make sure the email matches your company account. You can set it locally:

git config --local user.email "[email protected]"

Check remotes:

git remote -v

Make sure fetch and push URLs point to the expected repository. Accidentally pushing to a fork or personal mirror can waste time.

Check the current branch:

git branch --show-current

If you cloned a repository, read the README or contribution guide before creating a branch. Many teams expect branch names like feature/ticket-123-short-description or fix/login-timeout.

Before your first commit, check ignored files:

git status --ignored

This is a quick way to confirm build artifacts and local secret files are not about to be committed.

When to Ask for Help

Ask a teammate or repository maintainer for help if you are unsure which remote URL to use, whether you should clone a fork or the main repository, or how submodules are supposed to be handled.

You should also pause if you initialized Git in the wrong directory. For example, running git init in your home folder can make Git see thousands of unrelated files. Do not start deleting things randomly. Confirm where .git was created and remove only the mistaken repository metadata if you are sure it contains no needed history.

Starting with Git is mostly about clean habits. Use git init for new local projects, git clone for existing repositories, and verify your branch, remote, identity, and ignored files before you begin serious work.