The Complete Guide to Git in 2026

Git is the version-control system nearly every software team uses — it tracks every change to your code, lets you branch and experiment safely, and makes collaboration possible. This complete guide walks Git from how it actually works to the everyday commands, branching, merging, remotes and undoing mistakes, with real commands throughout.

How Git works: the three areas

Git tracks your project through three areas. Understanding them makes every command make sense:

• Working directory — the actual files you edit.
• Staging area (index) — a snapshot you’re preparing for the next commit; you choose exactly what goes in.
• Repository (.git) — the committed history, stored locally.

A commit is an immutable snapshot of the staged content, identified by a SHA hash, with a message, author and a link to its parent(s). History is a chain of these snapshots.

Getting started: init, clone, config

Start a repository from scratch with init, or copy an existing one with clone. Set your identity once so commits are attributed correctly.

# one-time identity setup
git config --global user.name "Your Name"
git config --global user.email "[email protected]"

# start a new repo
git init

# or copy an existing one
git clone https://github.com/user/repo.git

The core workflow: status, add, commit

The everyday loop is: change files, check what changed, stage the parts you want, and commit them with a clear message. git status is your compass — run it often.

git status                 # what changed and what's staged
git add file.js            # stage one file
git add .                  # stage everything changed
git commit -m "Add login validation"

git log --oneline --graph  # view history compactly

Branching

A branch is a lightweight, movable pointer to a commit. Branches let you build a feature in isolation without disturbing the main line. Creating and switching branches is instant.

git branch                 # list branches
git switch -c feature/login  # create + switch (modern)
# (older equivalent: git checkout -b feature/login)

# ...work and commit on the branch...

git switch main            # back to main

Merging vs rebasing

Both integrate one branch’s changes into another, differently. Merge creates a merge commit that ties two histories together — it preserves exactly what happened. Rebase replays your commits on top of another branch, producing a linear history but rewriting your commits (new hashes).

# merge feature into main (preserves history)
git switch main
git merge feature/login

# OR rebase feature onto main (linear history)
git switch feature/login
git rebase main

Working with remotes

A remote is a version of your repository hosted elsewhere (GitHub, GitLab). You push local commits up, and fetch/pull others’ commits down. fetch downloads without changing your files; pull fetches *and* merges.

git remote -v                        # list remotes
git push -u origin feature/login     # push + set upstream
git fetch origin                     # download, don't merge
git pull origin main                 # fetch + merge into current branch

Undoing changes

Git can undo almost anything. Pick the right tool for how far along the change is:

• git restore <file> — discard unstaged changes to a file.
• git restore --staged <file> — unstage (keep the edits).
• git commit --amend — fix the most recent commit (message or content).
• git revert <commit> — make a new commit that undoes an old one (safe for shared history).
• git reset --soft/--mixed/--hard <commit> — move the branch pointer back (rewrites history).

git restore src/app.js          # throw away local edits
git commit --amend -m "Better message"
git revert a1b2c3d              # safely undo a pushed commit

Ignoring files with .gitignore

A .gitignore file tells Git which paths never to track — dependencies, build output, secrets, editor cruft. Add it early; files already committed must be removed from tracking separately.

# .gitignore
node_modules/
dist/
.env
*.log
.DS_Store

Resolving merge conflicts

A conflict happens when two branches change the same lines. Git pauses and marks the file with conflict markers; you edit it to the desired result, then stage and continue.

<<<<<<< HEAD
const timeout = 3000;
=======
const timeout = 5000;
>>>>>>> feature/login

# after editing to the version you want:
git add config.js
git commit            # (or: git rebase --continue)

Everyday commands worth knowing

• git diff — see unstaged changes (git diff --staged for staged).
• git stash / git stash pop — shelve work-in-progress and restore it later.
• git log --oneline --graph --all — a compact visual history.
• git cherry-pick <commit> — apply a single commit onto the current branch.
• git blame <file> — see who last changed each line and when.
• git reflog — the safety net: a log of where HEAD has been, to recover "lost" commits.

Branching workflows

Teams adopt a convention so branches stay predictable:

• GitHub Flow — branch off main, open a pull request, review, merge. Simple and popular.
• Trunk-based development — short-lived branches merged into main frequently, behind feature flags. Favored for continuous delivery.
• Git Flow — long-lived develop/release/hotfix branches. Heavier; mostly for versioned/release-cadence products.

For most teams in 2026, GitHub Flow or trunk-based development keeps things fast and reviewable.

Git best-practices checklist

• Commit small, logical units with clear imperative messages.
• Branch for every feature/fix; keep branches short-lived.
• Pull/rebase before pushing to reduce conflicts.
• Never rebase or force-push shared/public history.
• Use git revert (not reset) to undo pushed commits.
• Add a .gitignore early; never commit secrets or node_modules.
• Open pull requests for review before merging to main.

Practice Git-tracked projects in XCODX Studio — build and run code in the browser. See also our folder structure best practices and the web development roadmap 2026.