Top 60 Git Interview Questions (2026)

Git is a distributed version control system that tracks changes to files over time. It lets many people work on the same codebase in parallel, keeps a full history of every change, and makes it possible to go back to any earlier state.

Teams use it because it's distributed: every clone is a complete repository with the full history, so you can commit and branch offline, and there's no single server whose outage stops all work. Branching is cheap, which makes feature branches and code review practical.

Git is the version control tool that runs on your machine and tracks changes. GitHub is a hosting service for Git repositories that adds a web interface, pull requests, issues, and access control on top.

You can use Git with no GitHub at all, pushing to any remote (GitLab, Bitbucket, a bare repo on a server). GitHub is one popular place to host the remote, not part of Git itself.

In a distributed system, every developer's clone contains the entire repository, including the full history, not just the latest files. Compare that to a centralized system like Subversion, where the history lives only on a server and each working copy is a thin snapshot tied to it.

The practical effect: you can commit, branch, diff, and browse history with no network connection, and any clone can act as a backup or become the new central copy if the main server dies.

A repository is the project's storage: all your files plus a hidden .git folder that holds the complete history, branches, tags, and configuration. Everything Git tracks lives in that .git directory, which is the single thing that turns an ordinary folder into a version-controlled project.

You create one with git init in a new project, or get a copy of an existing one with git clone. Delete the .git folder and you have plain files with no history.

git init creates a brand new, empty repository in the current directory. git clone copies an existing repository (usually from a remote URL) including its full history and sets up the remote for you.

Use init when you're starting fresh. Use clone when you want a local copy of a project that already exists somewhere.

The working directory is your actual files on disk. The staging area (also called the index) is where you assemble the exact set of changes for the next commit. The repository is the committed history stored in .git.

The flow is: edit files (working directory), git add to move chosen changes into staging, git commit to record staging into the repository. The staging area is what lets you commit some changes and leave others for later.

git add moves changes from your working directory into the staging area, choosing what goes into the next commit. git commit records everything staged as a new snapshot in the repository, with a message describing the change.

A commit is permanent history with a unique hash, an author, a timestamp, and a pointer to its parent. Nothing leaves your machine until you push.

git status shows the current state of your working directory and staging area: which files are staged, which are modified but not staged, and which are untracked. It also tells you the current branch and whether you're ahead of or behind the remote.

It's the command you run constantly to see where you stand before adding, committing, or pushing.

git log shows the commit history, newest first, with each commit's hash, author, date, and message. Flags shape the output: --oneline for a compact view, --graph to see branch structure, and -n to limit the count.

For what changed in each commit, add -p (the patch). For a quick summary of who touched a file, git blame is the tool.

A branch is a lightweight, movable pointer to a commit. Creating a branch just writes a new pointer, so it's instant and cheap, which is why Git encourages a branch per feature or fix.

The default branch is usually called main (older repos use master). Work happens on branches, and finished work merges back into the main line.

git switch -c name creates a new branch and moves onto it in one step. The older equivalent is git checkout -b name. To just move to an existing branch, use git switch name.

Newer Git splits the old, overloaded git checkout into git switch (for branches) and git restore (for files), which is worth mentioning as awareness.

A commit is a snapshot of your entire tracked project at a moment in time, plus metadata: the author, a timestamp, a message, and a pointer to the parent commit (or commits, for a merge). Each commit has a unique hash derived from its content.

Because a commit points to its parent, the history forms a chain (technically a directed graph). Git stores snapshots, not diffs, though it compresses them so identical content isn't duplicated.

A remote is a named reference to another copy of the repository, usually on a server. origin is the conventional name for the remote you cloned from. You push commits to a remote to share them and pull to get others' work.

A repo can have several remotes. git remote -v lists them with their URLs.

git push sends your local commits up to a remote branch, sharing your work with the rest of the team. git pull does the opposite: it brings remote commits down and integrates them into your current branch, so you get everyone else's work. Push is outgoing, pull is incoming.

Push is outgoing, pull is incoming. Under the hood pull is a fetch (download) followed by a merge or rebase.

