About This Book

If you search the web, you’ll find no shortage of Git tutorials. So why pick up a book?

Chances are, you’ve already tried learning Git from online resources and hit a wall. Maybe you found it confusing. Maybe you didn’t see why you needed it. Maybe you got lost in a sea of commands and gave up.

You’re not alone. The author failed to learn Git twice before it finally clicked. The first time, it seemed overly complicated with no clear payoff. The second time, even with real project deadlines as motivation, the fragmented online tutorials still weren’t enough.

That experience is exactly why this book exists. Having stumbled through those same frustrations, we know precisely where learners get stuck and what finally makes things click. And here’s the encouraging part: once it clicks, you’ll wonder why it ever seemed hard.

There are two main reasons people struggle with Git:

First, the intimidation of the command line. A black screen with a blinking cursor gives you no visual feedback. You can’t see what’s happening, so you try to memorize commands, and when you can’t remember them all, you give up.

Second, fragmented online resources. Most tutorials assume you already know enough to search for the right thing. But if you don’t know what commands exist, you can’t even form the right question. You end up discovering features months later, thinking, “Wait, Git can do that?”

Git is a fundamental skill for any developer. Engineers who use Git fluently are immediately recognized as professionals. In the AI era, this hasn’t changed. If anything, the importance of Git has only grown as AI tools become a bigger part of the development workflow.

This book is designed to overcome both of those stumbling blocks. We use abundant diagrams to visualize what’s happening behind the command line. And instead of scattered tips, we provide a systematic path from Git’s big picture down to individual commands. Rather than memorizing commands, you’ll understand why things work the way they do, and that understanding will make Git feel natural.

Series Structure

“Why Git?” is a two-volume series that takes you from fundamentals to professional practice.

Vol. I: Foundations (this book)

Learn Git operations in your local environment from the ground up. Even if you’ve never used Git or the command line, the step-by-step explanations will build your skills steadily.

By the end of this book, you’ll be able to use Git confidently in your own projects.

Vol. II: Mastery

Learn GitHub integration, conflict resolution, AI tool workflows, team collaboration, and CI/CD pipelines.

After Vol. II, you’ll have the Git skills to contribute effectively to any team.

How to Read This Book

We recommend reading from Chapter 1 onward in order. Each chapter builds on the previous one, so jumping ahead may leave gaps in understanding.

That said, if you already know Git basics, feel free to skip to the chapters you need. Each chapter opens with a “What you’ll learn” summary to help you decide.

Each section heading includes a “Back to Table of Contents” button. When you want to review a topic or look up a specific command, you can quickly jump back to the table of contents and navigate to the right section.

Chapter 1-1 Development in the AI Era TOC

The world of programming has changed dramatically. Beyond established tools like GitHub Copilot, Claude Code, and ChatGPT, new AI development tools keep emerging: Cursor, Devin, Windsurf, Cline, and Google’s Antigravity, to name a few. If you’ve picked up this book, you’re likely already using some of these tools or planning to start.

How AI Has Changed Development

AI tools are fundamentally reshaping how we build software.

Traditionally, programmers spent most of their time writing code. Now, the role is shifting toward directing AI to build what you need. “Prompt engineering” has become a skill in its own right, reflecting how much the job has changed.

This shift has dramatically lowered the barrier to programming. With AI assistance, even beginners can build functional applications. But it has also introduced new challenges.

The Wall That Non-Engineers Hit

AI has opened the door for people who never considered themselves programmers. Marketers, designers, founders – regardless of job title, “building with AI” is now a real option.

But many non-engineers who start building with AI hit a wall at a certain point.

They can generate code. They can get things to work. But as the project grows, things start going wrong. Files become disorganized. Something that worked yesterday breaks today. Trying to collaborate with others creates chaos.

The root cause is simple: they don’t know the unwritten rules that professional developers take for granted.

Best practices refined over decades of software development, industry-standard tools, team collaboration protocols – these are absorbed naturally through engineering experience, but people who enter development through AI never encounter them.

The most important of these is Git.

For professional developers, Git is like oxygen. It’s so fundamental that it’s assumed. But if Git is a new word to you, you’re in the right place. Git isn’t just a tool – it’s your entry ticket to professional development. Whether you know it or not will fundamentally change your development experience going forward.

This book teaches you Git’s foundations and, just as importantly, the why behind everything. When you’re ready to work as a professional developer, you’ll already have industry-standard practices under your belt.

What Is Git?

So what exactly is Git?

In one sentence: Git is a tool that records and manages the history of changes to your files.

Normally, when you save a file, you overwrite the previous version. But what if you want to go back to yesterday’s version? Once you’ve overwritten it, it’s gone.

With Git, you can take a “snapshot” of your files at any point in time. You can always return to a previous state, and every snapshot records who changed what, when, and why.

Think of it like save points in a video game. Save before the boss fight, and if you lose, you can try again as many times as you need. Git is essentially save points for your code.

Why Learn Git Now?

You might be thinking, “Can’t I manage file history with Dropbox or Google Drive?”

Here’s the thing: AI output varies every time, and it rarely produces perfect code on the first try. Working with AI means constant iteration.

Imagine this scenario. You ask AI to “build a login feature.”

1. Attempt 1: AI generates code. You run it. Errors.
2. Attempt 2: You report the error and ask for a fix. It works!
3. Attempt 3: You ask for design improvements. The look changes, but it’s not quite right.
4. Attempt 4: More tweaks. Things start going sideways…

This cycle is the reality of AI-assisted development. And here’s where the problem surfaces: “It was working at attempt 2… how do I get back to that state?”

With Git, you can record each stage as a “commit.” Want to go back to attempt 2? One command and you’re there. You can instantly restore the working state before things went off track.

In other words, Git is a safety net for the trial-and-error process of working with AI. The more powerful AI gets, the more iterations you’ll go through. That’s exactly why Git’s value keeps growing.

