Chapter 2: Setting Up Git and Your First Repository

Introduction

Welcome back, future Git master! In Chapter 1, we took a high-level flight over the world of Version Control Systems and understood what Git is and why it’s indispensable for modern development. Now, it’s time to roll up our sleeves and get practical.

In this chapter, we’re going to transform our theoretical understanding into hands-on experience. You’ll learn how to install Git on your machine, configure it to identify you as the author of your changes, and then take the monumental first step of initializing your very own local Git repository. This isn’t just about following instructions; it’s about building the fundamental environment where all your future version control magic will happen. Every line of code you write, every project you start, will begin with these foundational steps.

By the end of this chapter, you’ll have a fully functional Git setup and your first project under version control, ready for the exciting journey ahead. Let’s get started!

Core Concepts: Getting Ready for Action

Before we dive into commands, let’s briefly reinforce some ideas and introduce new ones for our setup.

Git: The Engine Under the Hood

Remember Git is a Distributed Version Control System (DVCS). This means the entire history of your project lives on your local machine. You don’t need to be connected to the internet to commit changes, browse history, or even branch and merge. Installing Git puts this powerful engine directly on your computer.

The `.git` Directory: Your Project’s Brain

When you initialize a Git repository, Git creates a hidden directory named .git within your project folder. This isn’t just any folder; it’s the core of your repository! It contains all the metadata, object databases, commit history, branch pointers, and configurations that make Git work. Think of it as your project’s brain, silently tracking everything.

The Git Workflow: A Sneak Peek

Our goal in this chapter is to get a basic understanding of the core Git workflow:

Working Directory: This is where you write and edit your files.
Staging Area (Index): This is where you prepare changes that you want to include in your next commit. It’s like a holding area. You tell Git, “Hey, these specific changes are ready to be saved together!”
Local Repository: Once you’re happy with the staged changes, you “commit” them. This action takes a snapshot of your staged files and permanently stores it in your local repository’s history.

This three-stage process gives you incredible control over exactly what gets saved and when.

Step-by-Step Implementation: Installing and Initializing

Let’s get practical!

Step 1: Installing Git

First things first, we need to install Git on your operating system. As of December 2025, the latest stable release of Git is typically around version 2.43.0 or newer. While the exact version number might slightly vary depending on when you check, the installation process remains consistent. Always check the official Git website for the absolute latest stable release.

For Windows:

Download: Go to the official Git for Windows download page.
Run Installer: Download the standalone installer (64-bit Git for Windows Setup is usually what you want).
Follow Prompts: Run the installer. For most users, the default options are perfectly fine. You might want to select a different default text editor if you prefer something other than Vim (like Visual Studio Code or Notepad++).
Finish: Complete the installation.

For macOS:

macOS users often have Git pre-installed, or it can be installed via Xcode Command Line Tools or Homebrew.

Check for Pre-installation: Open your Terminal (Applications > Utilities > Terminal) and type:
```
git --version
```
If you see a version number (e.g., git version 2.43.0 (Apple Git-136)) you likely have it. If prompted to install command line tools, agree.
Install via Homebrew (Recommended if not present): If Git isn’t installed or you want a more up-to-date version, Homebrew is the easiest way.
- If you don’t have Homebrew, install it by following instructions on brew.sh.
- Then, in your Terminal, run:
```
brew install git
```

For Linux (Debian/Ubuntu):

Open your terminal.
Update your package lists:
```
sudo apt update
```
Install Git:
```
sudo apt install git
```
For other Linux distributions, consult your distribution’s package manager documentation (e.g., dnf install git for Fedora/RHEL, pacman -S git for Arch Linux).

Verify Installation:

After installation, open a new terminal or command prompt and type:

git --version

You should see output similar to git version 2.43.0 (or whatever the latest version is). If you see this, congratulations! Git is successfully installed.

Step 2: Configuring Git with Your Identity

Before you make any commits, Git needs to know who you are. This information is attached to every commit you make, providing crucial attribution. We’ll set a global configuration, meaning it applies to all your Git repositories on this machine.

In your terminal, run these two commands, replacing the placeholders with your actual name and email:

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

What’s happening here?

git config: This is the command to get and set configuration variables.
--global: This flag tells Git to apply this configuration to all repositories on your system, stored in a global configuration file (e.g., ~/.gitconfig on Linux/macOS or C:\Users\<YourUser>\.gitconfig on Windows). If you wanted to set a different name/email for a specific project, you’d omit --global and run it inside that project’s directory.
user.name and user.email: These are the specific configuration keys Git uses to identify the author of a commit.

Why is this important? This information is permanently recorded in the commit history. It helps you and your team understand who made what changes, which is vital for collaboration and accountability.

Modern Best Practice: Setting the Default Branch Name

Traditionally, the default branch in Git was often named master. However, modern best practices, driven by inclusivity, recommend using main as the default branch name. Let’s configure Git to automatically use main for all new repositories you initialize:

git config --global init.defaultBranch main

Now, whenever you create a new repository with git init, its initial branch will be main. This is a small but important step towards aligning with current industry standards.

Step 3: Initializing Your First Repository

Now for the exciting part! Let’s create a new project and turn it into a Git repository.

Create a New Project Directory: Open your terminal and navigate to a location where you want to create your project. Then, create a new directory for your project:
```
mkdir my-first-git-project
```
Then, move into that directory:
```
cd my-first-git-project
```
Initialize the Git Repository: Inside your new project directory, run the magical command:
```
git init
```
You should see output similar to:
```
Initialized empty Git repository in /path/to/my-first-git-project/.git/
```
What just happened?
- git init: This command creates a new, empty Git repository.
- It creates the hidden .git/ directory we talked about earlier. This directory is what makes my-first-git-project a Git repository. Without it, it’s just a regular folder.