git fetch downloads new commits and refs from the remote but doesn't touch your working branch or your files. git pull does a fetch and then immediately merges (or rebases) those downloaded changes into your current branch. So pull is really fetch plus an automatic integration step you don't get to review first.

Fetch is the safe, look-before-you-leap option: you can inspect what changed with git log origin/main before deciding to merge.

A .gitignore file lists patterns for files and folders Git should not track, like build output, dependencies such as node_modules, log files, and secrets. Git skips any matching untracked file so it never lands in a commit by accident, which keeps generated and sensitive files out of the repository.

One catch: .gitignore only affects untracked files. If a file is already tracked, adding it to .gitignore does nothing until you untrack it with git rm --cached.

git diff shows line-by-line changes. With no arguments it shows unstaged changes (working directory versus staging). git diff --staged shows staged changes versus the last commit, and git diff branchA branchB compares two branches.

It's how you review exactly what you're about to commit before committing it.

Cloning is a Git operation: you copy an existing repository, with its full history, down to your local machine. Forking is a host feature on GitHub or GitLab: you create your own server-side copy of someone else's repository under your account, which you can then clone and push to freely.

The typical open-source flow forks the upstream repo, clones your fork locally, and opens pull requests back to the original. Forking gives you a copy you can push to when you don't have write access to the original.

HEAD is a pointer to your current location in history, almost always the tip of the branch you have checked out. When you commit, HEAD (and its branch) move forward to the new commit.

HEAD~1 means one commit before HEAD, HEAD~2 means two before, and so on. A detached HEAD means you've checked out a specific commit directly rather than a branch.

For changes in the working directory, git restore file undoes them (older syntax: git checkout -- file). To unstage a file you already added, use git restore --staged file. To wipe all untracked files, git clean -fd.

Be careful: discarding uncommitted changes can't be recovered by Git, because they were never committed.

You get the full repository: every commit in the history, all branches and tags recorded as remote-tracking refs, and the complete .git directory, plus a working copy of the default branch checked out on disk. It's a complete copy, not a thin snapshot, which is exactly what makes Git distributed.

Because you have the whole history, you can work entirely offline. The clone also records where it came from as the remote named origin.

A short imperative summary line (about 50 characters, like 'Fix null check on login'), a blank line, then a body explaining why the change was made if it isn't obvious. Present tense, imperative mood, matches Git's own conventions.

Good messages make history readable and make git log, git blame, and code review far more useful months later. Interviewers who ask this care about team habits, not syntax.

A tracked file is one Git already knows about, because it was committed or staged at least once. An untracked file is new and Git isn't following it yet, so it won't be included in a commit until you git add it.

git status lists untracked files separately. .gitignore controls which untracked files Git stops bothering you about.

git checkout is the old, overloaded command that both switched branches and restored files, which confused people. Newer Git split it into two clearer commands: git switch changes branches, and git restore discards or unstages file changes.

checkout still works and does both jobs, but switch and restore make your intent obvious. Knowing the split shows you keep up with Git, and it prevents the classic accident of checking out a file when you meant a branch.

Both integrate changes from one branch into another. Merge creates a new merge commit that ties the two histories together, preserving the true branch shape. Rebase replays your branch's commits on top of another branch, producing a linear history but rewriting each commit's hash.

Use merge to keep an honest record of what happened, especially on shared branches. Use rebase to tidy up local, unpushed work into a clean line before sharing. The golden rule: never rebase commits others have already pulled.

git reset moves the current branch pointer to an earlier commit, effectively rewriting history from that point. git revert leaves history intact and creates a new commit that undoes the changes of a target commit.

The rule of thumb: use revert on shared or pushed branches because it doesn't rewrite history, and reset for local commits nobody has seen. Reverting is safe; resetting a public branch forces everyone else into a painful recovery.

All three move the branch pointer, but they differ in what they do to the staging area and working directory. --soft moves the pointer and keeps everything staged. --mixed (the default) unstages the changes but keeps them in the working directory. --hard discards the changes entirely.

So --soft is safest (undo the commit, keep the changes ready to recommit), and --hard is the destructive one that throws work away.

When Git can't automatically combine two changes to the same lines, it marks the file with conflict markers (<<<<<<<, =======, >>>>>>>) and pauses the merge. You open each conflicted file, decide what the final content should be, remove the markers, then stage the resolved files and finish the merge.

