103 Git Interview Questions and Answers (2026)

Git manages your content across three "trees": the working directory (files you edit), the staging area / index (a snapshot of what will go into the next commit), and the repository (committed history). Changes flow: working directory → index → repository.

• Working Directory: The actual files on disk that you view and modify: a single checked-out version of the project.

• Staging Area (Index):

  • A middle layer holding a proposed next snapshot; git add moves changes here.

  • Lets you compose a commit selectively rather than committing everything.

• Repository (.git): The committed history of immutable snapshots; git commit writes the staged snapshot here permanently.

• How they relate to commands: git status compares all three; git diff shows working vs index, git diff --staged shows index vs repo.

The .git directory is the repository itself: it stores all commits, objects, branches, refs, config, and history. Deleting it turns your project back into an ordinary set of files with no version history at all.

• What it contains:

  • objects/: all commits, trees, and blobs (the actual content).

  • refs/ and HEAD: branches, tags, and the current checkout pointer.

  • config, index, and hooks: repo settings, the staging area, and automation scripts.

• If you delete it:

  • Your working files remain, but all history, branches, stashes, and staged state are gone locally.

  • The folder is no longer a Git repo (git status errors out).

  • If a remote (e.g. GitHub) still has the history, you can re-clone to recover it; otherwise the history is lost.

Both are config files but solve different problems: .gitignore tells Git which untracked files to not track, while .gitattributes tells Git how to handle files it does track (line endings, diff, merge, filters).

• .gitignore:

  • Lists patterns for files/dirs Git should ignore: build output, node_modules/, logs, secrets.

  • Only affects untracked files: already-tracked files are not ignored.

• .gitattributes:

  • Assigns behavior per path: text=auto for line-ending normalization, binary to disable diff/merge.

  • Configures diff/merge drivers, export-ignore for archives, and filters like Git LFS.

• In short: .gitignore controls presence in the repo; .gitattributes controls treatment within the repo.

The staging area exists to give you explicit control over what goes into each commit, separating the act of changing files from the act of committing a curated snapshot of them.

• Craft focused commits: You can stage only some of your changes (even parts of a file via git add -p) to make each commit logical and reviewable.

• Review before committing: git diff --staged lets you inspect exactly what will be committed, catching stray debug code or secrets.

• Build a snapshot incrementally: You can stage files as you finish them and commit the coherent set later.

• Alternative if you don't want it: git commit -a stages and commits all tracked changes in one step, bypassing manual staging.

Version control records the history of changes to a codebase so a team can collaborate safely, track who changed what and why, and recover any previous state. It solves the core problems of coordination, traceability, and reversibility.

• History and traceability: Every change is a commit with author, timestamp, and message, so you can answer "who changed this and why" (git blame, git log).

• Reversibility: You can revert to any prior state, undo mistakes, and find when a bug was introduced (git bisect).

• Parallel collaboration: Branches let many people work independently and merge their work, instead of overwriting each other.

• Single source of truth and backup: A shared remote gives everyone a consistent, recoverable copy of the project.

• Enables workflow and review: Pull requests, code review, and CI all build on version-controlled history.

The distinction is about whether Git knows and watches a file: tracked files are already in Git's index/history, untracked files exist in the working directory but Git isn't watching them yet, and ignored files are untracked files Git is explicitly told to skip.

• Tracked: Files Git already knows about (previously committed or staged); Git reports them as modified, staged, or unchanged.

• Untracked:

  • New files present on disk that have never been added; git status lists them under "Untracked files."

  • Becomes tracked once you run git add.

• Ignored:

  • Untracked files matching a pattern in .gitignore; Git hides them from status and won't auto-stage them.

  • Caveat: ignoring does not affect files already tracked; you must git rm --cached them first.

A lightweight tag is just a name pointing straight at a commit, like a branch that never moves. An annotated tag is a full object storing metadata (message, tagger, date) and can be GPG-signed. Use annotated tags for releases; lightweight tags for private, temporary bookmarks.

• Lightweight tag:

  • Created with git tag <name> (no -a/-m).

  • Just a ref pointing to a commit: no author, date, or message.

• Annotated tag:

  • Created with git tag -a v1.0 -m "..." (or -s to sign).

  • Creates a tag object with tagger, timestamp, message, and optional signature.

• When to use each:

  • Annotated: public releases: they carry provenance and are what git describe prefers by default.

  • Lightweight: throwaway local markers you don't need to audit.

Tags live in their own refs/tags/ namespace and a normal git push only updates branch refs, so you must push tags explicitly. This is deliberate: tags are permanent labels and Git avoids publishing them without your intent.

• Push a single tag: git push origin v1.0 sends just that tag.

• Push all tags:

  • git push origin --tags pushes every local tag (lightweight and annotated).

  • git push --follow-tags pushes commits plus only reachable annotated tags: cleaner for releases.

• Why not automatic:

  • push moves the current branch's commits; tags are a separate namespace, not carried along.

  • Tags are meant to be immutable and shared intentionally: silently publishing every local tag would pollute the remote.

• Deleting a remote tag: git push origin --delete v1.0 (or git push origin :refs/tags/v1.0).

git grep searches the content of files tracked by Git, using Git's index and object database rather than scanning the filesystem. It's faster and more precise than a generic search because it knows exactly which files are versioned and can search any commit or tree, not just the working tree.

• Searches tracked content only: Ignores untracked files, build artifacts, and anything in .gitignore, so no noise from node_modules or .git.

• Can search history, not just the disk:

  • git grep "foo" <commit> searches any commit or tree by reading objects directly.

  • A tool like grep -r can only see the current working directory.

• Fast and Git-aware: Uses the index and multiple threads, so it's typically quicker than recursive filesystem grep on a repo.

• Handy options: -n show line numbers, -i case-insensitive, -l list only filenames, -e for patterns and --and/--or to combine them.

A standard commit creates a brand-new commit on top of the current tip; git commit --amend replaces the most recent commit with a new one, letting you fix its message or contents without adding a separate commit.

• Standard commit: Adds a new commit whose parent is the current HEAD; history grows by one.

• Amend rewrites HEAD:

  • Combines the staged changes with the previous commit's content and produces a new commit object with a new SHA (the old one is discarded).

  • Common uses: fix a typo in the message, or add a forgotten file to the last commit.