Step 4: Adding Your First File and Making Your First Commit

Our repository is empty right now. Let’s add a file and save its initial state.

Create a Sample File: Using your preferred text editor (like VS Code, Sublime Text, Notepad, or even touch and nano in the terminal), create a file named README.md inside your my-first-git-project directory.
For example, in the terminal:
```
echo "# My Awesome Project" > README.md
echo "This is my very first project under Git version control!" >> README.md
```
Check the Status: Let’s see what Git thinks about our new file:
```
git status
```
You’ll see output like:
```
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        README.md

nothing added to commit but untracked files present (use "git add" to track)
```
What does this mean?
- On branch main: Git tells us we’re on the main branch (thanks to our init.defaultBranch setting!).
- No commits yet: Our repository is brand new, no history recorded.
- Untracked files: Git sees README.md but isn’t tracking it yet. It’s in our Working Directory, but not in the Staging Area. Git is suggesting git add.
Stage the File: Let’s tell Git we want to include README.md in our next snapshot (commit).
```
git add README.md
```
Check Status Again: Now, run git status one more time:
```
git status
```
Output:
```
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
        new file:   README.md
```
See the difference?
- Changes to be committed: README.md has moved from Untracked to the Staging Area. Git is now aware of it and ready to include it in the next commit.
Commit the Changes: Finally, let’s create our first permanent snapshot!
```
git commit -m "Initial project setup with README"
```
You’ll see output like:
```
[main (root-commit) 7a1b2c3] Initial project setup with README
 1 file changed, 2 insertions(+)
 create mode 100644 README.md
```
You just made your first commit!
- git commit: This command takes everything currently in the Staging Area and saves it as a new, permanent snapshot in your local repository.
- -m "Your message": The -m flag is essential for providing a commit message. This message is a brief, descriptive summary of the changes included in the commit. Good commit messages are crucial for understanding project history.
- [main (root-commit) 7a1b2c3]: This shows you the branch (main), that it’s the very first commit (root-commit), and a short version of the unique identifier (hash) for this commit (7a1b2c3).

Step 5: Viewing Your Commit History

To see a record of your commits, use git log:

git log

Output:

commit 7a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b (HEAD -> main)
Author: Your Name <your.email@example.com>
Date:   Mon Dec 23 10:00:00 2025 +0000

    Initial project setup with README

Here, you can see your commit, the author (your configured name and email!), the date, and your commit message. HEAD -> main indicates that your HEAD (which points to your current location) is currently pointing to the main branch.

Mini-Challenge: Expanding Your First Repository

Now it’s your turn to practice the workflow!

Challenge:

Create a new file called index.html in your my-first-git-project directory. Put some simple HTML content inside it (e.g., <h1>Hello Git!</h1>).
Check the status of your repository.
Add index.html to the staging area.
Commit the change with a clear and descriptive commit message like “Add basic index.html file”.
View your commit history to confirm both commits are there.

Hint: Remember the sequence: create/modify -> git status -> git add -> git status -> git commit -> git log.

What to Observe/Learn:

How git status helps you understand the state of your files.
The distinction between untracked, staged, and committed changes.
How each git commit adds a new snapshot to your project’s historical timeline.

Common Pitfalls & Troubleshooting

Even simple steps can sometimes lead to small hiccups. Here are a few common ones you might encounter:

'git' is not recognized as an internal or external command (Windows) or git: command not found (Linux/macOS):
- Problem: Git is not correctly installed or its executable path isn’t in your system’s PATH environment variable.
- Solution: Re-run the Git installer (especially on Windows, ensuring “Git from the command line and also from 3rd-party software” is selected). On Linux/macOS, ensure installation finished without errors. Sometimes, closing and reopening your terminal/command prompt is all it takes for the PATH to update.
fatal: not a git repository (or any of the parent directories): .git:
- Problem: You’re trying to run a Git command (like git status or git add) in a directory that hasn’t been initialized as a Git repository.
- Solution: Navigate to the root directory of your project where you ran git init, or run git init if you haven’t done so already.
Forgetting git add before git commit:
- Problem: You’ve created or modified files, but when you run git commit, Git says nothing to commit, working tree clean.
- Solution: You forgot to move your changes into the staging area. Use git add <file(s)> or git add . (to stage all changes in the current directory and subdirectories) before git commit. Always use git status to see what Git is aware of!
Getting stuck in a text editor after git commit (without -m):
- Problem: If you just type git commit without the -m flag, Git will open your default text editor (often Vim on Linux/macOS, or Notepad on Windows) to ask you for a commit message. If you’re not familiar with that editor, it can be confusing!
- Solution:
  - In Vim: Press i to enter insert mode, type your commit message, then press Esc, type :wq (write and quit), and press Enter.
  - In other editors: Type your message, save the file, and close the editor.
  - Prevention: Always use git commit -m "Your descriptive message" for single-line messages to avoid this.

Summary

Phew! You’ve just completed some crucial first steps in your Git journey. Let’s recap what you’ve achieved:

Installed Git: You now have the powerful Git engine running on your local machine.
Configured Your Identity: Git knows who you are, attributing your contributions correctly. We also set main as the default branch for new repositories.
Initialized Your First Repository: You’ve created a .git directory, turning a regular folder into a full-fledged Git repository.
Mastered the First Git Workflow: You learned to:
- Create or modify files in your Working Directory.
- Use git status to see the state of your files.
- Move changes to the Staging Area with git add.
- Permanently save a snapshot to your Local Repository with git commit, along with a descriptive message.
Explored Commit History: You used git log to view the timeline of your project’s changes.

You’ve laid the groundwork for all future version control efforts! In the next chapter, we’ll dive deeper into modifying files, understanding differences between versions, and undoing changes, making your local repository even more dynamic.

References

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.