The steps: git status to see conflicted files, edit each one, git add them, then git commit (or git merge --continue). git merge --abort backs out entirely.

git stash saves your uncommitted changes onto a stack and reverts your working directory to a clean state, so you can switch branches or pull without committing half-done work. git stash pop reapplies the most recent stash and removes it from the stack.

Common use: you're mid-change and need to jump to another branch for a quick fix. Stash, switch, fix, switch back, pop. git stash list shows saved stashes.

git cherry-pick applies the changes from one specific commit onto your current branch, creating a new commit with the same changes but a new hash. It's how you grab a single fix from one branch without merging the whole branch.

Common use: a hotfix landed on main and you need just that commit on a release branch. Overuse creates duplicate commits and confusing history, so reach for merge or rebase when you want a whole branch.

git commit --amend replaces the most recent commit. With staged changes, it folds them into that commit; with -m, it rewrites the message. Either way it creates a new commit with a new hash, so only amend commits you haven't pushed.

Common uses: you forgot to add a file, or the message had a typo. If the commit is already pushed and shared, amending forces a rewrite others must deal with, so avoid it there.

A fast-forward merge happens when the target branch hasn't diverged: the branch you're merging is directly ahead of it in a straight line, so Git just slides the pointer forward to the newer commit with no merge commit created. The history stays perfectly linear, as if the work had happened in sequence.

If the branches have both moved on (diverged), a fast-forward isn't possible and Git creates a merge commit instead. You can force a merge commit even when fast-forward is possible with --no-ff, which some teams prefer to keep feature branches visible in history.

A tracking branch is a local branch linked to a remote branch, so Git knows where plain git push and git pull should go and can report how far ahead or behind you are. When you clone, your local main tracks origin/main automatically.

For a new local branch, set the upstream on first push with git push -u origin branch-name. After that, git push and git pull work with no arguments.

Use git revert, which creates a new commit that reverses the changes of the target commit, then push that new commit. Because revert adds to history instead of rewriting it, everyone who already pulled the original commit stays in sync with no forced re-clone or reset on their side.

Avoid reset and force-push on a shared branch: rewriting pushed history breaks everyone else's clone and is the classic way to cause a team-wide mess. Revert is the safe answer.

git rebase -i lets you rewrite a series of commits: reorder them, edit messages, squash several into one, split a commit, or drop it. You get a to-do list of commits and mark each with an action (pick, squash, reword, drop, edit).

It's for cleaning up local, unpushed work before opening a pull request: squash noisy 'wip' commits into a coherent story. Never run it on commits others have pulled, because it rewrites hashes.

Squashing combines several commits into one. You typically do it with an interactive rebase (mark commits as squash) or with a squash merge when landing a pull request, so a messy series of work-in-progress commits becomes a single clean commit on the main branch.

The benefit is a readable history: one commit per logical change instead of a dozen tiny steps. The cost is losing the granular detail, so squash local noise, not commits that carry meaningful separate changes.

A detached HEAD means HEAD points directly at a commit instead of a branch, which happens when you check out a specific commit hash or tag. You can look around and even commit, but those commits belong to no branch and can be lost.

To keep work done there, create a branch: git switch -c new-branch. To just leave without saving, switch back to a real branch. If you already made commits and left, git reflog helps you find them.

A tag marks a specific commit, usually a release like v1.0.0. A lightweight tag is just a name pointing at a commit. An annotated tag is a full object with a message, tagger, and date, and can be signed, which is why releases use annotated tags.

Tags don't move as you commit, unlike branches. Push them explicitly with git push --tags, since a normal push doesn't send tags.

main is your local branch, the one you commit to. origin/main is a remote-tracking branch: your local snapshot of where main was on the remote the last time you fetched. It only updates when you fetch or pull.

That's why after a fetch you can compare with git log main..origin/main to see incoming commits before merging. origin/main is read-only from your side; you update the real remote by pushing.

Locally, git branch -d name deletes a branch that's already been merged, while the capital -D forces deletion of one that hasn't. On the remote, git push origin --delete name removes the branch there. Deleting locally and deleting on the remote are separate actions, so cleaning up after a merged pull request usually needs both.