• It rewrites history: Since the SHA changes, never amend a commit already pushed and shared, or you force others to reconcile a diverged history (needs --force-with-lease).

• Message-only amend: Run git commit --amend with nothing staged to edit just the message.

A good commit message concisely states what changed and why in a short summary line, followed by an optional body giving context. Git separates the two by convention (a blank line between them) so tools can treat the first line as a standalone title.

• Summary line:

  • ~50 characters, imperative mood ("Fix login redirect", not "Fixed"), no trailing period.

  • It should describe the intent, not just the mechanics.

• Body: Explains the why and the context (trade-offs, background) that the diff can't; wrap around 72 chars.

• Why the blank-line separation matters:

  • Many tools show only the first line: git log --oneline, git shortlog, GitHub PR titles, and email subjects.

  • Without the blank line, Git can't tell where the title ends, so the whole message collapses into one paragraph.

• Why it matters overall: History is read far more than it is written: clear messages speed up git blame, git bisect, and code review.

git fetch downloads new commits and updates remote-tracking branches but never touches your working files; git pull fetches and then immediately merges (or rebases) those changes into your current branch.

• git fetch is read-only to your work:

  • Updates refs like origin/main so you can inspect incoming changes before integrating them.

  • Your local branch and working tree stay exactly as they were.

• git pull combines two steps: It is essentially git fetch followed by git merge (or git rebase with --rebase).

• Why 'shortcut':

  • It collapses fetch + integrate into one command, which is convenient but can trigger surprise merges or conflicts.

  • Prefer explicit fetch then review when you want control; use pull for a quick update of a clean branch.

git clone creates a new local repository, downloads the full object database from the remote, sets up an origin remote, and checks out a working copy of the default branch.

• Initialize and connect: Creates a .git directory and registers the source URL as the remote named origin.

• Transfer objects: Fetches all commits, trees, blobs, and tags (usually as a packfile) into .git/objects.

