Git — Cheat Sheet

Tags: git, vcs, branching, rebase, merge, devops, workflow

Level: intermediate

TL;DR: Distributed version control fundamentals, branching strategies, rebase vs merge trade-offs, and critical recovery commands.

Key concepts

Git stores snapshots of the project state, not file differences.

Working directory, staging area (index), and repository form the core workflow triad.

A commit is an immutable cryptographic hash pointing to a tree object and parent commits.

A branch is simply a movable lightweight pointer to a specific commit.

HEAD indicates the current branch or commit currently checked out.

Merge creates an explicit merge commit preserving full branch history.

Rebase reapplies commits on top of another base, creating a linear history.

Fast-forward merge moves the pointer directly forward when no divergent commits exist.

Git reflog tracks every update to local references, enabling recovery of lost commits.

Cherry-pick applies changes introduced by specific individual commits onto the current branch.

Typical questions and ready answers

Q: What is the difference between git merge and git rebase?R: Merge creates a merge commit preserving historical topology. Rebase rewrites history linearly by reapplying commits onto the new base tip.

Q: What is a detached HEAD state and how do you resolve it?R: HEAD points directly to a commit rather than a branch. I resolve it by creating a new branch to keep changes or checking out main.

Q: How do you undo a commit that has already been pushed to a shared remote?R: I use git revert <commit-hash> to create a new commit that inverts the changes safely without rewriting shared history.

Q: What is the difference between git reset --soft, --mixed, and --hard?R: Soft moves HEAD only; mixed resets HEAD and staging area; hard wipes HEAD, staging area, and working directory changes completely.

Q: How do you resolve a merge conflict?R: I inspect conflicted files, edit markers manually or with a mergetool, run git add, and finalize with commit or rebase continue.

Pitfalls and common mistakes

Running git push --force on shared branches overwrites teammates' commits.

Using git reset --hard without verifying uncommitted work permanently deletes unstaged files.

Stashing untracked files without -u flag leaves newly created files behind.

Modifying commits already published to remote branches with git commit --amend.

Rebasing long-running public branches introduces massive conflict loops for the team.

Snippets and commands

# Branching and switching
git checkout -b feature/auth
git switch -c feature/auth

# Inspecting history and reflog
git log --oneline --graph --decorate --all
git reflog

# Stashing work
git stash push -u -m "wip auth token"
git stash pop

# Linear history and rebasing
git fetch origin
git rebase origin/main
git rebase -i HEAD~3

# Undoing and resetting
git reset --soft HEAD~1
git reset --hard HEAD~1
git revert <commit-hash>

# Cleaning untracked artifacts
git clean -fd

To review

[ ] Interactive rebase commands (squash, fixup, edit, drop)

[ ] Safe force push with --force-with-lease

[ ] Submodules versus subtree workflows

[x] Three-way merge fundamentals

[x] Stash lifecycle and management

References

Pro Git Book (Scott Chacon and Ben Straub)

Official Git Documentation (git-scm.com)