Git

Git explained

Updated June 2026 · 7 min read

Git is not a person. This is important, because at some point you will run git blame and it will feel personal.

The joke is fair, though. Git does keep a record of what changed, when it changed, and who changed it. That sounds dramatic until your project breaks and you suddenly want exactly that information.

What Git is

Git is a version control system. It tracks changes to files over time, mostly code, but also docs, configs, notes, and anything else that benefits from a history.

Instead of saving folders like project-final, project-final-2, and project-final-real-this-time, Git lets you save meaningful snapshots called commits.

git status
git add README.md
git commit -m "Update README"
git log

That is the core loop: inspect changes, stage changes, save a snapshot, read history.

Why developers use Git

Git solves a boring problem that becomes terrifying quickly: projects change constantly. Files are edited, deleted, renamed, fixed, broken, refactored, and occasionally improved by accident.

Git gives you a timeline. You can see what changed, compare versions, undo mistakes, work on features separately, and collaborate without everyone emailing zip files around like it is a group project from 2009.

History. You can see what changed and when.
Safety. You can recover from many mistakes instead of manually rebuilding lost work.
Collaboration. Multiple people can work on the same project without constantly overwriting each other.
Experimentation. Branches let you try something without disturbing the main version.
Accountability. Not in the courtroom sense. More in the "why is this line here?" sense.

The basic Git workflow

Most daily Git work is smaller than it looks. You make changes, check them, stage the ones you want, commit them, and push them somewhere shared.

git status
git diff
git add .
git commit -m "Fix export button"
git push

git status tells you what changed. git diff shows the actual line-by-line edits. git add stages changes for the next snapshot. git commit saves that snapshot locally. git push sends it to a remote repository, usually on GitHub, GitLab, or Bitbucket.

Git is not saving your work every second. A commit is you saying: this version matters enough to remember.

Git repositories, commits, and branches

A Git repository is a project folder with Git history inside it. A commit is one saved point in that history. A branch is a movable line of work.

The default branch is often called main. You might create another branch to work on a feature or fix:

git switch -c add-login-page

Now your changes happen on that branch. Later, the branch can be merged back into main. In normal human language: work over here for a while, then bring it back when it is ready.

Common Git commands

git init creates a new Git repository.
git clone copies an existing repository to your machine.
git status shows what changed.
git diff shows the actual edits.
git add stages files for a commit.
git commit saves a snapshot.
git pull brings remote changes down to your machine.
git push sends your commits to the remote.
git switch moves between branches.
git log shows commit history.

What git blame actually does

git blame sounds like a productivity tool designed by a manager having a bad week. It is not supposed to be social punishment. It shows which commit last changed each line of a file.

git blame app.js

The output usually includes a commit hash, an author, a date, and the line content. The useful question is not "who do we shame?" The useful question is "what change introduced this line, and what context did it have?"

Often the answer is humbling. The author was you. The date was yesterday. The commit message was "quick fix." Git has a sense of humor and it is mostly timestamps.

How to use git blame without being weird

Use git blame to find context, not a target. Once you know the commit that changed a line, open the commit and read the surrounding diff. The line may look wrong today because the product changed, an API changed, or a later commit removed the thing that made it make sense.

git blame README.md
git show abc1234

git blame points at the last change. git show helps explain that change. Together, they are less "who broke this?" and more "what was happening here?"

The beginner Git mental model

Git has a reputation for being confusing because it exposes a lot of machinery. At the beginning, keep the model small:

Your working directory is what you are editing right now.
The staging area is what you plan to include in the next commit.
A commit is a saved snapshot.
A branch is a line of snapshots.
A remote is the shared copy somewhere else.

That is enough to do useful work without turning every merge conflict into a personality test.

So who is Git?

Git is not a person. Git is the memory of the project. It remembers what changed, who changed it, and when. Sometimes that feels accusatory. Most of the time, it is just the receipt.

And yes, git blame could have had a friendlier name. But then we would have lost one of the few honest command names in computing.

Turn repository docs into PDFs Convert README files, Markdown notes, and technical docs locally in your browser.
Open README to PDF

New to the command line too? Read Terminal commands explained for sudo, curl, cron, and the other tiny words that run your machine.