Chapter 1-2 Three Risks of AI Code Generation TOC

AI is powerful, but without proper management, it comes with real pitfalls. Let’s look at three risks you should watch for when developing with AI.

Risk 1: Unintended Changes

Have you ever asked AI to “change the button color” and discovered it rewrote unrelated files?

AI doesn’t always limit itself to what you asked. It sometimes makes “helpful” changes to other parts of your code. These well-intentioned modifications can introduce unexpected bugs. In 2025, there were even reported incidents of AI accidentally deleting databases.

With Git: git diff lets you see exactly what changed at a glance. If something was modified that shouldn’t have been, you can easily revert just that part.

Risk 2: Quality and Security Issues

You deploy code that “works” – only to discover it has security vulnerabilities. This happens more often than you’d think.

Research suggests that roughly half of AI-generated code has issues flagged in security testing. AI is great at writing code that runs, but it often falls short on writing code that’s secure or maintainable over time.

With Git: You can trace the full change history during code review. Knowing when each change was introduced makes it much easier to pinpoint the source of problems.

Risk 3: No Way to Reproduce

“It was working a minute ago…” – a phrase you’ll hear constantly in AI-assisted development.

Even with the same prompt, AI generates slightly different code each time. If you want to get back to “that version that worked,” you can’t just re-run the same prompt. And trying to manually reconstruct a previous state from memory often makes things worse.

With Git: You save working states as commits. Even if you’ve gone down the wrong path, a single git checkout gets you back to a state you know works.

Chapter 1-3 The Limits of Developing Without Version Control TOC

The Nightmare of File-Name Versioning

app_final.js, app_final2.js, app_REALLY_final.js – sound familiar?

Without version control, this is what happens. Which file is the latest? What’s different between them? When were the changes made? Why were they made? Nobody remembers.

In a team, this chaos multiplies with every person involved. “Is Alex’s final version the right one, or is it the one Jamie fixed?” Time that should be spent writing code gets eaten up coordinating over chat and email.

The “How Far Back Do I Go?” Problem

This is especially painful in AI-assisted development: “It was just working…”

You ask AI for a fix. It breaks something else. You ask for another fix. Things get worse. Before you know it, you’re miles from a working state.

You want to get back to “the version that worked,” but with file names alone, you can’t identify which point that was. Trying to manually revert from memory often introduces new bugs.

These are exactly the problems that Git solves, as we’ll see in the next section.

Chapter 1-4 How AI and Git Work Together TOC

So far, we’ve seen the risks of AI code generation and the importance of version control. The question is: how do AI and Git fit together?

Offense and Defense

AI plays offense. It generates code at high speed, constantly proposing new ideas. “How about this approach?” “Should we add this feature too?” It’s always pushing forward.

Git plays defense. It reliably records everything AI produces and ensures you can always get back to a known-good state. It guards the checkpoint that says “everything was working up to here.”

This division of labor is what makes it safe to experiment with AI’s suggestions. If something goes wrong, just fall back to the safe point Git is protecting. You need both offense and defense to move forward with confidence.

A Practical Workflow

In practice, the cycle looks like this:

1. Save your current state with Git (commit)
2. Ask AI to add a feature or fix something
3. Test it – if it works, save with Git
4. If it doesn’t work, use Git to roll back

Repeat. AI pushes forward, and when it works, Git locks in the progress. When it doesn’t, Git takes you back to your last good state so you can try again.

Master this workflow and you’ll never get lost in AI-assisted development. This book teaches you how to put it into practice.

Chapter 1-5 What You’ll Learn and Where It Takes You TOC

This book (Vol. I: Foundations) is a practical guide to learning Git from scratch. Across six chapters, you’ll progress from “What is Git?” all the way to hands-on practice in a local environment.

What Each Chapter Covers

Chapter 1 (this chapter)

Understand why Git matters in the AI era. You’ll see how AI tools have transformed development, learn from real failure scenarios, grasp the importance of version control, and discover how Git and AI complement each other.

Chapter 2: Understanding Git’s Core Concepts

Learn Git-specific concepts like repositories, commits, and branches with clear, beginner-friendly explanations. Key sticking points like “local vs. remote repositories” and “commits add history, they don’t overwrite” get special attention.

Chapter 3: Setting Up Your Development Environment

Install and configure Git and VS Code. This chapter covers the practical setup you need, using free tools, with troubleshooting for common issues.

Chapter 4: Getting Comfortable with the Terminal

Learn the terminal (command line) basics you’ll need for Git. What the terminal is, GUI vs. CLI, essential commands (ls, cd, mkdir, pwd) – by the end, you’ll be comfortable typing commands with confidence.

Chapter 5: Git Commands: A Practical Guide

A systematic guide to the Git commands you’ll use in practice: init, status, add, commit, log, diff, branch, switch, merge, restore, and more. Each command includes its purpose, options, and real examples. You don’t need to memorize them now – you’ll learn by doing.

Chapter 6: Hands-On Git Practice in a Local Repository

Hands-on exercises that follow a real development workflow. From creating a repository to developing features, fixing bugs, and managing parallel branches – you’ll apply everything from Chapter 5 in realistic scenarios.

Skills You’ll Gain

By the end of this book, you’ll be able to:

• Fully understand Git’s core concepts (commits, branches, merges)
• Perform practical Git operations in a local repository
• Use branches for safe, organized development
• Integrate VS Code with Git
• Run a complete Git workflow for solo development

About Vol. II: Mastery

Once you’ve finished this book, Vol. II: Mastery is the natural next step. It covers GitHub integration, AI tool workflows, and team collaboration in practice.

• Connect with GitHub (push, pull, clone)
• Integrate AI tools with Git (GitHub Copilot, Claude Code)
• Collaborate on a team (Pull Requests, code review)
• Troubleshooting and advanced techniques

