Git Basics: init, add, commit, branch & merge Explained

You can be productive in Git with just five commands: git init creates a repository, git add stages changes, git commit saves a snapshot, git branch starts a parallel line of work, and git merge combines it back. Everything else — logs, diffs, remotes — builds on that loop.

Command	What it does	When you run it
git init	Turns a folder into a repository	Once, at the start of a project
git add <file>	Stages changes for the next snapshot	Before every commit
git commit -m "msg"	Saves a permanent snapshot	Whenever a small unit of work is done
git branch <name>	Creates a new line of development	Before starting a feature or experiment
git merge <name>	Combines a branch into the current one	When the feature is finished

How Git Thinks: Three Areas

Every file you touch lives in one of three places, and most beginner confusion disappears once you can name them.

Area	What lives there	Command that moves things in
Working directory	The files you actually edit	(just edit and save)
Staging area (index)	Changes selected for the next commit	git add
Repository (.git)	The permanent history of snapshots	git commit

The flow is always edit → stage → commit. The staging area exists so you can commit some of your edits without committing all of them — for example, the bug fix but not the half-finished refactor sitting in the same folder.

The Core Commands

git init

Run it once inside your project folder:

git init

This creates a hidden .git directory that holds the entire history — delete it and the folder becomes an ordinary directory again.

git add — choose what goes into the snapshot

git add report.py        # stage one file
git add src/             # stage a folder
git add -p               # stage hunk by hunk (interactive)

git add does not save anything permanently. It only marks changes as "include this in the next commit." If you edit the file again after staging, the new edit is not staged — you must git add again.

git commit — save the snapshot

git commit -m "Fix off-by-one in pagination"

A commit records the staged changes, the author, a timestamp, and a message, and gets a unique hash like a3f9c12. Good messages say why in the imperative mood: "Add input validation," not "changed stuff."

git status and git log — your two sanity checks

git status answers "what state is everything in right now?" — which files are modified, staged, or untracked. git log --oneline answers "what happened before?" Run git status constantly; it is free and prevents most accidents.

Branching: Parallel Timelines

A branch is just a movable label pointing at a commit — creating one is instant and costs almost nothing.

git branch login-feature     # create
git switch login-feature     # move onto it (older guides use: git checkout)
git switch -c login-feature  # create + switch in one step

Commits you make now extend login-feature while main stays untouched. When the work is done:

git switch main
git merge login-feature

Two things can happen:

Merge type	When it happens	Result
Fast-forward	main has no new commits since branching	main label simply moves forward; no new commit
Three-way merge	Both branches have new commits	Git creates a merge commit with two parents

Worked Example 1: Your First Repository

mkdir notes && cd notes
git init
echo "# My Notes" > README.md
git status                      # README.md shown as untracked
git add README.md
git commit -m "Add README"
echo "- buy milk" >> README.md
git add README.md
git commit -m "Add first note"
git log --oneline
# 4e2d1ab Add first note
# 9c01f37 Add README

Two commits, each a snapshot you can return to at any time. That edit → add → commit rhythm is 90% of daily Git.

Worked Example 2: A Feature Branch and a Merge Conflict

git switch -c title-change
# edit README.md: change the title to "# Shopping Notes"
git commit -am "Rename title"

git switch main
# edit README.md: change the title to "# Personal Notes"
git commit -am "Clarify title"

git merge title-change
# CONFLICT (content): Merge conflict in README.md

Both branches edited the same line, so Git refuses to guess. Open the file:

<<<<<<< HEAD
# Personal Notes
=======
# Shopping Notes
>>>>>>> title-change

Delete the markers, keep the line you want (or write a third version), then:

git add README.md
git commit                      # completes the merge

A conflict is not an error — it is Git asking a question only you can answer.

Common Mistakes

Running git add . reflexively. It stages everything, including debug prints, secrets, and temp files. Prefer naming files, or use git add -p to review each change. A .gitignore file keeps build artifacts out permanently.

Committing once a day in one giant lump. Huge commits are impossible to review or revert selectively. Commit every time one logical change is complete — even if that means ten commits an hour.

Forgetting which branch you are on. Committing to main when you meant a feature branch is the classic slip. git status shows the current branch on its first line; read it before you commit.

Confusing Git with GitHub. Git is the version-control program on your machine; GitHub is a hosting service for Git repositories. Everything on this page works offline with no account at all.

A Daily Loop Worth Memorizing

Before closing the laptop, run this cycle once: git status to see where you stand, git add -p to stage deliberately, git commit -m "..." to checkpoint, and git log --oneline -5 to confirm the story reads sensibly. Do it for a week and the commands stop being commands — they become how you think about your work changing over time.