Deleting a local branch doesn't touch the remote, and vice versa, so cleaning up after a merged pull request usually means doing both.

git blame shows, line by line, which commit and author last changed each line of a file. It's how you trace when and why a specific line was introduced, then jump to that commit for the full context.

It's a diagnostic tool, not an accusation despite the name. Pair it with git log to read the full story behind a puzzling line.

Plain git pull fetches remote commits and merges them into your branch, which can create a merge commit when both sides have new work. git pull --rebase fetches and then replays your local commits on top of the remote ones, keeping history linear with no extra merge commit.

Many teams prefer --rebase for pulling to avoid a clutter of tiny merge commits. The trade-off is the usual rebase caution, though here it only rewrites your own unpushed commits, so it's safe.

Git config has three levels. System config applies to every user on the machine (--system). Global config applies to your user across all repos (--global, stored in ~/.gitconfig). Local config applies to one repository (--local, the default, stored in .git/config).

More specific levels override broader ones, so a per-repo setting beats your global one. Setting your name and email globally is the usual first step after installing Git.

Use git reflog, which records every position HEAD has been at, including commits you 'lost' with a bad reset, rebase, or branch deletion. Find the commit's hash in the reflog, then bring it back with git reset --hard <hash>, git cherry-pick <hash>, or by creating a branch at it.

This works because Git doesn't immediately delete unreachable commits; garbage collection removes them only after a grace period, so you usually have days to recover.

Git is a content-addressable store built on four object types: blobs (file contents), trees (directory listings pointing to blobs and other trees), commits (a tree snapshot plus parent, author, and message), and tags (annotated references). Every object is keyed by the SHA hash of its content.

Because objects are addressed by content hash, identical content is stored once, and a commit is a cheap pointer to a tree of pointers. Branches and tags are just refs: files containing a commit hash. That model is why branching is instant and history is tamper-evident.

Each commit's hash is computed from its content, including its parent's hash, so the hash chains all the way back. Changing any historical commit changes every hash after it, which makes history tamper-evident and gives every object a unique, content-based ID.

Git historically used SHA-1. Because SHA-1 collisions became practical to construct, the Git project added SHA-256 repositories and collision detection for SHA-1. Most repos still run SHA-1 with the hardened detection, and interoperability tooling for the transition is ongoing.

Rebase-based workflows give a clean, linear history that's easy to read and bisect, at the cost of rewriting commits, so they require discipline (never rebase shared branches) and can hide the real timeline of parallel work. Merge-based workflows record exactly what happened, which is honest and safer for less experienced teams, but produce a busier graph.

A common middle path: rebase or squash locally to tidy a feature branch, then merge it into main with a merge commit (or a squash merge) so main stays readable while individual work stays honest. The right call depends on team seniority and how much you value a linear history for tooling like bisect.

git bisect finds the commit that introduced a bug with a binary search over history. You mark a known-bad commit and a known-good one, and Git checks out the midpoint; you test and mark it good or bad, and it halves the range each time until it pins the exact culprit.

For a thousand commits it takes about ten steps instead of a linear scan. You can automate it fully by giving bisect a test script, so it runs the whole search hands-off.

Git hooks are scripts Git runs automatically at points in its workflow: pre-commit (run linters or tests before a commit), commit-msg (validate the message format), pre-push (block a push that fails checks), and server-side hooks like pre-receive for enforcing policy centrally.

Client-side hooks live in .git/hooks and don't travel with a clone, so teams manage them with tools like pre-commit or Husky that install shared hooks. Server-side hooks are the real enforcement point, since client hooks can be skipped.

The reflog records every update to HEAD and to branch tips: every commit, checkout, reset, rebase, and merge, with the previous position. It's local and separate from the commit history, which is why it can rescue commits that a reset or rebase made unreachable from any branch.

Unreachable commits survive until garbage collection prunes them, typically after a grace period of around 30 days, so the reflog gives you a real window to recover. It's the single most useful recovery tool in Git.