How to Approach Your Learning

Plan for roughly 2-3 weeks of study time. Of course, your pace may vary based on experience, but the book is structured so that every step moves you forward.

Development in the AI era is full of unprecedented possibilities. With AI tools at your side, even beginners can produce remarkably high-quality code. But to get the most out of that power, you need a solid foundation. That foundation is Git.

Through this book, you’ll develop a fearless approach to development. Try AI’s suggestions aggressively, roll back if they don’t work, lock in progress when they do, and move on to the next challenge. You’ll build the confidence to keep that cycle going.

Starting in the next chapter, we’ll dive into the specifics of Git. Chapter 2 will give you a solid understanding of Git’s core concepts.

Chapter 1-6 Command Notation in This Book TOC

This book includes many command examples. If the word “command” makes you tense up, take a breath. It’s going to be fine.

You don’t need to memorize anything right now. Every time a new command appears, we explain it step by step. The fastest way to learn isn’t memorization – it’s learning by doing.

Also, as we’ll discuss later, Git can be operated through buttons in editors like VS Code. However, since many operations can only be done via the command line, this book focuses on commands. It may feel unfamiliar at first, but with repetition, your fingers will start moving on their own.

Note that this book uses two types of commands: Git commands and Bash commands. Git commands start with git; Bash commands are everything else (general terminal operations). Since this book’s focus is Git, we won’t go deep into Bash, but Chapter 4 covers the essentials.

This section explains the notation conventions used throughout the book. Understanding these now will make the rest of your learning smooth.

What Is a Terminal (Console)?

A terminal (also called a console or command line) is a tool where you type text instructions for your computer. The default terminal varies by operating system.

This Book Uses Git Bash as the Standard

Important note for Windows users: This book assumes you’re using “Git Bash” on Windows. Git Bash is a bash shell that gets installed along with Git, giving you the same commands available on Mac and Linux.

Some commands in this book (like ls and cat) may not work or may produce different output in PowerShell or Command Prompt. To follow along exactly, use Git Bash.

In this book, terminal operations are displayed in dark background boxes like this:

$ git status
On branch main
nothing to commit, working tree clean

Prompt Symbols

An important detail in terminal displays is the prompt symbol at the beginning of each line. It varies depending on your environment.

This book uses $ throughout. If your environment shows % or >, simply type the command that appears after the $.

$ git status
On branch main

Lines with $: Commands you type (don’t type the $ itself) Lines without $: Output from the computer (the result)

So in the example above, you type git status, and the computer responds with On branch main.

A Note on Terminal Language Settings

Command output in this book is shown in English. If your system is configured for a different language, you may see translated output messages.

# English (as shown in this book)
$ git status
On branch main
nothing to commit, working tree clean

As long as the meaning is the same, there’s no difference in behavior. You can follow along regardless of your system’s language setting.

