Git: creating a repository and making your first commit

This lesson covers the first important Git workflow: turning a normal folder into a repository and recording the first commit.

git init creates a repository

To turn the current directory into a Git repository:

git init

This creates a hidden .git directory that stores the repository’s metadata and history.

What .git is

After git init, the project contains a hidden directory named .git.

That directory is where Git stores repository data such as:

• objects
• references
• configuration
• commit history

In normal project work, you do not edit .git manually.

Git manages it for you.

Configure your identity before making commits

Git commits record author information.

If Git does not know your name and email yet, set them first:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

This is part of the basic first-time setup for Git on your machine.

Set your default branch name

When you run git init, Git creates a branch. By default, modern Git names this branch main.

If your Git version is older and uses master as the default, you can change it globally:

git config --global init.defaultBranch main

Or set it for a single repository:

git init -b main

main has become the standard default name across the industry, replacing the older master convention.

The three states that matter first

Before the first commit, keep these three states separate:

• the working tree is what is currently in your files on disk
• the staging area is what you have marked for the next commit
• the commit history is what has already been recorded

That distinction is the key to understanding git add and git commit.

git add stages changes for the next commit

If you want Git to include a file in the next commit, stage it with git add.

For example:

git add README.md

To stage multiple specific files:

git add README.md package.json

To stage all tracked and untracked changes in the current directory:

git add .

The Git docs describe the staging area as the index. In beginner-friendly terms, it is the list of changes Git should package into the next commit.

git commit -m records the staged snapshot

After staging the right files, create a commit:

git commit -m "Add initial project files"

Here, -m is an argument that tells Git to use the following text as the commit message.

In this example, the commit message is:

Add initial project files

Without -m, Git usually opens your configured editor so you can write the commit message there instead.

This records the current staged snapshot in the repository history.

The commit does not automatically include every file in the project. It includes the changes that were staged.

Quick commit for already-tracked files

Once files have been committed at least once, you can use -a to automatically stage and commit all tracked changes in one step:

git commit -am "Update README with project goals"

This skips the git add step for files Git is already tracking. New, untracked files still need git add first.

Use -am when you are confident all modified files belong in the same commit. For larger or more selective commits, use git add explicitly.

Commit messages matter

The commit message should describe what the commit changed.

Good commit messages make history easier to scan later because they answer a practical question:

What did this commit do?

Early on, a simple imperative style works well:

• Add project README
• Fix broken login validation
• Update button styles

Conventional Commits are one optional structure

Some teams use a framework called Conventional Commits to make commit messages more structured.

Examples:

feat: add login form
fix: correct button disabled state
docs: update setup instructions

The part before the colon is a type label, and the rest describes the change.

In that structure:

• feat usually means a new feature
• fix usually means a bug fix
• docs usually means a documentation change

That makes commit history easier to scan because the type gives context before you even read the rest of the message.

You do not need Conventional Commits to use Git well, but they are worth recognizing because many teams use them to keep commit history more consistent, generate changelogs, or support release tooling.

For a beginner, the practical rule is simple:

• first learn to write clear commit messages
• then use Conventional Commits if the project or team expects them

If you are working alone on a small project, either of these can be reasonable:

Add login form
feat: add login form

The more important part is that the message clearly describes the change.

A clean first-commit flow

1. Create or open the project directory.
2. Run git init.
3. If needed, configure your Git name and email.
4. Create or edit the files you want in the project.
5. Stage the intended files with git add.
6. Create the commit with git commit -m ”…”.

What changed in the project

After this flow:

• .git/ exists and stores the repository metadata
• the staged files are now part of the repository history
• the branch has its first commit