NOTE
Most of the content in this work was generated with the assistance of AI and carefully reviewed, edited, and curated by the author. If you have found any issues with the content on this page, please do not hesitate to contact me at support@issacc.com.
Git Crash Course — Quickstart & Cheat Sheet
A fast, practical guide to go from zero → shipping with Git in under an hour.
0) Mental Model (what Git is)
- Snapshots, not diffs: Each commit is a snapshot of your project (+ a pointer to its parent).
- Branches are pointers: A branch is just a name pointing to a commit.
- HEAD: Your current position; usually points at a branch name.
- Remote: Another copy of the repo (e.g., GitHub/Bitbucket).
origin
is the default remote name.
1) Initialize / Clone
# Start a new repo in the current folder
git init
# Clone an existing repo
git clone <git-url>
cd <repo>
2) Daily Driver Commands (the 10 you’ll use 90% of the time)
# See what changed (staged, unstaged, untracked)
git status
# What changed inside files
git diff # unstaged
git diff --staged # staged vs last commit
# Stage and commit
git add <file|dir> # or: git add -A
git commit -m "feat: short, imperative summary"
# Branches
git branch # list
git switch -c feature/my-thing # create + switch
# (or) git checkout -b feature/my-thing
# Sync with remote
git fetch # update remote refs
git pull --rebase # get latest + replay your commits
git push -u origin feature/my-thing
Message style: Use Conventional Commits (
feat:
,fix:
,docs:
,refactor:
,chore:
,test:
). Keep subject ≤ 72 chars, imperative mood (“Add”, not “Added”).
3) Branching & Collaboration (sane defaults)
- Keep a protected
main
(ortrunk
) always releasable. - For work: create short‑lived feature branches:
feature/<slug>
. - Update before you branch:
git switch main && git pull --rebase
. - After work: push branch, open PR, request review, squash‑merge into
main
.
Create + push a feature:
git switch main && git pull --rebase
git switch -c feature/login-oauth
# ...edit files...
git add -A && git commit -m "feat: add OAuth login"
git push -u origin feature/login-oauth
Open a Pull Request (on GitHub, GitLab, etc.) and choose Squash and merge.
4) Fixing Mistakes (your safety net)
See the timeline
git log --oneline --graph --decorate --all
Reflog (time machine for HEAD)
git reflog # find where HEAD was; recover lost commits/branches
Unstage changes (but keep edits)
git reset HEAD <file>
Discard local edits (careful)
git checkout -- <file> # reset file to last commit
# or modern
git restore --source=HEAD -- <file>
Amend the last commit (message or staged content)
git add <more-files>
git commit --amend
Revert a bad commit (safe for shared branches)
git revert <commit-sha>
Reset (move branch pointer)
# soft: keep changes staged (only move HEAD)
git reset --soft <commit>
# mixed (default): keep changes unstaged
git reset <commit>
# hard: discard working tree + index to match commit (danger!)
git reset --hard <commit>
5) Merge vs Rebase (and when)
- Merge: keeps true history; creates a merge commit. Good for long-running collaborative branches.
- Rebase: rewrites your local branch history to be linear; great for keeping feature branches clean before PR.
Keep your feature branch up to date
git switch feature/login-oauth
git fetch origin
git rebase origin/main # replay your commits after latest main
# resolve conflicts, then
git rebase --continue
Rule of thumb: Rebase your own branches; don’t rebase a shared/remote history others already pulled.
6) Resolve Merge Conflicts (quick recipe)
- Run your merge/rebase and hit a conflict.
- Open the conflicted files; look for markers:
<<<<<<< HEAD
your version
=======
incoming version
>>>>>>> origin/main
- Edit to the desired result, delete markers.
git add <fixed-files>
- Continue:
git merge --continue
orgit rebase --continue
If stuck: git merge --abort
or git rebase --abort
.
7) Stash & Work-in-Progress
# save work temporarily
git stash push -m "WIP: refactor auth"
# list stashes
git stash list
# bring back latest
git stash pop # or: git stash apply stash@{2}
8) Review Tools
# See who changed what line (and when)
git blame <file>
# Quick file history
git log -- <file>
# Show commit details
git show <commit>
9) Tags & Releases
# lightweight tag
git tag v1.0.0
# annotated tag (preferred for releases)
git tag -a v1.0.0 -m "First stable release"
# push tags
git push --tags
10) .gitignore (common patterns)
# Node
node_modules/
.npmrc
# Python
__pycache__/
*.py[cod]
.venv/
# OS / editors
.DS_Store
Thumbs.db
.vscode/
.idea/
# Build artifacts
/dist/
/build/
*.log
11) Binary/Large Files
- Use Git LFS for large/binary assets:
git lfs install
git lfs track "*.psd"
Commit the generated .gitattributes
file.
12) Clean History for PR (autosquash fixups)
# mark tidy-up commits
git commit --fixup <sha>
# then interactive rebase w/ autosquash
git rebase -i --autosquash origin/main
Pick order, squash/fixup as prompted.
13) Bisect (find the commit that broke things)
git bisect start
git bisect bad # current is bad
git bisect good <sha|tag> # a known good point
# Git jumps to a middle commit; test → mark good/bad
# repeat until offending commit is found
14) Minimal Team Workflow (recommended)
main
protected; CI must pass.- Dev: branch from
main
→ small commits → push → PR. - Rebase your branch regularly on
origin/main
. - Review → squash‑merge →
main
auto‑deploy.
15) 30‑Minute Hands‑On (do this once)
# 1) Init & first commit
tmpdir=$(mktemp -d); cd "$tmpdir"; mkdir app && cd app
echo "hello" > index.txt
git init && git add -A && git commit -m "feat: initial"
# 2) Branch & change
git switch -c feature/greet
echo "world" >> index.txt
git commit -am "feat: add world"
# 3) Rebase on main
git switch main
echo "!!!" >> index.txt
git commit -am "chore: excite"
git switch feature/greet && git rebase main
# 4) Resolve conflict (edit index.txt), then:
git add index.txt && git rebase --continue
# 5) Tag release
git switch main && git merge --no-ff feature/greet -m "merge feature"
git tag -a v0.1.0 -m "first"
16) Fast FAQ
- Pull vs Fetch?
fetch
updates remote refs;pull
=fetch
+ integrate (merge/rebase). - When to merge vs rebase? Rebase personal branches; merge long-lived/shared.
- Undo last commit but keep changes?
git reset --soft HEAD~1
. - Accidentally deleted a branch? Use
git reflog
to find commit, thengit branch <name> <sha>
. - Rename branch?
git branch -m new-name
(thengit push origin :old && git push -u origin new
).
17) Commit Message Template (copy/paste)
<type>(optional scope): <subject in imperative>
[optional body: what & why]
[optional footer: Fixes #123 | BREAKING CHANGE: ...]
Types: feat
, fix
, docs
, style
, refactor
, perf
, test
, build
, ci
, chore
.
18) Interview Questions (Practice)
What’s the difference between Git and GitHub?
A: Git is a version control system (local tool); GitHub is a remote hosting service for Git repositories.
Explain
git fetch
vsgit pull
A:
fetch
downloads new data (commits, branches) without merging;pull
doesfetch
+ integrates changes into your current branch.
What does
git rebase
do compared togit merge
?A:
merge
combines histories and keeps all commits;rebase
moves your commits to start after the target branch, creating a linear history.
How do you recover a deleted branch?
A: Use
git reflog
to find the last commit hash, thengit branch <name> <commit-hash>
.
What’s the difference between
reset
,revert
, andcheckout
?A:
reset
moves the branch pointer,revert
creates a new commit undoing changes,checkout
switches branches or restores files.
What is
HEAD
and how does it move?A:
HEAD
is a pointer to your current commit/branch. It moves with each commit or when you switch branches.
How do you resolve merge conflicts?
A: Edit conflict markers in files, choose correct content,
git add
the fixed files, thengit merge --continue
orgit rebase --continue
.
How do you squash commits before merging?
A:
git rebase -i origin/main
→ mark extra commits assquash
→ save and update commit message.
What’s a detached HEAD state?
A: When
HEAD
points to a specific commit instead of a branch, meaning new commits won’t belong to any branch until you create one.
Why use feature branches and pull requests?
A: To isolate changes, enable code review, prevent breaking
main
, and maintain clean history.
19) Next Steps
- Add a pre-commit hook (lint/tests) with Husky or pre-commit.
- Protect
main
, require PR reviews + passing CI. - Learn one advanced tool next:
bisect
,worktree
, orsubmodule
(only if needed).
Bonus: Quick Conflict Checklist
- Pull/rebase first, commit often, push early.
- Keep PRs small (≤ ~200 lines changed).
- Communicate intent in the PR description.