What is Git?
Git is a distributed version control system. In plain English, it tracks every change you make to your files and lets you go back to any previous version at any time. Think of it as an unlimited undo history for your entire project.
Without version control, developers resort to naming files project-v2-final-FINAL.zip or emailing code back and forth. Git replaces all of that with a clean, reliable timeline of changes. Every modification is recorded as a commit — a snapshot of your project at a specific moment.
Git was created in 2005 by Linus Torvalds (the creator of Linux) and has since become the industry standard. Whether you work on personal projects or in a team of hundreds, Git is the foundation of modern software development.
Setting up Git
Before creating your first repository, you need two things: Git installed on your machine and a basic identity configuration. This takes less than five minutes.
Install Git
Git is available on every major operating system. On macOS, it comes pre-installed or you can get it via Homebrew (brew install git). On Windows, download the installer from git-scm.com. On Linux, use your package manager (sudo apt install git on Ubuntu/Debian, sudo dnf install git on Fedora). Once installed, verify it works by checking the version:
If you see a version number, you're ready. The exact version does not matter for anything in this guide — any version from 2.x onward will work.
Configure your identity
Every Git commit records who made the change. Before your first commit, tell Git your name and email address. The --global flag means this configuration applies to all repositories on your machine. You only need to do this once.
This information is attached to every commit you make. If you contribute to open-source projects, use the same email as your GitHub or GitLab account so your contributions are properly attributed.
Create your first repository
A repository (or "repo") is a project folder that Git tracks. It contains your files plus a hidden .git/ directory where Git stores the entire history. Let's create one from scratch.
git init — Initialize the repository
The git init command transforms a regular directory into a Git repository. It creates the hidden .git/ folder that contains all the internal machinery — the commit database, configuration, and references. You never need to modify this folder manually; Git manages it entirely.
That's it. Your directory is now a Git repository. Nothing has changed in your visible files — the only addition is the .git/ folder. Read the full git init guide for advanced options like bare repositories and reinitializing existing projects.
Your first commit — git add + git commit
Creating a commit is a two-step process. First, you stage your changes with git add — this tells Git which files to include. Then you commit with git commit — this permanently records the staged changes as a snapshot. The -m flag lets you write the commit message inline.
Congratulations — you've created your first commit. The hash a1b2c3d is a unique identifier for this snapshot. You can always return to this exact state of your project later. Write clear commit messages that explain why you made a change, not just what changed.
Understand the Git workflow
Git organizes your work into three distinct areas. Understanding how files move between them is the single most important concept for any Git beginner.
Working directory, staging area, and repository
Every file in a Git project lives in one of three zones:
Working directory
The files you see and edit on disk. This is your everyday workspace. Changes here are not yet tracked by Git until you stage them.
Staging area
A preparation zone (also called the "index"). When you run git add, files move here. It lets you choose exactly what goes into the next commit.
Repository
The permanent history stored in .git/. When you run git commit, the staged snapshot becomes part of this immutable timeline.
The flow is always the same: edit files in the working directory, stage them with git add, then commit them with git commit. This two-step process gives you precise control over what goes into each snapshot.
git status — Know where you stand
The git status command is your compass. It tells you which branch you're on, which files have been modified, which are staged and ready to commit, and which are completely new (untracked). Run it often — especially before committing — to make sure you're including exactly what you intend.
In this example, README.md has been modified but not yet staged, and style.css is a brand-new file Git has never seen. Neither will be included in your next commit until you run git add. See the full git status guide for tips on reading the short format.
git diff — See exactly what changed
While git status tells you which files changed, git diff shows you what changed inside them, line by line. Lines prefixed with - were removed; lines prefixed with + were added. It's invaluable for reviewing your own work before committing.
By default, git diff shows unstaged changes only. To see what's already staged (ready to commit), use git diff --staged. Explore the full git diff guide for comparing branches and specific commits.
Navigate your history
One of Git's greatest strengths is the ability to look back through every change ever made. The git log command is your window into that timeline.
git log — Browse commit history
git log displays your commits from newest to oldest. Each entry shows the commit hash, author, date, and message. The --oneline flag gives you a compact single-line view that is much easier to scan. You can also use --graph to visualize branches.
Every commit hash is a reference you can use with other commands. For example, git diff a1b2c3d b2c3d4e would show you exactly what changed between two commits. Check the full git log guide for filtering by date, author, and file path.
The .gitignore file
Not every file belongs in version control. Dependencies downloaded by a package manager, environment variables containing secrets, OS-generated metadata, and build output are all things Git should ignore. The .gitignore file tells Git which files and folders to skip entirely.
Create a .gitignore file in the root of your repository and list one pattern per line. Wildcards like * match any characters, and trailing slashes indicate directories. A good practice is to add your .gitignore in your very first commit so that unwanted files never enter the history.
GitHub maintains an excellent collection of .gitignore templates for different languages and frameworks. Starting from a template and customizing it to your project saves time and prevents common mistakes like accidentally committing API keys or large binary files.
You now have a solid foundation: Git is installed, your identity is configured, you've created a repository, made commits, and you understand how files flow through the three areas. This is everything you need to start using Git productively on your own projects. The next step is learning about branches and collaboration — but that's a topic for another guide.