What is Git?

Introduction

Git is a version control system — software that tracks every change you make to your code over time. Think of it as a time machine for your project: you can go back to any previous state, see exactly what changed and when, and work on new features without risking your working code.

Without Git, most developers would rely on folders named things like project-final, project-final-v2, project-ACTUALLY-final. Git replaces that chaos with a clean, powerful system.

Theory

The problem Git solves

Imagine you are building a website. It works perfectly. You start adding a new feature — and break everything. Without version control, you have to remember every change you made and manually undo them. With Git, you just type one command to go back to the working version.

Core concepts

• Repository (repo) — a folder tracked by Git. It contains your project files plus a hidden .git folder where all the history is stored.
• Commit — a saved snapshot of your project at a specific point in time. Each commit has a unique ID, a message describing what changed, and a timestamp.
• History — the complete list of all commits, forming a timeline of your project's evolution.
• Working directory — your actual project files as you edit them right now.
• Staging area (index) — a holding area where you assemble the changes you want to include in your next commit.

The three states of a file

Every file in a Git repository is in one of three states:

• Modified — you have changed the file but not yet told Git about it.
• Staged — you have marked the changed file to go into the next commit.
• Committed — the file is safely stored in the Git database.

Real World Example

Here is what a typical day with Git looks like for a developer:

1. They start work in the morning. Their code is in a clean, committed state.
2. They add a new navigation menu. Something breaks — the whole page goes blank.
3. Instead of spending an hour debugging, they run git diff to see exactly what lines they changed.
4. They spot the bug, fix it, and run git add . and git commit -m "Add navigation menu".
5. They push the code to GitHub. Their colleague can now pull the changes and continue working.

Every team at every software company — from startups to Google — uses Git every single day.

Git vs Other Version Control Systems

Git is a distributed VCS. Every developer has the full project history on their own computer — not just the latest version. This means you can work offline, and there is no single point of failure.

Older systems like SVN (Subversion) were centralised — you needed a connection to the server to commit anything. Git made branching and offline work fast and easy, which is why it took over the industry.

Centralised VCS:   Developer A ─┐
                   Developer B ─┤─── Central Server (single source)
                   Developer C ─┘

Distributed VCS:   Developer A ─ full copy of history
(Git)              Developer B ─ full copy of history
                   Developer C ─ full copy of history
                   GitHub ─────── shared remote copy

Common Mistakes

• Confusing Git and GitHub. Git is the tool; GitHub is just one of many hosting services for Git repositories (others: GitLab, Bitbucket).
• Never committing. Some beginners write thousands of lines before making a single commit. Commit early and often — at least once per logical unit of work.
• Committing everything including secrets. API keys, passwords, and .env files should never be committed. Use .gitignore (covered in Lesson 6).
• Writing useless commit messages. "fix", "stuff", "asdf" tell nobody (including future you) what changed. Write descriptive messages.

Best Practices

• Commit after every logical change — not too rarely, not every single line.
• Write commit messages in the imperative tense: "Add login form" not "Added login form".
• Never commit broken code to the main branch.
• Learn Git in the terminal first — GUI tools are fine later, but understanding the commands gives you full control.

Practice Exercise

No code required for this exercise — just reflection:

1. Think of the last time you accidentally broke something while coding and had to undo your changes. How long did it take? How would Git have helped?
2. On a piece of paper, draw the three states of a file (Modified → Staged → Committed) and the commands that move a file between states. We will verify this in the next lesson.
3. Look at the .git folder inside this repository (it may be hidden — enable "show hidden files" in your file manager). Do not edit anything inside it, but notice it exists.

Assignment

Research task: Visit the official Git website (git-scm.com) and find the answer to these questions:

1. In what year was Git first created, and by whom?
2. What is the default branch name when you create a new repository with git init? (Hint: it changed in recent versions.)
3. What is the name of the hidden file inside a repository that stores all Git data?

Interview Questions

• What is the difference between Git and GitHub? — Git is a version control system that runs locally; GitHub is a cloud hosting service for Git repositories.
• What is a commit? — A commit is a saved snapshot of the project at a point in time, with a unique ID, timestamp, and message.
• What is the staging area? — An intermediate zone where you place changes before committing them. It lets you commit only some of your current changes.
• Why is Git distributed? — Every developer has the full history locally. This enables offline work, faster operations, and no single point of failure.

Additional Resources

• Pro Git book (free online) — the definitive Git reference
• git-scm.com/docs — official command reference
• Oh My Git! — a game-based Git learning tool