What Comments (#) Mean

The # symbol in code indicates a “comment.” Everything from # to the end of that line is treated as a comment and ignored by the computer. You don’t need to type it.

# This entire line is a comment (don't type it)
$ git add index.html    # <- only this part is a comment

• Line 1: Starts with #, so the entire line is a comment
• Line 2: git add index.html is the command; everything after # is a comment

In the example above, you only type git add index.html.

Git Commands vs. Bash Commands

The commands in this book fall into two main categories.

Git Commands

Any command starting with git is a Git command. These perform version control operations.

$ git init          # Initialize a Git repository
$ git add .         # Stage files
$ git commit -m "message"  # Create a commit
$ git push          # Send to remote
$ git pull          # Fetch from remote

Bash Commands (Shell Commands)

Commands that don’t start with git are general shell commands. These handle file operations and system tasks.

$ ls                # List files
$ cd my-project     # Change directory
$ cat index.html    # Display file contents
$ mkdir new-folder  # Create a new folder

These aren’t directly related to Git, but you’ll use them frequently during development. They’ll appear in this book whenever we need to check the state of things.

Reading Options

Commands can take “options” that modify their behavior.

$ git log --oneline    # Show history, one line per commit
$ git commit -m "message"  # Specify the commit message
$ ls -la               # List all files with details

Single hyphen (-): Short option (e.g., -m, -a) Double hyphen (--): Long option (e.g., --oneline, --all)

Short options use a single character; long options use a word. Some options have both short and long forms (e.g., -m and --message mean the same thing).

Placeholders

In this book, values you need to replace are shown in <> brackets.

$ git commit -m "<message>"
$ git switch <branch-name>
$ git clone <repository-url>

In the examples above, replace <message> with your actual message (e.g., "Initial commit"). Don’t type the <> brackets themselves.

Multi-Line Commands

When a command is long, it may be broken across lines with \ (backslash).

$ git log --oneline \
    --graph \
    --all

This is actually a single command. The \ means “continues on the next line.” You’ll get the same result typing everything on one line.

Truncated Output

When output is long, it may be shortened with ....

$ git log
commit a1b2c3d4e5f6a7b8...
Author: Your Name <email@example.com>
Date:   Mon Jan 15 10:00:00 2025 +0900

    Initial commit
...

Notation Reference

Chapter 1-7 Opening Git Bash TOC

In the previous section, we mentioned that Windows users should use Git Bash. Here’s how to open it.

There are several ways to open Git Bash, but opening it from VS Code (Visual Studio Code) is recommended. VS Code is covered in detail in Chapter 3, but it’s the most widely used code editor among developers.

Opening a Terminal in VS Code

1. Launch VS Code and open your project folder
2. Open from the menu: Click the hamburger menu icon (top-left) -> “Terminal” -> “New Terminal”

You can also use the keyboard shortcut (Windows: Ctrl+`, Mac: Cmd+`).

When the terminal opens, a panel appears at the bottom of the screen where you can type commands.

The image above shows a simple $ prompt, but your environment might display something like user@PC-name ~/project $ with your username and folder path. Git Bash may also show colorized text. Different displays are perfectly normal. As long as you can type after $ or %, you’re all set.

Type a command after $ and press Enter (Return) to run it. Many commands produce no output on success – the next prompt simply appears. If that feels unsettling, remember: no error message means it worked. No news is good news.

Windows users: The first time you open a terminal, it might default to PowerShell. If so, click the dropdown arrow next to the “+” button at the top right of the terminal panel and select “Git Bash.”

With that, you can use a terminal (Git Bash) right inside VS Code. Your project folder automatically becomes the current directory, so you can start running Git commands immediately.

Setting Git Bash as the Default (Windows Users)

If you’re tired of selecting Git Bash every time, you can make it the default terminal in VS Code.

1. Press Ctrl+Shift+P to open the Command Palette
2. Type “Terminal: Select Default Profile” and select it
3. Choose “Git Bash”

Now every new terminal will automatically open Git Bash.

Chapter 1-8 Summary TOC

In this chapter, you learned why Git matters in the AI era. Git isn’t just a file management tool – it’s the “defense” that keeps your AI-assisted development safe and under control.

What You Learned in This Chapter

• What Git is: A version control system that records and manages the history of changes to your files. You can always return to a previous state.
• Why Git matters in the AI era: Git’s importance is growing for three reasons: recording iterations, enabling safe experimentation, and tracking changes.
• Risks of AI code generation: Three key risks: unintended changes, quality/security issues, and the inability to reproduce previous states.
• How AI and Git work together: AI handles “offense” (code generation) while Git handles “defense” (history management and recovery).
• Command notation: $ is the prompt, # is a comment, and <> indicates a placeholder.
• Git Bash: Windows users should use Git Bash to run the commands in this book exactly as shown.

Comprehension Check

Next chapter preview: In Chapter 2, you’ll learn Git’s core concepts: repositories, commits, and branches. Understanding these concepts will give you a clear picture of how Git works under the hood.

Chapter 2-1 What Is a Version Control System? TOC

“The code was working yesterday, but now it’s broken.” “I want to undo that change, but I can’t remember what I modified.” You’ve been adding a new feature, rewriting code as you go, and suddenly the parts that used to work are broken too. Mashing Ctrl+Z won’t save you – it’s already too late. If you’ve ever written code, you’ve lived this nightmare.

In the age of AI coding, this problem is even worse. AI generates and modifies large amounts of code at once, making it nearly impossible for a human to track “what changed” and “what it looked like before.” That’s exactly why version control systems are more important now than ever.

A version control system automatically records every change made to your files, letting you jump back to any point in time. Who (or which AI) changed what, when, in which file, and how – it’s all recorded and available whenever you need it. If AI-generated code causes a problem, you can instantly restore “the way things were.” For any developer working alongside AI, this is a lifeline.

In modern software development, version control is as fundamental as electricity or running water. You simply won’t find a professional development team that doesn’t use it. And the global standard is Git.

The Power of Diffs – Seeing What Changed

One of Git’s most powerful features is the “diff” view. Below is an illustration of what a Git diff looks like in VS Code.

The left side shows the code before the change, and the right side shows it after. Deleted lines are highlighted in red, and added lines in green. In this example, a traditional for loop has been refactored into a more concise forEach call.

With this diff view, whether code was generated by AI or written by you at 2 AM, you can see exactly what changed at a glance. When something breaks, this view makes it dramatically faster to pinpoint the cause. And if needed, you can revert the change with a single click.

This is the core benefit of using Git. It makes changes visible and gives you the confidence to keep improving your code, knowing you can always go back.

One Click to Undo – Reverting Changes from the Diff View

“OK, so I can see the diff. But is reverting actually easy?” You might be surprised. With VS Code and Git, you can revert changes with a single click right from the diff view.

When you’re reviewing changes in the diff view, you’ll see arrow and plus buttons next to each change block. Click the arrow button, and that specific change is reverted – back to the original code. No commands to memorize. And you can selectively revert individual change blocks rather than the entire file.

Say you had AI write some code, but one part isn’t working right. You revert just the problematic section with one click, keep the rest, and try a different approach. You can experiment freely and redo things as many times as you want – that’s what a Git-powered development environment gives you.

The Origin Story of Git

Git was created in April 2005 by Linus Torvalds, the creator of Linux. The story behind it is quite dramatic.

At the time, the Linux kernel – one of the world’s largest open-source projects – used a commercial version control system called BitKeeper. BitKeeper was distributed and high-performance, but when a Linux developer reverse-engineered its protocol, the free license was revoked. Thousands of Linux kernel developers suddenly lost their development tool.

Torvalds evaluated existing version control systems like CVS and Subversion, but none met his requirements. Here’s what he needed:

• Distributed architecture (no dependence on a central server)
• Blazing speed (existing tools could take 30 seconds per patch)
• Support for non-linear development with thousands of parallel branches
• Efficient handling of a massive project like the Linux kernel

“I took CVS as an example of what not to do,” Torvalds later said. “If in doubt, do the exact opposite of what CVS does.”

Remarkably, Torvalds built the first version of Git in just 10 days. But this wasn’t a sudden impulse – he’d spent the previous four months designing a system to surpass BitKeeper. On April 7, 2005, the first Git commit was made, and that commit itself was recorded using Git.

Distributed vs. Centralized

Version control systems come in two flavors: centralized and distributed. Git is distributed. Understanding this distinction will help everything else about Git click into place.

Centralized (e.g., SVN)

In a centralized system, the complete project history lives only on the server. Developers have just the latest version of the files on their machines.

This means if the server goes down, everyone stops working. Want to view history, revert to an older version, or create a branch? You need a connection to the server. On an unreliable network, productivity takes a serious hit.

Distributed (Git)

In a distributed system, everyone has the complete history. When you git clone a repository, every commit from the very first to the latest is copied to your machine.

So even if the server (GitHub, etc.) goes down, you can keep working locally. Commits, branch creation, history searches – all happen on your machine without a network connection. You only need the network when sharing changes with others.

This difference directly impacts your day-to-day development experience. With Git, operations like “let me try something” or “let me dig through the history” are effortless. Branch creation is instant. History searches have zero network latency. This responsiveness is one of the key reasons Git is used worldwide.

Why Git Became the Global Standard

Today, Git is a “must-have” skill for developers. It’s not uncommon to see “Git experience required” on job listings. According to the Stack Overflow Developer Survey, over 93% of professional developers use Git as their version control system.

But Git wasn’t always popular. For several years after its birth in 2005, it was seen as “an obscure tool for Linux kernel developers” and was slow to gain traction in the wider developer community.

The Turning Point: GitHub

What changed everything was GitHub, launched in 2008. GitHub combined Git repository hosting with features like pull requests, issue tracking, and code review – all accessible through a web interface.

The game-changer was making open-source projects free to host. Individual developers and open-source communities flocked to GitHub, and enterprises followed. In 2018, Microsoft acquired GitHub for $7.5 billion. Today, with GitHub, GitLab, and Bitbucket, the Git-centric development ecosystem is firmly established.

Why Developers Choose Git

Git’s continued dominance is backed by solid technical reasons:

• Fast: Branch creation, history search, diff viewing – most operations happen locally with zero network latency
• Secure: All data is managed with cryptographic hashes, so corruption or tampering is immediately detectable
• Flexible: It adapts to any team size and development workflow
• Free: It’s open source – anyone can use it at no cost

Chapter 2-2 Git’s World: A Terminology Guide TOC

Git comes with a lot of its own terminology. “Repository,” “commit,” “branch,” “staging area” – if you’re hearing these for the first time, it can feel overwhelming. Don’t worry. In this section, you’ll get a bird’s-eye view of Git’s world and its key terms all at once.

A Bird’s-Eye View of Git

Working with Git revolves around “four locations” and “the operations that connect them.” Getting this big picture in your head first will make everything that follows much easier to understand.

Once you understand the relationship between the “locations” and “operations” in this diagram, you’ve grasped about 80% of Git. We’ll cover each one in detail from section 2-3 onward, so for now, just get a sense of the overall flow.

Quick Reference: Key Terms

The table below lists the terms you’ll learn in detail throughout this chapter. For now, just scan through them. As you read each section, the concepts will start to click.

Location Terms

Concept Terms

Operation Terms

Terms You’ll Learn Later

Later chapters will introduce these additional terms:

How to Read This Chapter

We recommend reading this chapter from top to bottom. Each section builds on the previous one, but if you get lost on a term, come back to this section as a reference.

There’s also a “Glossary” box at the end of the chapter with all terms summarized in a table for quick lookup.

Now, let’s dive into each concept in detail.

Chapter 2-3 Local vs. Remote Repositories TOC

One of the first concepts that trips up Git beginners is the “repository.” Specifically, understanding that there are two kinds – local and remote – is the first step to mastering Git.

The Big Picture of a Git Workflow

Let’s take a closer look at the diagram from section 2-2.

A Git workflow consists of “four locations” and “four operations.”

Four Locations

• Working tree: Where you actually edit files. This is the project folder you have open in VS Code or your editor of choice (also called the “working directory”)
• Staging area: Where you select and prepare changes for the next commit (also called the “index”)
• Local repository: The history stored on your own machine
• Remote repository: A shared repository on a server like GitHub or GitLab

Four Core Operations

1. add: Move changes from the working tree to the staging area
2. commit: Record the contents of the staging area in the local repository
3. push: Send the local repository’s history to the remote
4. pull: Bring the remote repository’s history into your local

Once you understand this flow, you’ve grasped about 80% of Git. Let’s look at each element in detail.

What Is a Repository?

A repository is where your project’s files and their complete change history are stored. Unlike a regular folder, it includes a record of every change – who changed what, and when.

The repository is physically stored in a hidden .git folder inside your project directory. This folder contains commit history, branch information, configuration files, and everything else Git needs to operate.

What Actually Happens When You “Create a Repository”

To turn an ordinary folder into a Git repository, you run the git init command. Let’s see what actually happens:

# An ordinary folder
$ ls -la my-project/
drwxr-xr-x  3 user  staff   96 Jan 15 10:00 .
drwxr-xr-x  5 user  staff  160 Jan 15 10:00 ..
-rw-r--r--  1 user  staff  100 Jan 15 10:00 index.html

# Run git init
$ cd my-project && git init
Initialized empty Git repository in /Users/user/my-project/.git/

# A .git folder has been added
$ ls -la
drwxr-xr-x  4 user  staff  128 Jan 15 10:00 .
drwxr-xr-x  5 user  staff  160 Jan 15 10:00 ..
drwxr-xr-x 12 user  staff  384 Jan 15 10:00 .git  <- This was added
-rw-r--r--  1 user  staff  100 Jan 15 10:00 index.html

This .git folder is the repository. Whether or not this folder exists is what distinguishes a “regular folder” from a “Git repository.”

Inside the .git Folder

Peeking inside the .git folder reveals how Git manages its data:

$ ls .git/
HEAD        # Records which branch you're currently on
config      # Configuration for this repository
objects/    # Actual data for commits and files (stored compressed)
refs/       # Branch and tag information
hooks/      # Auto-run scripts (advanced usage)

The critical thing to understand is that deleting the .git folder destroys all history. Your files will remain, but the change history will be completely lost. Conversely, as long as the .git folder exists, you can restore any past state of your project.

Local Repository

A local repository exists on your own computer.

Characteristics - Lives on your machine and is invisible to others - Works without an internet connection - A private space for experimentation and testing - Created with the git init command

With a local repository, you can make changes, commit, create branches, and perform most Git operations without ever going online. You can review past history and develop new features, all completely offline.

Remote Repository

A remote repository lives on a server like GitHub or GitLab.

Characteristics - Hosted on a server accessible over the internet - A shared space for team collaboration - Doubles as a backup - Can be copied locally with the git clone command

The remote repository is the hub of team collaboration. Each team member works in their own local repository and pushes completed changes to the remote, sharing their work with the rest of the team.

Basic Sync Operations

There are three fundamental operations for moving data between local and remote:

For solo development, you’ll primarily use the remote repository as a backup. For team development, it serves as the central hub for integrating everyone’s changes.

Chapter 2-4 Commits “Add” History; Saving “Overwrites” Files TOC

The most important concept in Git is the “commit.” A commit works fundamentally differently from a regular file save.

The Difference Between “Save” and “Commit”

Regular “saving” and Git “committing” serve different purposes. You don’t commit instead of saving – you save, and then commit. They work together.

File saving (Ctrl+S / Cmd+S) is still necessary

When you’re working in your editor and press Ctrl+S to save, that hasn’t changed. You still need to save for your file changes to take effect. But saving is an “overwrite” – each save replaces the previous state. You can undo with Ctrl+Z while the editor is open, but once you close it, that undo history is gone.

A commit creates a “history point”

A Git commit is a separate operation from saving. You run it whenever you think, “I want to record this current state in history.” When you commit, the entire project’s state at that moment is stored as a “history point.”

Create commit A, commit B, commit C… at whatever pace you like, and you can return to any of those points at any time. Close your editor, restart your computer, come back a year later – it doesn’t matter. The state at each commit is permanently preserved and always accessible.

Here’s the workflow:

1. Edit your files
2. Save with Ctrl+S (same as always)
3. When you want to preserve the current state, make a commit
4. Repeat steps 1-3

Saving “updates the file.” Committing “creates a history point.” Combining the two gives you the confidence that you can always go back.

The diagram makes it clear. With overwrite saving, previous versions are lost one after another. With Git, every commit is preserved, and you can move to any point in time simply by moving HEAD.

A Commit Is a “Snapshot”

A Git commit is like a photograph of your entire project’s state at a specific moment in time.

Every time you commit, a “photo” of the entire project is taken. Every file is captured in that photo, and looking back at it later lets you perfectly reconstruct “what the project looked like at that moment.”

Here’s the key point. When you want to go back, you just pick a “photo.” Your entire project instantly switches to the state it was in when that photo was taken. It doesn’t matter if you have 100 files or 1,000. Pick one photo, and every file reverts to its content at that point.

This is the essence of Git’s “snapshot” approach. Rather than rewinding diffs one by one, you restore “the complete state at that point.” So even if AI modifies dozens of files, as long as you’ve committed, there’s nothing to fear.

Technically, Git records the “complete state” of files at each commit, not just the “diff.” However, internally it optimizes storage by saving unchanged files as references to the previous commit, so it doesn’t waste disk space.

Viewing Actual Commit History

Commits aren’t an abstract concept. You can see exactly how they’re recorded using the git log command:

$ git log --oneline
a1b2c3d (HEAD -> main) Add user authentication
e4f5a6b Update header design
c7d8e9f Initial commit

Here’s what this output tells you:

• Each line is one commit: Newest at the top, oldest at the bottom
• The alphanumeric string on the left (a1b2c3d): A unique ID for the commit (the commit hash)
• The message on the right: The description recorded at commit time (the commit message)
• HEAD -> main: Shows where you currently are

To visualize branch divergence and merges, add the --graph option. This is one of the most commonly used commands in practice:

$ git log --oneline --graph
* a1b2c3d (HEAD -> main) Merge branch 'feature/login'
|\
| * b2c3d4e Add login form validation
| * c3d4e5f Create login page
|/
* d4e5f6a Update README
* e5f6a7b Initial commit

Each * represents a commit, and the lines show the branching and merging flow at a glance. This is especially useful when multiple people are working on a project or when branches are heavily used.

For more detailed information, drop the --oneline flag:

$ git log
commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 (HEAD -> main)
Author: Your Name <email@example.com>
Date:   Mon Jan 15 14:30:00 2025 +0900

    Add user authentication feature

As you can see, “who,” “when,” and “what” is completely recorded.

Viewing Past States

As commits accumulate, you’ll sometimes want to check “what did the code look like back then?” With Git, it’s easy:

# View the file content as of two commits ago
$ git show c7d8e9f:index.html
<!DOCTYPE html>
<html>
<head><title>My App</title></head>
<body></body>
</html>

# Compare with the current file
$ cat index.html
<!DOCTYPE html>
<html>
<head><title>My App - User Dashboard</title></head>
<body>
  <header>Welcome, User!</header>
  <!-- Much more code has been added -->
</body>
</html>

You can view the content of any file at any point in history, whenever you want. This is Git’s “nothing is lost” property in action.

Commit Hashes

Each commit is assigned a unique identifier (ID) called a “commit hash” or “SHA-1 hash.”

Full hash:      a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 (40 characters)
Short form:     a1b2c3d (first 7 characters)

The commit hash is automatically calculated from the commit’s contents – the changed files, the author, the timestamp, the commit message, and more. Identical content always produces the same hash, and even a one-character difference produces a completely different hash.

Why the short form is enough

In practice, you don’t need to type all 40 characters. Git can identify commits from the short form:

# All of these refer to the same commit
$ git show a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
$ git show a1b2c3d4e5f6
$ git show a1b2c3d

Usually, the first 5-7 characters are enough to uniquely identify a commit within a project. Git automatically searches for commits matching the string you provide, and if there’s exactly one match, it uses it. If multiple commits share the same prefix, Git warns you it’s ambiguous, and you just add a character or two to resolve it.

Why collisions don’t happen

SHA-1 uses a 40-character hexadecimal space (160 bits), which provides approximately 10^48 possible combinations. Even the 7-character short form gives about 268 million possibilities, so for projects with thousands or even tens of thousands of commits, collisions are virtually impossible.

Even a massive project like the Linux kernel (over 1 million commits) maintains uniqueness with about 12 characters.

How to check commit hashes

# Check the hash of the most recent commit
$ git log --oneline -1
a1b2c3d feat: Add login feature

# Show the full hash
$ git log -1 --format="%H"
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

git log --oneline automatically displays a short form of appropriate length (typically 7 characters). You can copy this directly and use it in other commands.

Why Commit Messages Matter

Every commit requires a “commit message” describing what changed and why.

Good commit message example

Add user authentication feature

- Implement login/logout functionality
- Use JWT for session management
- Hash passwords with bcrypt

Bad commit message example

fix stuff

A commit message is a letter to your future self and your teammates. Months later, when you need to understand “why was this change made,” a specific, meaningful message will save you hours of detective work.

Chapter 2-5 Branches Are Labels on Commits TOC

Branches are one of Git’s most powerful features. But many beginners misunderstand what they actually are. Getting this concept right unlocks Git’s true potential.

A Common Misconception: Branch = Copy of Files?

Many beginners assume “creating a branch = copying the entire project.” If you’ve ever managed versions by duplicating folders into project_v1, project_v2, etc., this misconception is understandable.

Misconception: Creating a branch copies your files

Reality: A branch is just a “pointer (reference)” to a commit

As the diagram shows, a branch is remarkably simple. Each branch just holds the information “which commit am I pointing to?” (a 40-character hash value). When you create a branch, no files are copied at all.

This design gives you several advantages:

• Instant creation: Creating a branch just writes a single file of a few dozen bytes
• Zero storage overhead: Create 1,000 branches and the extra space used is just a few KB
• Fast switching: It just changes where the pointer references, so it’s instantaneous

This “lightweight branching” is what sets Git apart from other version control systems. Create branches freely, experiment, and delete them when you’re done. This flexibility is what powers modern development workflows.

Why You Need Branches

The value of branches becomes clear with a concrete scenario.

Situation: You want to add a “dark mode” feature. But you’re not sure you can pull it off. It’ll take some trial and error, and you might fail.

The problem without branches:

If you start developing directly on main, your trial-and-error could break working code. If you decide to abandon the effort, you won’t know how far back to revert. In the worst case, you might break features that were working perfectly fine.

The solution with branches:

Branches let you completely separate “finished code” from “work in progress.”

main branch            -> Completed, tested code
feature/dark-mode      -> Dark mode in development (not yet finished)

You do all your dark mode development on the feature/dark-mode branch. No matter how much code you change on this branch, main is completely unaffected. When development is done and you’ve thoroughly tested everything, you merge it into main.

What if it doesn’t work out? Just delete the branch. main stays safe the entire time. Your existing features are never at risk.

Let’s look at the specific commands and the state of the project after each operation:

The key insight is that when you run git switch to change branches, the files in your folder actually change. Same folder, different contents depending on the branch. That’s the magic of Git.

git switch main      # Modern syntax (recommended)
git checkout main    # Legacy syntax (still works)

Branches let you completely isolate multiple streams of work. You can develop in parallel without any risk of one affecting another.

How Branches Work

A branch is physically a small file containing a 40-character commit hash. Look inside the .git/refs/heads/ directory, and you’ll find a file for each branch:

$ cat .git/refs/heads/main
e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4

$ cat .git/refs/heads/feature
d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3

As you can see, the contents of a branch file is just a hash value. When you create a new commit, this hash is updated to point to the new commit.

When you switch branches (git switch), Git performs the following steps:

1. Update HEAD: Change the HEAD pointer to the target branch
2. Restore files: Update the working tree to match the target commit’s state
3. Update the index: Sync the staging area with the target branch’s state

The diagram above shows a typical branch flow. A feature branch is created at commit B, then main and feature progress independently, and eventually they’re merged (combined).

What Actually Happens When You Switch Branches

Switching branches isn’t just a “display change.” The file contents actually change.

# On the feature/dark-mode branch, developing a new feature
$ git switch feature/dark-mode
Switched to branch 'feature/dark-mode'

$ cat styles.css
body {
  background: #1a1a1a;  /* Dark mode background */
  color: #ffffff;
}

# Switch to the main branch
$ git switch main
Switched to branch 'main'

$ cat styles.css
body {
  background: #ffffff;  /* Standard background */
  color: #333333;
}

The same file (styles.css) has different contents depending on which branch you’re on. Git rewrites the files based on the data stored in the .git folder.

This mechanism lets you manage multiple lines of development in a single project folder. No need to manually copy files or maintain multiple directories.

What Is HEAD?

HEAD is a special pointer that shows “where you currently are.” Think of it as the “You Are Here” pin on a map app. When working with Git, it’s essential to always know where you are. HEAD serves that purpose.

Normally, HEAD points to a branch name, and that branch points to a commit – which determines your current working state. Understanding this “two-level reference” structure is key to mastering Git.

As the diagram shows, HEAD normally points to a “branch,” and the branch points to a “commit.” When you create a new commit, the current branch pointer automatically moves to the new commit. HEAD keeps pointing to the same branch, so it effectively follows along to the latest commit.

When you switch branches (git switch feature), HEAD changes what it points to:

$ git switch main
Switched to branch 'main'
# HEAD -> main -> commit E

$ git switch feature
Switched to branch 'feature'
# HEAD -> feature -> commit D

# Checkout a commit hash directly
$ git checkout a1b2c3d
# or
$ git switch --detach a1b2c3d

# Create a new branch at the current commit
$ git switch -c my-new-branch

The main Branch

When you create a repository, a main branch is created by default. By convention, main holds “stable code that’s ready for production.”

New features and bug fixes are developed on branches that split off from main, then merged back in when complete. This is the standard workflow.

Branch Strategy in Practice

The word “branch” means “a division or subdivision.” Think of main as the “trunk” of a tree, with feature branches and bugfix branches growing out from it as its limbs.

In professional software development, you’ll almost never work directly on the main branch. Most companies and teams have explicit branching rules.

Here are some typical rules: “Direct commits to main are prohibited. Always create a working branch and merge via pull request (PR).” “Every PR requires at least one reviewer’s approval.” “CI (automated tests) must pass before merging.” Rules like these are standard practice.

Why so strict? In most setups, main is directly connected to the production environment. A buggy commit on main means users are affected. That’s why main is treated as sacred ground, and every change must pass through multiple checkpoints.

Here’s what the day-to-day flow looks like: Create a branch for your assigned task (e.g., feature/user-profile). Develop on that branch. When it’s ready, open a pull request. Your teammates review the code, and if everything looks good, it’s merged into main.

Even for solo projects, building this habit is worth it. If you get used to working directly on main, you’ll struggle when you join a team. And even solo, maintaining a “working main” means you always have a deployable state ready to go.

Branch Use Cases

Branches are easier to manage when you follow naming conventions:

$ git switch -c experiment/copilot-refactor

Chapter 2-6 The Role of the Index (Staging Area) TOC

Git has a unique mechanism called the “staging area” (also known as the “index”). It’s a concept specific to Git that you won’t find in other version control systems.

Why Staging Exists

The staging area was born from the demands of the Linux kernel – a massive project with hundreds of changes per day. In that environment, developers needed fine-grained control over “which changes go into each commit.”

Without a staging area, you’d have to either commit all changes in your working directory at once or split commits only at the file level. The staging area lets you create commits in “meaningful units.”

A Concrete Scenario: Committing Selectively

Situation: You’ve modified two files, but one is finished and the other is still in progress.

# Check current status
$ git status
Changes not staged for commit:
  modified:   login.js      # <- Done! Ready to commit
  modified:   dashboard.js  # <- Still in progress...

# Stage only login.js
$ git add login.js

# Check status again
$ git status
Changes to be committed:
  modified:   login.js      # <- Staged (will be included in commit)

Changes not staged for commit:
  modified:   dashboard.js  # <- Not staged (will NOT be included)

# Commit
$ git commit -m "Fix login feature"
# -> Only login.js is committed
# -> dashboard.js remains as work in progress

The staging area lets you commit “only the finished parts” without worrying about dragging in unfinished work.

The Three States

Files managed by Git move through three states:

1. Working tree: Where you actually edit files. The files open in your editor live here.

2. Staging area: Where you prepare changes for the next commit. Use git add to move changes here.

3. Repository: Where committed changes are permanently stored. Running git commit records the staging area’s contents here.

Four Benefits of Staging

1. Selective commits: Even if you’ve changed multiple files, you can pick just the related changes for each commit

2. Partial staging: You can stage specific lines within a single file (git add -p)

3. Review opportunity: Before committing, you can inspect “what am I about to commit?” (git status, git diff --staged)

4. Handling interruptions: If an urgent bug fix comes in mid-development, you can set aside your current work and create a separate commit

The Actual Flow

# 1. Edit files (work in the working tree)
$ code feature.js  # Open and edit in VS Code

# 2. Stage your changes
$ git add feature.js

# 3. Review what's staged
$ git status
Changes to be committed:
  modified:   feature.js

# 4. Commit
$ git commit -m "Add user authentication"

Reading git status

git status is one of the most frequently used Git commands. Let’s look at how to read its output:

$ git status
On branch main                          # Current branch

Changes to be committed:                # Shown in green
  (use "git restore --staged <file>..." to unstage)
        modified:   completed.js        # -> Will be included in commit

Changes not staged for commit:          # Shown in red
  (use "git add <file>..." to update what will be committed)
        modified:   work-in-progress.js # -> Will NOT be included in commit

Untracked files:                        # Shown in red
  (use "git add <file>..." to include in what will be committed)
        new-file.js                     # -> Not yet tracked by Git

What the three sections mean:

Before every commit, check git status and verify that “the green section contains exactly the files you intend to commit.”

Chapter 2-7 Summary TOC

In this chapter, you learned the core concepts of Git. By understanding the three pillars – repositories, commits, and branches – you should now have a clear mental model of how Git works.

What You Learned in This Chapter

• Repository: Where a project’s files and change history are stored. The .git folder is its physical form
• Commit: A snapshot of the project’s state. Think of it as a “save point before the boss fight”
• Branch: A pointer to a commit. Not a copy of files – extremely lightweight
• HEAD: A pointer showing where you currently are. Your “You Are Here” marker
• Staging area: Where you select and prepare changes for a commit. Enables partial commits
• The three zones: Changes flow through working tree -> staging area -> repository

Comprehension Check

Next chapter preview: In Chapter 3, you’ll set up your development environment – Git, VS Code, and more. Let’s get ready to actually use Git.

Free Downloadable Content for This Book

Five free bonus resources are available to accelerate your learning.

• Git Command Complete Reference (80+ commands, 150+ options)
• Bash/CLI Command Cheat Sheet (100+ commands, 250+ options)
• Shell Techniques Complete Guide (pipes, variables, scripting)
• Git Error Resolution Complete Guide (60+ errors with solutions)
• Git Hooks Samples (pre-commit, pre-push, commit-msg)

Download URL: https://alphaelements.co.jp/en/books/why-git-vol1/

Passphrase: UnlockGit2026

A passphrase is required to access the download.