Force-pushing (git push --force) overwrites the remote branch with your local history, which is fine on a personal feature branch you alone use, for example after cleaning up commits with an interactive rebase. It's dangerous on shared branches because it can erase commits teammates pushed.

Use git push --force-with-lease instead: it refuses to overwrite if the remote has commits you haven't seen, protecting against clobbering someone else's work. And protect main and release branches so force-pushes are blocked entirely.

A submodule embeds one repository inside another as a pinned reference: the parent records a specific commit of the child, and the child stays its own repo you clone and update separately. A subtree merges another repo's contents directly into a subdirectory of yours, so there's nothing extra to clone.

Submodules keep clear boundaries and exact version pins but add workflow friction (extra init and update steps, easy to forget). Subtrees are simpler for consumers but make pulling upstream changes and pushing back more manual. Both solve vendoring; pick by who else consumes the shared code.

Git stores and diffs large binaries poorly, so committing big media files or datasets bloats the repository permanently, because the history keeps every version of every file forever. Every person who clones the repo then downloads all of that weight, which is why unmanaged binaries make a repo slow and heavy over time.

Git LFS (Large File Storage) replaces large files in Git with small text pointers and stores the actual content on a separate LFS server, downloading blobs on demand. It keeps the repo lightweight while still versioning large assets. For files already committed, cleaning them out means rewriting history.

You have to rewrite history, because the secret exists in past commits, not just the latest one. git filter-repo (the modern tool, replacing the slower filter-branch) rewrites every affected commit to strip the file or string, then you force-push and everyone re-clones or resets.

Two things must follow: rotate the secret, because it's already exposed in any clone or fork made before the rewrite, and invalidate caches on the host. Rewriting history alone doesn't un-leak a credential.

For a typical merge Git does a three-way merge: it finds the common ancestor (the merge base) of the two branch tips, then compares each branch against that base. Changes that don't overlap combine automatically; changes to the same lines from both sides produce a conflict Git can't decide.

The merge base is why Git is good at merging: it looks at what each side changed relative to a shared starting point, not just the two end states. Understanding this explains why conflicts happen exactly where both branches edited the same region.

GitFlow uses long-lived develop and release branches plus feature, release, and hotfix branches, which suits scheduled releases but adds overhead. GitHub Flow is lighter: short feature branches off main, opened as pull requests, merged and deployed continuously. Trunk-based development keeps everyone committing to main (or very short-lived branches) behind feature flags, optimizing for continuous integration.

The trend for teams doing continuous delivery is toward trunk-based or GitHub Flow, because long-lived branches accumulate painful merges. GitFlow still fits products with versioned, scheduled releases. The right choice follows your release cadence, not fashion.

git gc (garbage collection) cleans and compresses the repository: it packs loose objects into compressed packfiles, deltifies similar objects so only differences are stored, and prunes unreachable objects past their grace period. Git runs it automatically in the background at times, and you can trigger it manually.

Packing is why a repo with long history stays reasonable: Git stores deltas between similar objects rather than full copies of each version. Pruning is also why the reflog matters, because it's what keeps 'lost' commits reachable until gc removes them.

Cherry-pick when you need one or a few specific commits, not a whole branch: back-porting a single bug fix to a release branch, or pulling one useful commit out of an abandoned branch. Merge and rebase move a branch's whole set of commits.

The cost of overusing cherry-pick is duplicate commits (the same change appears with different hashes on two branches), which can confuse later merges. So it's a targeted tool, not a general integration strategy.

Compare them against their merge base. git log --oneline main..feature shows commits on feature but not main, and swapping the range shows the other direction; if both have unique commits, they've diverged. git status also reports 'ahead by X, behind by Y' for a branch and its upstream.

To sync a diverged feature branch you either merge main into it (a merge commit, honest history) or rebase it onto main (linear, rewrites your commits). Choose merge if the branch is shared, rebase if it's yours alone and you want a clean line.

git worktree lets one repository have multiple working directories checked out at once, each on a different branch, sharing the same object store. Instead of stashing and switching, you get a second folder with another branch checked out.

It's useful for running a long build on one branch while coding on another, reviewing a pull request without disturbing your current work, or comparing two branches side by side. It's lighter than a second clone because history isn't duplicated.