Initializing Your Repository – git init

The very first step for any project that you want to put under version control is to initialize a Git repository. You only need to do this once per project.

Navigate to your project's root folder using your terminal or command prompt, and then run the following command:

git init

That's it! This single command creates a new, hidden sub-directory named .git. This .git folder is your local repository – it's where Git stores all the metadata and the entire history of your project. All the magic of Git happens inside this folder.

Once you see a message like "Initialized empty Git repository in .../.git/", Git is now officially tracking that folder and its contents.

The Three States – Git's Mental Model

Before we use more commands, it's crucial to understand Git's mental model for your files. Every file in your working directory can be in one of two states: tracked or untracked. A tracked file is one that Git knows about. A tracked file can then exist in one of three main states:

1. Modified: You have changed the file, but you haven't yet saved this change to your repository's history.
2. Staged: You have marked a modified file in its current version to be included in your next commit (your next snapshot).
3. Committed: The data is safely stored as a snapshot in your local repository (the .git directory).

This introduces the concept of the Staging Area (or "index"). The staging area is an intermediate step between modifying a file and committing it. It allows you to carefully select which changes you want to include in your next commit.

The basic workflow looks like this:

Working Directory → (You modify files) → Modified Files → (You run git add) → Staging Area → (You run git commit) → Repository

Checking Your Status – git status

The git status command is one of the most helpful tools for understanding what's going on in your repository. It gives you a snapshot of:

• Which files have been modified since your last commit.
• Which files are currently staged and ready to be committed.
• Which files in your working directory are new and not yet being tracked by Git.

It also provides clear guidance on next steps, such as staging changes or discarding modifications.

If you're using a visual Git client like Sourcetree, GitHub Desktop, or GitKraken, this information is often shown in real-time within the interface – making it even easier to understand your working directory and staging area without typing commands.

Whether you prefer the command line or a GUI, being aware of your current Git status helps ensure your commits are intentional and well-structured.

Staging Changes – git add

Once you've modified some files and you're happy with the changes, you need to move those changes to the staging area. This is done with the git add command. This command tells Git, "I want to include the current version of this file in my next commit."

Staging a Specific File

To stage a single file, you provide its name:

git add MyTestFile.cs

Staging All Changes

A very common shortcut is to stage all new and modified files in your current directory and all subdirectories. You can do this with a period (.):

# The '.' represents the current directory
git add .

After running git add, if you run git status again, you'll see that your files have moved from the "Changes not staged for commit" section to the "Changes to be committed" section.

Saving Your Work – git commit

Once you have staged all the changes you want to include in your next historical snapshot, you save them to your repository using the git commit command.

A commit takes everything in the staging area, creates a permanent snapshot of that state in your Git history, and gives it a unique hash ID. Every commit must have a message associated with it to describe the changes.

The most common way to commit is with the -m flag, which allows you to provide a commit message directly on the command line.

git commit -m "Feat: Add initial calculator class and its unit tests"

Viewing Your History – git log

Now that you've made some commits, how do you see the history you've created? The git log command is your window into the past.

Running git log by itself will show you a detailed list of all the commits in your repository's history, starting with the most recent. Each entry will typically show:

• The full commit hash (the unique SHA-1 ID).
• The author's name and email.
• The date the commit was made.
• The full commit message.

The output can be quite verbose. A very useful flag for a more compact view is --oneline:

git log --oneline

Example Output:

a1b2c3d (HEAD -> main) Fix: Add error handling for division by zero
e4f5g6h Feat: Implement subtraction method
c7d8e9f Feat: Add initial calculator class and its unit tests

This gives you a quick, one-line summary of each commit, showing the short version of the hash and the commit message title.