Git is a version control system. It records snapshots of your project over time, so you can see what changed, go back, and work on several things at once without them interfering.
Every developer has a complete copy of the history. You can commit, branch and search history with no network at all.
git init # start tracking a project here
git clone https://github.com/u/r.git # copy an existing one
# Set your identity once, globally — commits are stamped with it
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git status # WHAT STATE AM I IN? Run this constantly
git diff # unstaged changes
git diff --staged # what's staged, i.e. what will be committed
git add file.js # stage one file
git add . # stage everything changed here
git commit -m "Fix login redirect"
git pull # get others' work
git push # publish yours
git status is the most useful command in Git. It tells you which of the four places your changes are in, and usually suggests the command you want next.
git switch -c feature/login # create a branch and move to it
git switch main # move back
git branch # list local branches
git branch -d feature/login # delete a merged branch
git switch is the modern command for changing branches. git checkout still works but does several unrelated jobs, which is why it confused people for a decade — switch (branches) and restore (files) split it up.
Both bring another branch's work into yours. They produce different history.
MERGE — keeps what actually happened
main A───B───────────M M is a merge commit with two parents
\ /
feature C───D───┘
REBASE — replays your commits on top, as if written later
main A───B
\
feature C'──D' C and D are NEW commits (different hashes)
Merge
Rebase
History
Truthful, shows the branch
Linear, easier to read
Commit hashes
Unchanged
Rewritten
Safe on shared branches
Yes
No
git switch main && git merge feature/login # merge
git switch feature/login && git rebase main # rebase onto latest main
You are mid-change and need to switch branches urgently:
git stash # put changes aside, clean the working directory
git stash list # see what you stashed
git stash pop # bring the most recent back and remove it from the stash
git stash apply # bring it back but KEEP it in the stash
git log --oneline --graph --decorate -20 # compact visual history
git log -p file.js # how one file changed over time
git log --author="Ahmed"
git blame file.js # who last changed each line, and when
git show <hash> # everything about one commit
.gitignore — never commit generated files, dependencies or secrets:
.gitignore
node_modules/
dist/
.env
*.log
.DS_Store
.gitattributes — normalise line endings across Windows/Linux teams:
.gitattributes
* text=auto
*.sh text eol=lf
Without the second one, a shell script committed on Windows gets CRLF line endings and fails on Linux with \r: command not found — an error that names the wrong problem entirely.
Explain the difference between git reset, git revert, and git checkout.
They operate on different things, which is the real answer:
Command
Moves / changes
Rewrites history?
Use when
git reset
the branch pointer
Yes
The commits are local only
git revert
creates a new commit
No
The commits are already pushed
git checkout / restore
files in your working tree
No
You want to discard edits, or inspect an old version
before: A ─── B ─── C ← main, HEAD
git reset --hard B → A ─── B ← main, HEAD
(C is orphaned — findable via reflog)
git revert C → A ─── B ─── C ─── C' ← main
(C' undoes C; both remain in history)
A secret was committed and pushed two weeks ago. What do you do, in order?
Rotate the secret first. Everything else is second.
The order matters and getting it wrong is the failed answer:
Revoke and reissue the credential. It is in the remote, in every clone, in forks, in CI logs, and possibly in a mirror or backup. Assume it is compromised — because it is.
Remove it from the code so the new secret does not follow it in, and move it to a secret manager or an environment variable.
Then, optionally, purge history with git filter-repo (or BFG) and coordinate a force-push, because every collaborator must re-clone.
Add a guardrail so it cannot recur: a pre-commit hook or CI scanning step (gitleaks, trufflehog), plus branch protection.
How do you find which commit introduced a bug in a 2,000-commit history?
git bisect — a binary search over history. It finds the culprit in about 11 steps for 2,000 commits, instead of 2,000.
git bisect start
git bisect bad # the current commit is broken
git bisect good v1.4.0 # this tag was known good
# Git checks out the midpoint. Test it, then tell Git:
git bisect good # or: git bisect bad
# repeat — Git halves the range each time
git bisect reset # return to where you started
And if the test can be scripted, do not do it by hand at all:
# Any non-zero exit means "bad". Git runs it on each candidate.
git bisect start HEAD v1.4.0
git bisect run npm test