• Set up refs: Creates remote-tracking branches under origin/* and a local branch tracking the remote's default (HEAD).

• Check out: Populates the working directory from the checked-out branch and writes the index.

git push -u (short for --set-upstream) pushes the branch and records a tracking link between your local branch and the remote branch, so future git push and git pull need no arguments.

• What it sets:

  • Configures the branch's upstream (tracking) reference, e.g. origin/feature.

  • Stored in .git/config under the branch's remote and merge keys.

• Effect on later commands:

  • Bare git push and git pull now know the target automatically.

  • git status can report ahead/behind counts vs the upstream.

• You only need -u once per branch; after that the link persists.

A merge conflict occurs when Git cannot automatically reconcile changes from two branches because they modified the same region of a file in incompatible ways. Git detects this during its three-way merge by comparing each side against the common ancestor line by line (hunk by hunk).

• How Git decides:

  • For each changed region it compares the merge base to ours and theirs.

  • If only one side changed a region, that change is taken automatically.

  • If both sides changed the same region differently, Git can't choose and marks a conflict.

• What you see: Conflict markers <<<<<<<, =======, >>>>>>> wrap the competing versions in the file.

• Beyond simple text overlaps:

  • Conflicts also arise from add/add, delete/modify, or rename collisions, not just overlapping edits.

  • Git is line-based, so it won't flag semantic conflicts (code that merges cleanly but breaks logically).

A fast-forward merge is when Git advances the current branch pointer directly to the tip of the branch being merged, because no divergent commits exist. It just moves the ref forward with no new merge commit, keeping history linear.

• The condition: The current branch's tip must be a direct ancestor of the target commit: the feature branch is simply ahead.

• What happens: No merge commit is created; the branch label slides forward to the newer commit.

• When it's not possible: If the base branch also received commits since the branch diverged, histories have branched and Git must create a merge commit instead.

• Enforcing behavior: Use git merge --ff-only to abort rather than create a merge commit when a fast-forward isn't available.

Conceptually, resolving a conflict means you (the human) make the decision Git couldn't: for each conflicted region you choose ours, theirs, or a hand-crafted combination, then tell Git the conflict is settled and complete the merge.

• Understand the three inputs: The common ancestor (base), your version (ours), and the incoming version (theirs): compare against the base to see each side's intent.

• Edit to the correct final state: Remove the <<<<<<</=======/>>>>>>> markers and leave the code as it should actually be, not just picking one side blindly.

• Mark as resolved and finish: git add the file to stage the resolution, then git commit (or git merge --continue).

• Escape hatches: git merge --abort returns to the pre-merge state; a mergetool or --conflict=diff3 showing the base helps for tricky cases.

• Then verify: Build and test: Git resolves text, not correctness.

Both reapply stashed changes to your working tree, but pop also deletes the stash entry afterward, while apply leaves it in the stash list.

• git stash pop:

  • Applies then drops the stash (only if the apply succeeds cleanly).

  • Convenient one-shot restore when you're done with the stash.

• git stash apply: Applies but keeps the entry, so you can reuse it (e.g. apply the same stash to multiple branches).

• When to choose which:

  • Prefer apply when the reapply might conflict; the stash stays safe until you're sure, then git stash drop manually.

  • Note: on a conflict, pop does not drop the stash, so you won't lose it.

git blame annotates each line of a file with the commit, author, and date that last modified it, answering "who changed this line and when (and in which commit)?"

• What it shows:

  • For every line: the short commit hash, author, timestamp, and the line content.

  • It reports the last commit that touched each line, not the full history of that line.

• What question it answers:

  • Great for context/archaeology: find the commit behind a suspicious line, then read its message or git show to learn why.

  • It's an investigative tool, not a blame-assignment tool despite the name.

• Useful options:

  • -L 10,20 limits output to a line range.

  • -w ignores whitespace changes; -C and -M detect lines moved or copied across files so a reformat doesn't hide the real author.

• Follow-up: to see how a line evolved over time, pair blame with git log -L or the interactive git gui blame.

git log becomes powerful once you combine filters (which commits) with formatting (how they display), letting you narrow history to exactly what you're investigating.

• Filter which commits appear:

  • By time: --since, --until (e.g. --since="2 weeks ago").

  • By author or message: --author="Ana", --grep="fix".

  • By file or path: git log -- path/to/file.

  • By content change: -S"string" (pickaxe) finds commits that added/removed that string; -p shows the actual diffs.

• Format how they display:

  • --oneline for a compact one-line-per-commit view.

  • --graph draws the branch/merge topology as ASCII.

  • --pretty=format:... builds a custom line with placeholders like %h (hash), %an (author), %ar (relative date), %s (subject).

• Combine them: filters and format flags stack in one command, which is what makes git log a real inspection tool.

Git config exists at three scopes (system, global, local) that layer on top of each other, with the most specific scope winning. This lets machine-wide defaults be overridden per-user and then per-repository.

• System (--system): Applies to every user on the machine; stored in something like /etc/gitconfig.

• Global (--global): Per-user settings in ~/.gitconfig; the usual place for name, email, aliases.

• Local (--local): Per-repository in .git/config; the default when you run git config inside a repo.

• Override order:

  • local beats global beats system (nearest scope wins).

  • Use git config --list --show-origin to see effective values and where each came from.

A Git alias is a shortcut you define for a longer Git command (or combination of commands), saving typing and standardizing complex workflows. They're stored in config under the [alias] section.

• How they work: Set with git config --global alias.<name> <command>, then invoke as git <name>.

• Why use them:

  • Shorten frequent commands (co for checkout).

  • Encapsulate complex flags you'd never remember (a pretty log format).

• Shell escape: Prefix with ! to run an external shell command instead of a Git subcommand.

Git is a distributed VCS: every clone is a full copy of the entire repository including complete history, whereas SVN/Perforce are centralized, keeping history on one server that clients must contact for most operations. That local full copy is exactly why Git works offline.

• Centralized (SVN, Perforce):

  • A single server holds the authoritative history; clients usually check out just a working copy.

  • Committing, viewing log, diffing older revisions typically require a network round-trip.

  • Server outage blocks most work; it's a single point of failure.

• Distributed (Git):

  • git clone copies the whole object database, so every developer has a complete repository.

  • Commits, branches, diffs, log, and merges are all local and fast.

• Why offline works: Because history lives locally, you only need the network for push/fetch/pull to synchronize with others.

A detached HEAD means HEAD points directly at a commit instead of at a branch reference. You still have a valid working state, but new commits aren't attached to any branch, so they can be lost once you move away.

• Normally HEAD is symbolic: It points to a branch (e.g. ref: refs/heads/main), and that branch points to the tip commit.

• Detached means HEAD holds a raw SHA: Commits you make advance HEAD but no branch moves, so they're only reachable by their SHA.

• How you get there: Checking out a commit, tag, or remote-tracking ref directly: git checkout <sha>, git checkout v1.0, or git checkout origin/main.

• How to fix it:

  1. To keep new work: git switch -c newbranch (or git checkout -b) to save the commits onto a branch.

  2. To just leave without saving: git switch main to reattach to a branch.

  3. If you already left and lost commits: recover the SHA via git reflog and branch from it.

Detached HEAD is not an error: it's the right mode for inspecting or bisecting old states. It only bites you if you commit and walk away.

A branch is just a lightweight, movable pointer: a file under refs/heads/ containing a single commit SHA. A tag is a pointer too, but it's meant to be permanent and stationary, and it can also be a real Git object rather than a bare reference.

• A branch is a moving ref:

  • Stored as a 40-char SHA in .git/refs/heads/<name> (or packed-refs).

  • It advances automatically: committing on it rewrites that file to the new tip.

• A tag is a fixed ref:

  • Stored under refs/tags/<name>; Git never moves it as you commit.

  • Intended as a permanent label (e.g. a release point).

• Key structural difference: A branch is only a pointer. An annotated tag additionally creates a tag object in the object database holding a message, tagger, and date.

• HEAD ties into branches: HEAD usually points at a branch so it can follow new commits: nothing points to tags that way.

An annotated tag object is one of Git's four object types (alongside blob, tree, and commit). It's a small immutable object stored in the object database that wraps a target object plus metadata, and it's addressed by its own SHA.

• What it contains:

  • The SHA and type of the object it points to (usually a commit).

  • The tag name, tagger identity, timestamp, message, and optional GPG signature.

• How it differs from the others:

  • A blob stores file content; a tree stores directory structure; a commit stores a snapshot plus parents.

  • A tag object simply references and annotates another object, adding no file data.

• Two-hop resolution:

  • The ref refs/tags/v1.0 points to the tag object, which in turn points to the commit: a lightweight tag skips this and points straight at the commit.

  • Inspect it with git cat-file -p v1.0.

git describe produces a readable, version-like name for a commit by finding the nearest tag reachable from it and showing how far away it is. It's commonly used to stamp builds with a human-friendly version derived from Git history.

• What it outputs:

  • Exactly on a tag: just the tag name, e.g. v1.2.0.

  • Past a tag: v1.2.0-14-g2b1d3c4 meaning 14 commits after v1.2.0, at abbreviated SHA 2b1d3c4 (the g marks a Git hash).

• How it derives the name:

  • Walks backward through the commit's ancestry to the closest annotated tag.

  • Counts commits between that tag and the target for the -N-g suffix.

• Useful options:

  • git describe --tags: also consider lightweight tags.

  • git describe --dirty: append -dirty if the working tree has uncommitted changes.

  • git describe --always: fall back to a bare SHA when no tag is found.

Tags mark a release as a fixed, immutable point in history, while branches are moving pointers meant for ongoing work. For an exact, reproducible release marker use a tag; use a branch when the release line needs continued maintenance like backports and patches.

• Tags for releases:

  • Immutable label: v2.1.0 always points at the exact shipped commit.

  • Annotated/signed tags carry metadata and provenance for auditing.

  • Downside: you can't commit onto a tag: it's a dead point, not a place to add fixes.

• Branches for releases:

  • A release branch (e.g. release/2.1) lets you land hotfixes and cut 2.1.1, 2.1.2.

  • Downside: it moves, so it doesn't by itself identify a single shipped version.

• Common practice: Use both: a maintenance branch for the release line, and a tag on each exact published version.

Every commit stores two identities: the Author is who originally wrote the change, and the Committer is who last created/applied the commit object. They are usually the same person but diverge during rebases, cherry-picks, or patches applied on someone's behalf.

• Author: Original writer of the content, with their own timestamp (GIT_AUTHOR_DATE). Preserved when the commit is moved around.

• Committer: Whoever produced the current commit object, with the GIT_COMMITTER_DATE. Updated whenever the commit is recreated.

• When they differ:

  • A rebase keeps the original author but sets you as the new committer, since a new commit object is made.

  • Applying a mailing-list patch: the contributor is the author, the maintainer is the committer.

• Visibility: git log shows the author by default; use git log --format=fuller to see both.

Both inspect changes across Git's three areas (working directory, staging index, and the last commit/HEAD), but git status gives a high-level summary of which files changed where, while git diff shows the exact line-level content changes.

• git status: Lists files that are staged, unstaged, or untracked: the "what and where," not the content.

• git diff (no args): Working directory vs index: changes you have not staged yet.

• git diff --staged (or --cached): Index vs HEAD: changes that are staged and will go into the next commit.

• git diff HEAD: Working directory vs last commit: staged and unstaged changes combined.

• Mental model: status answers "which files?"; diff answers "which lines?" and lets you pick the pair of areas to compare.

A signed commit or tag carries a cryptographic signature (GPG or SSH key) proving who created it, which Git can verify. Teams require signing to guarantee authenticity and integrity: that a commit really came from the claimed person and was not forged or tampered with.

• How it works:

  • git commit -S and git tag -s attach a signature over the commit/tag content using your private key.

  • Verify with git verify-commit / git verify-tag, or see status in git log --show-signature.

• Why authorship alone is not enough: The author/committer name and email are just plain text anyone can set, so they are trivial to spoof; a signature can't be forged without the private key.

• Why teams require it:

  • Supply-chain security and compliance: prove releases (tags) and commits are trusted before they ship.

  • Platforms like GitHub show a "Verified" badge and can enforce signing via branch protection.

• Auto-sign: Set commit.gpgsign true to sign every commit automatically.

An empty commit records a commit with no file changes, created with git commit --allow-empty. It is useful whenever you want a marker or a trigger in history without altering any content.

• How to create it: git commit --allow-empty -m "message" bypasses the normal "nothing to commit" guard.

• Common uses:

  • Trigger CI/CD pipelines or a redeploy without a code change.

  • Mark a milestone or annotate history (e.g. "start of release branch").

  • Open a pull request early before any code exists to start discussion.

• Related: git commit --allow-empty-message is the separate flag for a commit with content but no message.

The index (staging area) is a separate layer between your working directory and the repository, so you decide exactly what goes into the next commit. Because staging is independent of your edits, you can stage only some changes (even individual lines) and leave the rest for a later commit, keeping each commit focused.

• The index is a staging snapshot: git add copies a change into the index; the commit is built from the index, not directly from your files.

• Partial staging with git add -p:

  • Git splits your changes into "hunks" and asks about each one, so you stage some and skip others.

  • Key prompts: y stage this hunk, n skip it, s split into smaller hunks, e edit the hunk line by line.

• Why it is useful:

  • Separate unrelated changes made in one file into distinct, atomic commits.

  • Leave debug/experimental lines unstaged while committing the real fix.

• Verify before committing: git diff --staged shows exactly what you selected.

Both integrate changes from one branch into another, but merge preserves history by creating a merge commit that ties two lines together, while rebase rewrites your commits to replay them on top of the target branch, producing a linear history.

• git merge:

  • Creates a merge commit with two parents (unless a fast-forward is possible); keeps the true, non-linear history.

  • Non-destructive: existing commits and their SHAs are untouched.

• git rebase:

  • Reapplies your commits one by one onto the tip of the base branch, giving each a new SHA.

  • Result is a clean, linear history with no merge commits.

• When to choose merge: Integrating a completed feature into a shared branch, or any branch others have pulled: you want the real history preserved.

• When to choose rebase: Cleaning up your local, unpublished commits before sharing (e.g. git rebase -i), or updating a feature branch onto the latest main.

• The golden rule: Never rebase commits that have been pushed and shared, since rewriting their SHAs forces everyone else's history to diverge.

The Golden Rule of rebasing is: never rebase commits that have been pushed to a shared branch that others rely on. Rebase only your own local, unpublished work.

• Why the rule exists:

  • Rebase rewrites history: it creates new commits with new hashes, and the old ones are abandoned.

  • Anyone who already pulled the old commits now has a divergent history.

• What happens if you break it:

  • You force-push (git push --force) rewritten history over the shared branch.

  • Collaborators' next pull sees duplicated commits and messy merges; they may re-introduce the discarded commits.

  • Work can be lost if someone's push overwrites the rewrite (or vice versa).

• Safe practice:

  • Rebase private feature branches before sharing; use merge for integrating shared history.

  • If you must force-push a shared branch, prefer --force-with-lease and coordinate with the team.

git cherry-pick takes one (or a few) specific commits and re-applies them as brand-new commits on your current branch. It is better than a merge when you want just a single commit, not an entire branch's history.

• How it works:

  • It computes the diff a commit introduced and applies that patch to your current HEAD.

  • A new commit is created with a new hash (same content/message, different parent).

  • Conflicts are resolved like any patch application.

• When it beats a merge:

  • Hotfix backport: apply one bug-fix commit to a release branch without pulling in unrelated feature work.

  • You need one commit from a branch that isn't ready to merge as a whole.

  • Recovering a specific commit from an abandoned branch.

• Caveat: It duplicates content across branches, which can cause redundant changes when those branches are later merged.

An interactive rebase (git rebase -i) lets you rewrite a series of commits by editing, reordering, dropping, or combining them via a to-do list. Both squash and fixup combine a commit into the one above it; the difference is what happens to the commit message.

• What interactive rebase does:

  • Opens an editor listing commits with actions: pick, reword, edit, squash, fixup, drop.

  • Used to clean up local history before sharing: tidy messages, remove WIP noise, logically group changes.

• squash:

  • Merges the commit into the previous one and opens an editor to combine both commit messages.

  • Use when both messages have content worth keeping.

• fixup:

  • Merges the commit into the previous one but discards this commit's message.

  • Use for small corrections (a typo, a missed file) that don't deserve their own message.

During a rebase, the replayed commits get brand-new hashes: rebase does not move existing commits, it creates new ones. The originals are orphaned (still recoverable via reflog until garbage-collected).

• Why hashes change:

  • A commit's hash is derived from its content, including its parent hash and metadata.

  • Rebasing changes the parent (the new base), so every replayed commit downstream gets a new hash even if its diff is unchanged.

• Practical consequences:

  • The old commits become unreachable but linger in the reflog, so a botched rebase can be undone.

  • Because hashes changed, sharing rebased commits requires a force-push (hence the Golden Rule).

• Recovery: Use git reflog to find the pre-rebase HEAD and git reset --hard back to it.

--force overwrites the remote branch unconditionally, while --force-with-lease only overwrites if the remote is still where you last saw it, protecting teammates' commits you didn't know about.

• git push --force: Replaces the remote branch with your local version no matter what, silently discarding any commits others pushed since.

• git push --force-with-lease:

  • Checks that the remote-tracking ref matches your local origin/branch; if someone pushed new work, the push is rejected.

  • Acts like an optimistic lock: it fails safely rather than destroying data.

• Why the latter is preferred:

  • Common after a rebase or amend where you must rewrite history but still want to avoid clobbering colleagues.

  • Caveat: run git fetch first so your lease reflects reality, otherwise it can give false confidence.

A remote-tracking branch like origin/main is a local read-only snapshot of where a branch was on the remote the last time you communicated with it; it is not a branch you commit to.

• It is a bookmark, not a workspace: Git updates origin/main only during fetch, pull, or push; you cannot check it out and commit directly.

• Your local main is editable: It moves forward as you commit and can diverge from origin/main until you push or fetch.

• Why it matters: The gap between main and origin/main is what messages like 'ahead 2, behind 1' describe.

They describe the same relationship from two angles: a tracking branch is your local branch that follows something, and the upstream is the specific remote branch it follows.

• Tracking branch: A local branch configured to have an upstream, e.g. local main tracking origin/main.

• Upstream branch: The target it follows: the remote-tracking ref that git pull and git push default to.

• How it is set:

  • Use git push -u origin main or git branch --set-upstream-to=origin/main.

  • Enables bare git pull/git push with no arguments and the 'ahead/behind' status.

You migrate cleanly by making a mirror clone, which copies every ref, then pushing that mirror to the new server so all branches and tags move intact.

• Steps:

  1. Clone with git clone --mirror <old-url> to get a bare copy of all refs.

  2. Set the new remote: git remote set-url --push origin <new-url> (or add a new remote).

  3. Push everything with git push --mirror <new-url>.

• Why --mirror: It transfers all branches, tags, and other refs exactly, unlike a normal clone which only sets up the default branch tracking.

Pruning removes stale remote-tracking refs for branches that no longer exist on the remote; they linger locally because fetch adds new refs but does not automatically delete ones the server removed.

• Why stale branches persist: When a teammate deletes origin/feature-x on the server, your local copy of that ref stays until told to clean up.

• How to prune:

  • Run git fetch --prune or git remote prune origin.

  • Set fetch.prune true to prune automatically on every fetch.

• Note: Pruning only affects remote-tracking refs, not your actual local branches.

Both are just remote names by convention, not Git keywords: origin is usually the repo you cloned (in a fork workflow, your personal fork you can push to), while upstream is the original source repo you sync from but usually can't push to.

• origin:

  • The default name given by git clone; points at the URL you cloned from.

  • In a fork workflow this is your own fork, which you have write access to.

• upstream:

  • A remote you add manually pointing at the canonical/original project.

  • You fetch from it to keep your fork current, but typically open PRs rather than push.

• Typical fork workflow:

  1. Fork on the host, then git clone your fork (becomes origin).

  2. Add the original: git remote add upstream <url>.

  3. Sync: git fetch upstream then rebase/merge upstream/main into your branch.

  4. Push your work to origin and open a PR against upstream.

git pull --rebase fetches remote commits and then replays your local commits on top of them, instead of creating a merge commit like the default git pull (which is fetch + merge).

• Default pull merges: When local and remote diverged, it produces a merge commit, cluttering history with noise.

• --rebase replays:

  • Your commits are re-applied after the fetched ones, yielding a clean linear history.

  • No extra merge commit for routine syncs.

• Why teams prefer it:

  • Readable, linear log that's easier to bisect and review.

  • Can be made the default with git config pull.rebase true.

• Caveats:

  • Rebasing rewrites your local commit SHAs, so only do it on commits you haven't shared.

  • Conflicts may need resolving per replayed commit rather than once.

All three move the current branch pointer (HEAD) to a target commit; they differ in how far the reset propagates into the staging area (index) and working directory.

• --soft:

  • Moves HEAD only; index and working directory untouched.

  • Changes from the undone commits stay staged, ready to recommit.

• --mixed (default):

  • Moves HEAD and resets the index, but leaves the working directory.

  • Changes remain on disk but become unstaged.

• --hard:

  • Moves HEAD, resets the index, and overwrites the working directory to match.

  • Discards uncommitted changes: destructive, use with care (though commits may still be found in the reflog).

• Mnemonic: --soft keeps everything staged, --mixed unstages, --hard throws it all away.

The reflog is a local, per-repo log of every place HEAD (and branch tips) has pointed, so it captures history that git log can't: even commits no longer reachable from any branch.

• reflog vs log:

  • git log shows the commit ancestry reachable from a ref.

  • git reflog shows movements of HEAD over time (commits, checkouts, resets, rebases), including dropped ones.

• Local and temporary: Not pushed or cloned; entries expire (default ~90 days).

• Recovering a deleted branch:

  1. Run git reflog to find the SHA where the branch tip last was.

  2. Recreate it: git branch <name> <sha>.

git reset operates on tracked content (moving HEAD, the index, and optionally tracked files), while git clean removes untracked files and directories that Git isn't following at all.

• git reset:

  • Affects tracked state: branch pointer, staged changes, and (with --hard) tracked working files.

  • Never touches untracked files.

• git clean:

  • Deletes untracked files; -d for directories, -x to also remove ignored files.

  • Use -n (dry run) first, then -f to force it.

• Complementary: For a truly pristine working tree, combine git reset --hard (tracked) with git clean -fd (untracked).

git reset rewrites history by moving the branch pointer backward, whereas git revert creates a new commit that undoes a previous one; git revert is safer for public/shared history because it doesn't rewrite existing commits.

• git reset:

  • Discards or relocates commits by moving HEAD; the original commits become unreachable.

  • On shared branches this forces others to reconcile diverged history (a force-push nightmare).

• git revert:

  • Adds a new commit with the inverse changes; history stays intact and append-only.

  • Safe to push normally: no rewriting, no forced updates.

• Rule of thumb: Use reset for local, unpublished cleanup; use revert to undo commits already shared with others.

First try to abort the operation in progress; if you've already completed it and want to undo it, use the reflog to reset HEAD back to exactly where it was before you started.

• While still in progress:

  • git merge --abort or git rebase --abort restores the pre-operation state cleanly.

  • Git tracks the original position via ORIG_HEAD during these operations.

• If already finished:

  • git reset --hard ORIG_HEAD jumps back to where HEAD was before the merge/rebase.

  • Or inspect git reflog and reset to the exact SHA from just before the operation.

• Caveat: --hard discards uncommitted work, so stash or commit anything you want to keep first.

A fast-forward merge just slides the branch pointer forward when no divergent work exists, creating no new commit; a three-way merge builds a new merge commit by combining two divergent lines using their common ancestor as the base. Git cannot fast-forward once both branches have commits the other lacks.

• Fast-forward:

  • Happens when the target branch tip is a direct ancestor of the branch being merged (linear history).

  • Git simply moves the branch ref to the newer commit: no merge commit, no new content.

• Three-way merge (recursive/ort):

  • Used when histories diverged: Git finds the merge base (common ancestor) and does a three-way compare of base, ours, and theirs.

  • ort is the modern default strategy (replacing recursive), producing a new merge commit with two parents.

• When fast-forward is impossible: When the current branch has commits not present in the branch you're merging: the histories have diverged, so a merge commit is required.

• Control it: --ff-only fails if it can't fast-forward; --no-ff forces a merge commit even when a fast-forward was possible.

git merge --no-ff forces a dedicated merge commit even when a fast-forward is possible. The trade-off is richer, explicit history versus a noisier, non-linear log.

• Benefits:

  • Preserves the fact that a feature branch existed: the merge commit groups its commits together.

  • Makes reverting a whole feature easy: revert the single merge commit.

  • The merge commit is a natural place for a review/PR reference and audit trail.

• Costs:

  • History becomes non-linear and busier with merge commits, making git log harder to read.

  • Empty merge commits add little value for tiny one-commit changes.

  • Bisecting and reading a clean linear story is easier without them.

• When to use it: Teams that value explicit branch topology and revertable features favor it; teams preferring linear history prefer fast-forward or rebase workflows.

Squash and merge collapses all commits from a feature branch into a single new commit on the target branch, discarding the individual intermediate commits. Teams use it to keep the mainline history clean and each merged change atomic.

• What it does:

  • git merge --squash stages the combined changes without committing or recording the branch's parentage; you then make one commit.

  • The result has no second parent, so it isn't a true merge commit.

• Why teams choose it:

  • One clean, logical commit per feature/PR makes main's history readable and easy to bisect.

  • Hides messy WIP commits ("fix typo", "wip") that add noise.

  • Reverting a feature is a single-commit revert.

• Trade-offs:

  • Loses granular history and authorship of individual commits.

  • The branch isn't recorded as merged, so it may show as unmerged and complicate future merges from the same branch.

Both integrate a branch, but --no-ff preserves the branch's full history under a single merge commit, while --squash collapses all the branch's changes into one new commit with no merge link.

• git merge --no-ff:

  • Forces a merge commit even when a fast-forward is possible, so the branch topology and all individual commits remain visible.

  • The merge commit has two parents, keeping a record that a feature branch existed.

• git merge --squash:

  • Stages the combined result of the branch but does not commit or create a merge parent; you commit manually, producing one flat commit.

  • Individual branch commits and the merge relationship are discarded.

• When to prefer each:

  • Use --no-ff when you value auditable, granular history and want to see feature boundaries (e.g. release tracking, reverting whole features).

  • Use --squash when you want a clean linear main history and the intermediate WIP commits add no value.

A three-way merge finds the merge base (the best common ancestor of the two commits) and compares each branch tip against it, so Git can tell which side actually changed a given region rather than blindly diffing the two tips.

• Finding the base:

  • Git walks back through the commit graph to locate the lowest common ancestor of both tips (git merge-base exposes this).

  • If several equally-good ancestors exist, recursive/ort merges them into one virtual base.

• Why the base is needed:

  • With three points (base, ours, theirs) Git distinguishes a change from the original from an unchanged region.

  • If only one side changed a hunk, that side wins automatically; if both changed the same hunk differently, it's a conflict.

• Contrast: a two-way diff can't know which side is authoritative, forcing conflicts on every difference.

When a merge conflicts, Git marks the conflicting regions and gives you several ways to resolve: edit the markers by hand, pick a whole side with --ours/--theirs, or launch a visual mergetool.

• Conflict markers: Git inserts <<<<<<<, =======, >>>>>>> so you can edit the final content directly, then git add.

• Choosing a whole side: git checkout --ours <file> or --theirs takes one version entirely (during a merge, "ours" is the current branch).

• Mergetool: git mergetool opens a configured 3-way GUI (e.g. meld, vimdiff) showing base, ours, and theirs.

• Helpers:

  • merge.conflictStyle=diff3 adds the original base to markers for context.

  • git merge --abort backs out entirely to start over.

A long-lived branch drifts from main as both sides change, so the eventual merge becomes larger, riskier, and full of conflicts that no longer reflect what either author had in mind.

• Merge conflict accumulation: The longer the branch lives, the more files both branches touch, so conflicts multiply and get harder to resolve correctly.

• Integration drift: Your code is written against an old state of main; APIs, schemas, or dependencies may have changed underneath you.

• Delayed feedback: Bugs and design mismatches surface only at merge time, when they are expensive to fix, instead of continuously.

• Large, unreviewable diffs: A weeks-long branch produces a huge pull request that reviewers rush through, lowering review quality.

• Mitigation: Regularly git merge or git rebase from main to keep the branch current, and prefer small, short-lived branches (continuous integration).

In a forking workflow each contributor works from their own server-side copy (fork) of the repository and proposes changes via pull requests; in a shared-repository workflow everyone pushes branches directly to one central repo.

• Forking workflow:

  • You fork the upstream repo, clone your fork, and push branches to your fork (origin), keeping the original as upstream.

  • Changes reach the project only through pull requests, so no contributor needs write access to the main repo.

  • Common in open source: it lets anyone contribute while maintainers control what merges.

• Shared-repository feature-branch workflow:

  • All developers have write access to one central repo and push feature branches directly to it.

  • Simpler and faster for a trusted team inside a company.

• Key difference: Trust and access boundary: forking isolates contributors behind their own repos; shared-repo trusts everyone with push rights to the same repo.

Pass pathspecs to stash a subset of files, use -u to include untracked files, and -a to include ignored files too.

• Stash specific files:

  • git stash push path/to/file stashes only the listed paths and leaves everything else in your working tree.

  • Add a message with -m for clarity: git stash push -m "wip" file.

• Include untracked files:

  • By default stash ignores untracked files; git stash -u (or --include-untracked) stashes them too.

  • git stash -a (--all) also includes files ignored by .gitignore.

• Interactive selection: git stash push -p lets you pick individual hunks to stash.

git bisect finds the commit that introduced a bug by binary search: you mark a known-good and known-bad commit, and it repeatedly checks out the midpoint for you to test, halving the search space each step.

• How the search works:

  • Start with git bisect start, then git bisect bad and git bisect good <commit>.

  • Git checks out the middle commit; you test and reply git bisect good or git bisect bad.

  • Each answer discards half the range, so it finds the culprit in about log2(N) steps.

• Automation:

  • git bisect run <script> runs a test script at each step (exit code decides good/bad) and finds the commit hands-free.

  • Finish with git bisect reset.

• History requirement:

  • Each commit should be individually buildable and testable, so the bug's presence gives a clean good/bad signal.

  • Small, atomic commits pinpoint the change precisely; giant or broken commits make the result useless.

git switch and git restore are newer, focused commands that split the two overloaded jobs of git checkout: switching branches versus restoring file contents.

• git checkout (the legacy all-in-one)

• placeholder

git rm --cached removes a file from Git's index (stops tracking it) while leaving the actual file on disk, so it stays in your working directory but is no longer version-controlled.

• What it does vs plain git rm:

  • git rm deletes the file from both the index and the working directory.

  • git rm --cached only untracks it: the next commit records its removal, but the file remains locally.

• When to use it:

  • You accidentally committed a file that should have been ignored (e.g. .env, node_modules, a build artifact) and want to stop tracking it without deleting it.

  • Pair it with a .gitignore entry so it doesn't get re-added.

• Caveats:

  • Use -r to untrack a directory recursively.

  • The file still exists in history; --cached doesn't purge past commits (use git filter-repo for that).

Git hooks are scripts that Git runs automatically at certain points in its lifecycle (before a commit, after receiving a push, etc.), letting you enforce policy or automate tasks. They live in .git/hooks and are triggered by name.

• Client-side hooks:

  • Run on the developer's machine around commits, merges, and pushes.

  • Example: pre-commit to run linters/tests or reject bad formatting before a commit is created.

• Server-side hooks:

  • Run on the remote repo when pushes arrive, ideal for enforcing team-wide rules.

  • Example: pre-receive to reject pushes that violate policy (bad commit messages, force-pushes to main).

• Key caveat: Client-side hooks are not cloned or pushed, so they aren't a security boundary; only server-side hooks can truly enforce rules.

A credential helper is a program Git uses to store and retrieve authentication credentials (passwords or tokens) so you aren't prompted on every remote operation. It solves the friction and insecurity of repeatedly typing credentials.

• The problem it solves: Without it, every push/fetch over HTTPS prompts for username and token.

• Common helpers:

  • cache: keeps credentials in memory for a short time.

  • store: writes them in plaintext to disk (convenient but insecure).

  • OS-integrated helpers (macOS Keychain, Windows manager) store them encrypted.

• Configuration: Set with git config --global credential.helper <helper>.

Git can normalize line endings so text files are stored consistently (LF) in the repository while checking out platform-appropriate endings, preventing spurious diffs when Windows (CRLF) and Unix (LF) developers collaborate. This is controlled by core.autocrlf and, more robustly, .gitattributes.

• The core idea: Best practice is LF in the repo; conversion happens on checkout/commit, not in storage.

• core.autocrlf (per-machine setting):

  • true: convert LF to CRLF on checkout, CRLF to LF on commit (typical Windows).

  • input: convert to LF on commit but leave checkout alone (typical Mac/Linux).

  • false: no conversion.

• .gitattributes (per-repo, committed):

  • Overrides per-machine settings and is shared with the whole team, so behavior is consistent everywhere.

  • e.g. * text=auto normalizes text, and *.png binary marks files to never be touched.

• Why prefer .gitattributes: It's version-controlled and explicit, avoiding the inconsistency of everyone configuring core.autocrlf differently.

Git stores everything as objects in a content-addressed key-value store, where the key is a hash of the content. There are four object types that together represent your history: blobs, trees, commits, and tags.

• Blob: Stores raw file content (no filename, no metadata).

• Tree: Represents a directory: maps names to blobs and other trees, along with file modes. This is where filenames live.

• Commit: Points to one root tree (a snapshot), plus parent commit(s), author/committer, and message.

• Tag (annotated): A named, permanent pointer to an object (usually a commit) with its own message and tagger metadata.

• How they connect:

  • commit → tree → subtrees/blobs forms an immutable snapshot; branches are just movable pointers to commits.

  • Inspect any object with git cat-file -p <hash>.

Git ensures integrity by hashing everything and chaining those hashes, so any corruption or tampering, whether accidental or malicious, changes a hash and is detectable. It's built on cryptographic hashing rather than trust in storage or transport.

• Content is checksummed: Every object is stored under a hash of its own contents, so a bit-flip yields a mismatched hash on read.

• History is a hash chain: A commit hash includes its tree and parent hashes, so altering any past object would break every descendant hash (Merkle DAG).

• Verification tools: git fsck validates object connectivity and checksums; transfers are checksummed too.

• Note on security: Hashing protects against corruption; for authenticity (who made the commit) you add signed commits/tags with GPG.

A commit object is a small text record that ties a snapshot of your project (a tree) to metadata and its parent history. It does not store file contents directly: it points to a single top-level tree.

• A tree reference: One line tree <sha> pointing to the root tree that represents the full snapshot at commit time.

• Parent reference(s): Zero for the first commit, one for a normal commit, two or more for a merge commit (parent <sha>).

• Author and committer: Name, email, and timestamp for each; author is who wrote it, committer is who applied it (they differ after rebase or cherry-pick).

• Commit message: Free-form text after a blank line.

• Optional GPG signature line if the commit is signed.

A blob stores the raw contents of a single file, while a tree stores directory structure: a list of names pointing to blobs and other trees. Blobs are the leaves, trees are the nodes.

• Blob (binary large object): Holds file content only, with no filename and no path: identical content anywhere in the repo is one shared blob.

• Tree:

  • Maps entries to objects, each entry recording mode (permissions), type, object SHA, and name.

  • A tree can reference other trees (subdirectories), forming the directory hierarchy.

• Key contrast: Filenames live in trees, not blobs, which is why renaming a file changes the tree but reuses the same blob.

Git stores full snapshots, not diffs. Every commit points to a complete tree describing the whole project state at that moment. Diffs are computed on demand when you ask to compare commits.

• Snapshot model: Each commit references a tree that represents every file, so history is a chain of complete snapshots.

• Deduplication keeps it cheap: Unchanged files reuse the exact same blob (same hash) across commits, so unchanged content is stored once, not copied.

• Deltas exist only for packing: Packfiles may store objects as deltas to save disk, but this is a storage optimization, not the logical model.

• Diffs are derived: git diff and blame compute differences between two snapshots at view time.

Because Git is a distributed, content-addressed system, IDs must be globally unique without any central coordinator and must verify integrity. A hash of the content achieves both; a sequential counter cannot work when many people commit independently offline.

• No central authority: Incrementing numbers require a coordinator to hand out the next value; distributed clones all committing offline would collide.

• Content addressing: The hash is derived from content, so the same content deduplicates and the ID is reproducible anywhere.

• Integrity and tamper detection: Because a commit's hash covers its tree and parent, changing any historical byte changes every downstream hash, making tampering obvious.

• SHA-256 migration: SHA-1 has known collision attacks, so Git added SHA-256 support for stronger guarantees.

HEAD is a pointer to your current position: usually a symbolic ref naming the branch you're on, so it points at a branch which points at a commit. A symbolic ref is a ref whose value is the name of another ref rather than a raw SHA.

• Normal HEAD: .git/HEAD contains ref: refs/heads/main, so committing advances main automatically.

• Symbolic ref:

  • A ref pointing to another ref by name rather than a commit hash; HEAD is the primary example.

  • Managed with git symbolic-ref.

• Detached HEAD: When you check out a specific commit, HEAD holds a raw SHA instead of a branch name, so new commits aren't tracked by any branch.

• Why it matters: HEAD is what commands like git commit and git status use as the baseline for the working state.

A ref (reference) is a human-readable name that points to a commit SHA: instead of remembering a 40-character hash, you use a name like main that resolves to that hash. Refs are how branches, tags, and HEAD are implemented.

• A ref is just a name pointing at an object:

  • Usually a file containing a commit SHA (a branch or lightweight tag), or a symbolic ref pointing to another ref.

  • Example: HEAD is typically a symbolic ref like ref: refs/heads/main.

• Where they live in .git:

  • Branches: .git/refs/heads/; tags: .git/refs/tags/; remotes: .git/refs/remotes/.

  • Special refs like HEAD sit at the top level of .git/.

• Packed refs: For efficiency Git can move loose ref files into a single .git/packed-refs file, so a branch may not appear as its own file.

• Inspect and update refs safely: Use git show-ref, git symbolic-ref HEAD, and git update-ref rather than editing files by hand.

The commit DAG (Directed Acyclic Graph) is Git's model of history: each commit points back to its parent(s), and following those pointers backward reconstructs the entire history. The arrows only go toward ancestors, so there are no cycles.

• Directed and acyclic:

  • Directed: a commit references its parents, never its children.

  • Acyclic: you can never loop back to a commit through its own ancestors.

• Parent pointers shape history:

  • One parent: a normal linear commit.

  • Zero parents: a root commit (the first, or an orphan branch).

  • Two or more parents: a merge commit, which is where branches rejoin.

• Branches and tags are entry points: They're just refs pointing at commits; the graph is traversed backward from them.

• Why the model matters:

  • Merge base, git log --graph, rebase, and reachability all follow directly from parent links.

  • Rebase doesn't edit commits: it creates new ones with different parents, reshaping the DAG.

Git stores full snapshots of every version of every file, so large binaries bloat the repo permanently because each change stores another near-full copy. Git LFS solves this by replacing large files with tiny text pointers in Git and storing the actual content on a separate LFS server.

• Why plain Git struggles with binaries:

  • Binaries don't delta-compress well, and every revision is kept forever in history, so clones grow huge.

  • You can't easily remove them later without rewriting history (git filter-repo).

• How Git LFS works:

  • A clean/smudge filter replaces the file with a small pointer file (containing an OID and size) that Git actually tracks.

  • The real bytes are uploaded to an LFS store and downloaded on checkout only when needed.

• Setting it up: Track patterns with git lfs track, which writes rules into .gitattributes.

• Trade-offs: Requires LFS support on the host, adds a dependency, and can incur storage/bandwidth quotas.

git worktree lets one repository have multiple working directories checked out at once, each on a different branch, all sharing the same .git object database. You get parallel branches without a full second clone.

• The problem it solves:

  • Normally a repo has one working tree, so switching branches means stashing or committing WIP.

  • A worktree gives each branch its own directory, so you can build one while editing another.

• How it works:

  • git worktree add ../hotfix hotfix creates a new directory checked out to that branch.

  • All worktrees share objects and refs, so it's far lighter than a clone (no duplicate history).

• Rules and cleanup:

  • The same branch can't be checked out in two worktrees at once.

  • Remove with git worktree remove, and tidy stale entries with git worktree prune.

• Common uses: Urgent hotfix while mid-feature, comparing two branches side by side, or running a long build on one branch.

A submodule is a Git repository nested inside another repository, pinned to a specific commit of the child repo. You use it instead of copying code so the dependency stays a live, versioned repository you can update and track independently.

• What it actually stores: The parent repo records the submodule's URL (in .gitmodules) plus a single pinned commit SHA (a gitlink), not the child's files.

• Why not just copy the code:

  • Keeps a clear upstream link and history, so you can pull updates and push fixes back.

  • Pins an exact version for reproducibility instead of a frozen, untraceable copy.

• Working with them:

  • Add with git submodule add <url>; after cloning run git submodule update --init --recursive.

  • Updating the pin means committing the new SHA in the parent repo.

• Trade-offs:

  • Extra workflow friction: forgetting to init/update is a common footgun, and detached-HEAD states confuse people.

  • Alternatives worth knowing: git subtree or a package manager may fit better for many dependencies.