Top 30 Git Interview Questions for Beginners with Real Examples (2026 Guide)

By Kedar Salunkhe  ·  Updated March 2026  

Here is something nobody tells you before your first developer interview.

The Git questions are not hard. They are not trick questions. They are not designed to catch you out. They are designed to find out one simple thing: have you actually used Git on a real project, or have you just read about it?

The problem is that most beginners prepare for these questions by reading documentation and memorising definitions. Then the interviewer asks something like “walk me through what happens when you run git commit” and the answer that comes out sounds like a copied paragraph from a manual. Interviewers notice that immediately.

What you want is answers that sound like you’ve been there. Like you’ve actually typed these commands, hit problems, figured things out. That’s what this guide tries to give you.

We’ve covered 30 questions, starting from the most basic and building up gradually. Each answer explains not just what the answer is, but why it matters and what a real example looks like. Read through all of them. Practice saying the answers out loud. Then go open a terminal and actually run the commands.

That combination is what walks you into an interview feeling genuinely prepared rather than just hoping the right questions come up.

Fundamentals (Q1–Q10)

These are the questions that show up in every single Git interview, regardless of role or company size. If you are not fully confident on all ten of these, start here and stay here until you are.

Q1. What is Git and what problem does it solve?

What interviewers want to hear: Not the definition. The problem it solves.

Git is a version control system that tracks changes to files over time. But the honest answer to what problem it solves is this: before version control, people working on code did things like saving copies of files called project_final.js, then project_final_v2.js, then project_final_v2_ACTUALLY_USE_THIS.js. That breaks down the moment more than one person is working on the same code at the same time. Someone overwrites someone else’s changes. Nobody knows what changed between yesterday and today. You break something and have no idea what you did differently.

Git solves all of this. It keeps a complete history of every change, lets multiple people work simultaneously without overwriting each other, and lets you go back to any previous state at any time. It is used by over 93 percent of professional developers as of 2025. Knowing Git is not optional for anyone writing code professionally.

Q2. What is the difference between Git and GitHub?

What interviewers want to hear: That you understand these are two completely separate things.

Git is the tool itself. It is free, open-source software you install on your computer that lives entirely on your local machine. It tracks changes, creates commits, manages branches. It works with no internet connection at all.

GitHub is a website. It hosts Git repositories in the cloud so you can share them with teammates, back them up, and collaborate. It adds features on top of Git: Pull Requests for code review, Issues for tracking bugs and tasks, Actions for automation. GitHub is owned by Microsoft.

The analogy that lands well in interviews: Git is like Microsoft Word. GitHub is like Google Drive. You can write documents in Word without ever using Google Drive. But Google Drive is where you store and share those documents with others. Similarly, you can use Git locally without GitHub, but you use GitHub to store and collaborate on your Git repositories.

GitLab and Bitbucket do the same job as GitHub. They are all platforms for hosting Git repositories. The underlying tool in all cases is Git.

Q3. What is a repository?

What interviewers want to hear: A clear definition plus the distinction between local and remote.

A repository is a project directory that Git is tracking. It contains all the project files and the complete history of every change ever made. When you run git init inside a folder, Git creates a hidden .git directory inside it. That .git directory is the actual repository — it stores all the history, all the commits, all the configuration. The files you see and edit are just a working copy checked out from that repository.

A local repository lives on your own computer. A remote repository lives on a server like GitHub. In most workflows you have both — you work locally and push your changes to the remote to back them up and share them with your team.

# Creating a new local repository
$ mkdir my-project
$ cd my-project
$ git init
Initialized empty Git repository in /my-project/.git/

Q4. What are the three areas in Git that files move through?

What interviewers want to hear: Working directory, staging area, repository — and what each one means.

Every file in a Git project moves through three areas:

The working directory is your normal project folder — the files you are actively editing right now. This is what you see in your file explorer. When you modify a file here, Git sees it as changed but has not recorded that change anywhere yet.

The staging area (also called the index) is where you prepare your next commit. When you run git add filename, you move changes from the working directory into the staging area. You are telling Git: I want to include this change in my next commit. You can stage some files and not others, giving you precise control over what goes into each commit.

The repository is where committed changes live permanently. When you run git commit, everything in the staging area becomes a new commit saved into the repository history forever.

The flow is always: edit files in the working directory, stage the changes you want, commit them to the repository. Understanding this flow explains why almost every Git command works the way it does.

Q5. What does git init do?

What interviewers want to hear: What it does and what it creates.

git init turns an ordinary folder into a Git repository. It creates a hidden .git directory inside the folder. This directory contains everything Git needs: the object database where commits and file versions are stored, the configuration for this repository, and the hooks folder for automation scripts.

Before git init the folder is just a normal folder. After it, Git tracks everything inside it. You run git init once when starting a new project. If you are working with an existing project that is already on GitHub, you use git clone instead — that already runs git init internally.

One important thing: git init does not make any commits and does not connect to any remote. It just sets up the local tracking infrastructure.

Q6. What is a commit and what does it contain?

What interviewers want to hear: A real description of what a commit is, not just “saving your work.”

A commit is a permanent snapshot of your staged changes at a specific point in time. Every commit contains:

• A unique identifier — a 40-character SHA-1 hash like a3f9c12b...
• Your name and email address (from your git config)
• A timestamp
• The commit message you wrote
• A pointer to the complete snapshot of the project at that moment
• A pointer to the previous commit, creating the chain of history

One thing that surprises many beginners: a commit does not store a diff. It stores a complete snapshot of every file in the project at that moment. When you run git show or look at a commit on GitHub and see what changed, Git is computing the difference between this commit’s snapshot and the previous commit’s snapshot on the fly. The underlying storage is snapshots, not diffs.

# Stage your changes
$ git add login.js

# Commit with a clear message
$ git commit -m "Add email validation to login form"

[main a3f9c12] Add email validation to login form
 1 file changed, 8 insertions(+), 1 deletion(-)

Q7. What is a branch and why would you use one?

What interviewers want to hear: The definition plus a real-world reason to use one.

A branch is a separate line of development. It lets you work on something new — a feature, a bug fix, an experiment — without touching the stable code that is already working. The default branch in most repositories is called main.

Here is a real-world scenario: your company’s website is live on main. Your manager asks you to build a new contact form. You create a branch called feature/contact-form and do all your work there. Meanwhile, a critical bug is found on the live site. You switch back to main, fix the bug there, deploy it. Then switch back to your feature branch and keep building. Neither piece of work interfered with the other.

The technical detail that impresses interviewers: a branch is not a copy of your code. It is a lightweight pointer — literally a text file containing a single commit hash. Creating a branch takes milliseconds and adds almost no storage.

# Create a branch and switch to it immediately
$ git checkout -b feature/contact-form
Switched to a new branch 'feature/contact-form'

Q8. What is the difference between git clone and git init?

What interviewers want to hear: Clear and confident. This trips up a surprising number of beginners.

git init starts a brand new empty repository in your current folder. There is no existing project — you are beginning from scratch. No history, no files tracked, no remote configured.

git clone downloads an existing repository from somewhere else — usually GitHub — to your local machine. It copies the entire repository: all files, all commits, all branches, the full history. It also automatically sets up a remote called origin pointing back to wherever you cloned from.

When you join a team that already has a project on GitHub, you use git clone. When you start a brand new project from nothing, you use git init.

# Clone an existing repository from GitHub
$ git clone https://github.com/username/project-name.git

# This creates a local folder called project-name
# with all the code, history, and a remote called origin already set up

Q9. What is HEAD in Git?

What interviewers want to hear: A clear explanation, not just “it is the current commit.”

HEAD is a special pointer that tells Git where you currently are in the repository. In normal usage, HEAD does not point directly to a commit — it points to a branch, which in turn points to the most recent commit on that branch. This two-level setup is what lets Git know which branch to advance when you make a new commit.

When you switch branches, HEAD updates to point to the new branch. When you make a new commit, the branch HEAD is pointing to advances to include the new commit. HEAD follows along.

You may also hear about “detached HEAD state.” This happens when HEAD points directly to a commit instead of through a branch — usually because you checked out a specific commit hash. You can look around in detached HEAD state, but if you make commits there without first creating a branch, those commits can be lost when you switch back to a branch.

# HEAD normally looks like this (pointing to a branch)
$ cat .git/HEAD
ref: refs/heads/main

# In detached HEAD state it looks like this (pointing directly to a commit)
$ cat .git/HEAD
a3f9c12b8e1d4f7c2a9b6e3d8f1c5a2b9e4d7f3

Q10. What is .gitignore and when would you use it?

What interviewers want to hear: The definition plus at least two real examples of what goes in it.

A .gitignore file tells Git which files and folders to completely ignore — never track them, never show them in git status, never include them in commits. You put this file in the root of your repository.

You need it because every project generates files that should never go into version control. In a Node.js project, the node_modules folder can be hundreds of megabytes — it is installed from package.json and does not belong in Git. Build output folders like dist or build are generated automatically and should not be committed. Most critically, .env files containing secrets like database passwords and API keys must never be committed, especially to public repositories.

# Example .gitignore for a Node.js project
node_modules/
dist/
build/
.env
.env.local
*.log
.DS_Store

A common follow-up question: what if you already committed a file that should be ignored? Adding it to .gitignore does not untrack it — Git is already watching it. You need to run git rm --cached filename to stop tracking it, then commit that change. Only after that will .gitignore keep it out of future commits.

Core Commands and Concepts (Q11–Q20)

These questions dig into the commands you will use every single day as a developer. The answers here need to be comfortable and natural, not recited.

Q11. What does git status do and why is it useful?

What interviewers want to hear: That you actually use this command constantly, not just know it exists.

git status shows the current state of your working directory and staging area. It tells you which branch you are on, which files have been modified but not staged, which files are staged and ready to commit, and which files are new and not yet tracked by Git at all.

It is probably the most-run Git command in daily use. Before you stage anything, run git status. Before you commit, run git status. Any time you are not sure what state your repository is in, run git status. It never changes anything — it only shows you information. There is no risk in running it.

$ git status
On branch feature/contact-form
Changes not staged for commit:
  modified:   src/contact.js

Untracked files:
  src/contact.css

nothing added to commit but untracked files present

Q12. What is the difference between git add . and git add filename?

What interviewers want to hear: The practical difference and when to use each.

git add filename stages a specific file. Only that file’s changes move to the staging area. Everything else stays unstaged.

git add . stages everything in the current directory and all subdirectories — every modified file, every new untracked file. It is fast and convenient but requires you to be sure you want to stage everything. If you have debug files, temporary test code, or accidentally modified files you did not mean to change, git add . will include all of them.

Best practice: run git status before git add . to see exactly what you are about to stage. If anything looks wrong, use git add filename to stage selectively instead.

# Stage only a specific file
$ git add src/contact.js

# Stage everything
$ git add .

# Stage everything in a specific folder
$ git add src/

Q13. What is git push and what does the -u flag do?

What interviewers want to hear: What push does and what -u means, since freshers often use it without knowing why.

git push sends your local commits to the remote repository. Specifically it sends the commits on your current branch that the remote does not have yet.

The -u flag stands for “set upstream.” The first time you push a new branch to the remote, Git does not know which remote branch your local branch corresponds to. The -u flag tells Git to set up that connection — your local branch now knows its corresponding remote branch. After running it once with -u, every subsequent git push and git pull on that branch works without needing to specify the remote and branch name.

# First time pushing a new branch — use -u to set up tracking
$ git push -u origin feature/contact-form
Branch 'feature/contact-form' set up to track remote branch 'feature/contact-form' from 'origin'.

# After that, just:
$ git push

Q14. What is the difference between git pull and git fetch?

What interviewers want to hear: A clear explanation of both and what makes them different in practice.

git fetch downloads changes from the remote repository but does not apply them to your local branch. It updates your remote-tracking branches — the local records of where the remote branches are — but leaves your actual working files and local branches completely untouched. It is always safe to run.

git pull does a git fetch followed immediately by a git merge. It downloads the remote changes and integrates them into your current local branch in one step. If the remote has changes that conflict with your local commits, git pull will produce a merge conflict that you need to resolve.

Think of it this way: git fetch lets you see what changed on the remote before deciding what to do. git pull downloads and merges in one shot without giving you that preview.

# Safe — downloads but does not merge
$ git fetch origin

# See what changed on the remote without affecting your branch
$ git log origin/main --oneline

# Then merge when ready
$ git merge origin/main

# OR do both at once with pull
$ git pull

Q15. What is a merge conflict and how do you resolve one?

What interviewers want to hear: That you know what causes them, what they look like, and the actual steps to fix one.

A merge conflict happens when two branches have both changed the same part of the same file in different ways and Git cannot automatically decide which version to keep. Git stops the merge and marks the conflicted sections in the file with special markers.

<<<<<<< HEAD
const timeout = 7200;
=======
const timeout = 1800;
>>>>>>> feature/security-update

The section between <<<<<<< HEAD and ======= is your version. The section between ======= and >>>>>>> is the incoming version from the other branch.

To resolve it: open the file, read both versions, edit the file to what it should actually be, remove all the conflict markers, save it. Then run git add filename to mark it resolved and git commit to complete the merge.

Conflicts are not errors. They are Git telling you there is a decision only a human can make. Every developer hits them regularly. Getting comfortable with them is part of working on a team.

Q16. What is git merge?

What interviewers want to hear: What it does and a real scenario where you would use it.

git merge combines the changes from one branch into another. You switch to the branch you want to merge into, then run git merge branch-name to bring in that branch’s commits.

Real scenario: you have been building a login feature on feature/login. It is done, tested, and ready. You switch to main and merge your feature branch in. All the commits from feature/login are now part of main. The feature branch still exists — merging does not delete it — but you would typically delete it afterwards since its work is now in main.

# Switch to main first
$ git checkout main

# Bring in the feature branch
$ git merge feature/login
Updating a3f9c12..f4d8a1b
Fast-forward
 src/auth/login.js | 42 +++++++++++++++++
 1 file changed, 42 insertions(+)

# Delete the branch since its work is now in main
$ git branch -d feature/login

Q17. What is git log and what information does it show?

What interviewers want to hear: The basic usage and at least one useful option.

git log shows the commit history of the current branch — every commit that has been made, listed from newest to oldest. For each commit it shows the full SHA-1 hash, the author name and email, the date, and the full commit message.

The most practical version for everyday use is git log --oneline which shows one line per commit with a shortened hash and just the first line of the message. Much easier to scan.

$ git log --oneline
f4d8a1b  Add password validation to login form
a3f9c12  Add login form HTML and CSS
b1e4d90  Initial project setup

# Show a visual graph of branches
$ git log --oneline --graph --all

If you want to see what changed in a specific commit, use git show commit-hash. If you want to see the history for a specific file, use git log -- filename.js.

Q18. What is git diff?

What interviewers want to hear: The basic usage and the important –staged variation.

git diff shows the exact line-by-line differences between file versions. Without any arguments it shows the changes in your working directory that are not yet staged — what you have changed since the last commit that you have not run git add on yet.

git diff --staged shows what is in the staging area — what will go into the next commit when you run git commit. This is the one to run right before committing to double-check you are committing exactly what you think you are.

# See unstaged changes
$ git diff

# See staged changes (what will be in next commit)
$ git diff --staged

# See difference between two branches
$ git diff main feature/login

Q19. What is git stash and when would you use it?

What interviewers want to hear: The definition and a real scenario — the scenario is what makes the answer memorable.

git stash temporarily saves your uncommitted changes and reverts your working directory to the last committed state. It puts your work-in-progress aside so you can switch context cleanly. Use git stash pop to bring your changes back.

The classic scenario: you are halfway through building a feature. Your working directory has changes all over the place — nothing is committed because it is not ready. Then your manager messages you about an urgent bug that needs fixing immediately. You cannot switch branches with uncommitted changes that would conflict. You run git stash, your working directory goes clean, you switch to main, fix and commit the bug, push it, then come back to your feature branch and run git stash pop to restore all your in-progress work exactly as you left it.

# Save work in progress
$ git stash push -m "Half-finished contact form"
Saved working directory and index state: Half-finished contact form

# Your working directory is now clean — safe to switch branches
$ git checkout main

# Fix the urgent bug, commit it, push...

# Come back to your feature and restore the stash
$ git checkout feature/contact-form
$ git stash pop

Q20. What is the difference between git reset and git revert?

What interviewers want to hear: That you understand why one is safe for shared branches and one is not.

git revert undoes a commit by creating a new commit that does the opposite. The original commit stays in the history — nothing is rewritten. Because it adds to the history rather than rewriting it, git revert is safe to use on branches that other people have already pulled. The team’s history stays consistent.

git reset moves the branch pointer backwards, effectively removing commits from the history. This is useful for undoing local commits that have not been pushed yet. But if you use it on commits that teammates have already pulled, their history no longer matches yours. This causes serious problems and requires everyone to sort out the mismatch.

The rule that makes sense of it: use git revert to undo things on shared branches. Use git reset only on local commits that no one else has seen yet.

# Safe for shared branches — creates a new "undo" commit
$ git revert a3f9c12

# Local only — moves pointer back, rewrites history
$ git reset --soft HEAD~1   # undo commit, keep changes staged
$ git reset --hard HEAD~1   # undo commit, discard changes completely

Practical and Applied Questions (Q21–Q30)

These questions go beyond definitions into real situations. Interviewers ask these to find out if you can actually apply what you know. Beginners who have only read about Git struggle here. Beginners who have used it on real projects find these natural.

Q21. Walk me through your typical Git workflow on a project.

What interviewers want to hear: A coherent, realistic workflow — not a list of commands.

At the start of each day, the first thing is to pull the latest changes from the remote so the local main branch is up to date. Then create a new branch for whatever task is being worked on that day. The branch name describes the work: feature/user-profile-page or fix/broken-nav-link.

Work happens on that branch. Commits are made in small logical pieces as each part of the work is done — not one giant commit at the end of the day. Each commit message describes what changed and why in plain language.

When the work is complete and tested, the branch is pushed to the remote and a Pull Request is opened. A teammate reviews the code, leaves comments, and once approved the PR is merged into main. The feature branch is deleted after merging.

# Start of each piece of work
$ git checkout main
$ git pull origin main
$ git checkout -b feature/user-profile-page

# Work and commit in small pieces
$ git add src/profile.js
$ git commit -m "Add profile page layout and basic routing"

$ git add src/profile.css
$ git commit -m "Style profile page header and avatar section"

# When done
$ git push -u origin feature/user-profile-page
# Open Pull Request on GitHub

Q22. What is a Pull Request and how does code review work?

What interviewers want to hear: That you understand this is a GitHub feature, not a Git feature, and what it is actually for.

A Pull Request is a feature of platforms like GitHub and GitLab, not Git itself. It is a formal proposal to merge changes from one branch into another. You push your feature branch to the remote and then open a Pull Request saying: here are the changes I made, I am requesting that these get merged into main.

The PR shows the exact diff — every line added, every line removed. Teammates can look through the changes, leave comments on specific lines, ask questions, and request modifications before approving. You respond to feedback by making new commits on the same branch, which automatically appear in the PR. Once enough people approve, someone merges it.

Code review via Pull Requests is how professional teams maintain quality and spread knowledge. It catches bugs before they reach production, ensures at least one other person understands every change, and creates a permanent searchable record of why decisions were made.

Q23. How do you undo the last commit if you have not pushed it yet?

What interviewers want to hear: A specific command and an explanation of what it does to your changes.

The safest option is git reset --soft HEAD~1. This moves the branch pointer back one commit, undoing the commit, but keeps all the changes staged in the index. Nothing is lost — the changes are right there waiting to be committed again. You can fix whatever was wrong and re-commit.

If you want the changes unstaged instead of staged, use git reset HEAD~1 (which is --mixed by default). The changes are still in your working directory, just not staged.

If you used the wrong commit message and that is the only problem, use git commit --amend instead of reset. This replaces the last commit with a new one and opens your editor to fix the message. Again, only safe before pushing.

# Undo the last commit, keep changes staged
$ git reset --soft HEAD~1

# Undo the last commit, keep changes in working directory (unstaged)
$ git reset HEAD~1

# Fix only the commit message on the last commit
$ git commit --amend -m "Correct commit message here"

Q24. How do you see what changed in a specific commit?

What interviewers want to hear: The command and what it shows.

git show commit-hash shows the full details of a specific commit: the author, date, message, and the complete diff of every file changed in that commit.

# Show a specific commit by its hash
$ git show a3f9c12

# Show the most recent commit
$ git show HEAD

# Show just the files changed in a commit, not the full diff
$ git show --stat a3f9c12

A related command: git diff commit1 commit2 shows all the differences between two specific commits. Useful when you want to see everything that changed between two points in history, not just what one commit introduced.

Q25. What happens when you delete a branch? Is the work lost?

What interviewers want to hear: That deleting a branch does not delete the commits, and why.

Deleting a branch does not delete the commits. A branch is just a pointer — a text file containing a commit hash. Deleting the branch file removes the pointer, but the commit objects themselves remain in Git’s database.

If the branch was already merged into another branch like main, then all its commits are now reachable through main‘s history. The branch pointer was redundant anyway — that is why Git lets you delete merged branches with git branch -d and the commits are safely accessible through main.

If you delete an unmerged branch — one whose commits are not part of any other branch — those commits become unreachable from any branch. Git will eventually clean them up through garbage collection. But they are still in the database for 90 days and you can recover them through the reflog if you act quickly.

# Safe delete — only works if branch is merged
$ git branch -d feature/old-feature

# Force delete — works even if not merged (use carefully)
$ git branch -D feature/abandoned-experiment

# Delete a remote branch
$ git push origin --delete feature/old-feature

Q26. How do you connect a local repository to a remote on GitHub?

What interviewers want to hear: The complete sequence from a new local repo to a connected remote.

First create a new empty repository on GitHub — do not check the option to initialize it with a README, since you already have local files. Then connect your local repository to that remote and push:

# Add the remote — name it origin by convention
$ git remote add origin https://github.com/yourusername/your-repo.git

# Rename your default branch to main if it is not already
$ git branch -M main

# Push and set up tracking in one step
$ git push -u origin main

After this, git push and git pull on the main branch work without specifying the remote or branch name every time. The -u flag set up that connection.

To check which remote a repository is connected to, run git remote -v. It shows the fetch and push URL for each remote.

Q27. What is git cherry-pick and when would you use it?

What interviewers want to hear: The definition and one clear real-world use case.

git cherry-pick takes a single specific commit from any branch and applies its changes to your current branch as a new commit. You are picking one cherry from the tree rather than merging the whole branch.

The classic use case: a developer has been working on a large feature branch that is not ready for release. Buried within that branch is a critical bug fix. Production needs that fix now, but you cannot merge the whole feature because it is incomplete. Use git cherry-pick to apply just the bug fix commit to main without bringing in any of the unfinished feature code.

# Find the commit hash of the bug fix on the feature branch
$ git log feature/big-feature --oneline
f4d8a1b  Fix critical null pointer in payment processing  ← this one
a3f9c12  Add new checkout flow (incomplete)
b1e4d90  Add cart summary component (incomplete)

# Apply just the bug fix to main
$ git checkout main
$ git cherry-pick f4d8a1b

Q28. How do you write a good commit message?

What interviewers want to hear: That you actually think about commit messages, not just type something to get past the prompt.

A good commit message tells future readers — including yourself six months from now — what changed and why. The subject line should be 50 characters or fewer and use the imperative mood: “Add email validation” not “Added email validation” or “Adding email validation.” It should complete the sentence “If applied, this commit will…”

Bad commit messages: “fix”, “WIP”, “changes”, “update stuff”, “please work”. These are useless in a history that might have thousands of commits. When you run git log --oneline three months from now trying to find when a specific behavior changed, messages like these tell you nothing.

Good commit messages: “Fix login redirect loop when session token expires”, “Add rate limiting to the signup endpoint”, “Remove deprecated user preferences API”. These tell you exactly what happened without needing to read the diff.

# Bad
$ git commit -m "fix"
$ git commit -m "changes to login"

# Good
$ git commit -m "Fix null pointer crash when email field is empty on login"
$ git commit -m "Add rate limiting to prevent brute force on login endpoint"

Q29. What would you do if you accidentally pushed sensitive data to a public repository?

What interviewers want to hear: That you know to rotate the secret immediately, not just delete the file.

The very first step — before doing anything else in Git — is to rotate the secret. Generate a new API key, revoke the old one, update all systems that used it. Assume the moment it was pushed it was seen by someone. Even if the repository is public for only five minutes, automated scanners crawl GitHub continuously looking for exposed credentials.

After rotating, remove the secret from the repository history. Deleting the file and committing is not enough — the secret is still visible in previous commits. Use git filter-repo to rewrite the history and remove it completely, then force-push. Contact GitHub support as well — they can help purge cached versions.

Finally, add the file to .gitignore so it can never be accidentally committed again. The lesson everyone learns the hard way: secrets go in environment variables and .env files, .env goes in .gitignore, and that .gitignore entry happens before the first commit.

Q30. What is the reflog and why is it useful for beginners specifically?

What interviewers want to hear: That you know it exists and understand why it is a safety net.

The reflog is a local log of every position HEAD has been in for the last 90 days. Every commit, every branch switch, every reset, every merge — it is all recorded. It runs in the background automatically without you having to do anything.

Why it matters for beginners: beginners make mistakes. They do hard resets and then realise they did not want to throw away those changes. They delete branches and then want them back. They run a command from a tutorial without fully understanding it and end up somewhere unexpected. The reflog is almost always how you get back to where you were.

$ git reflog
f4d8a1b HEAD@{0}: reset: moving to HEAD~1
a3f9c12 HEAD@{1}: commit: Add login form validation
b1e4d90 HEAD@{2}: commit: Add login page HTML

# Recover the commit that was "lost" in the reset
$ git checkout -b recovery-branch a3f9c12

The reflog is local only — it is not pushed to remotes and is not available after a fresh clone. But while you are working in your local repository, it is your strongest safety net. Before you panic about losing work in Git, run git reflog.

What to Do Before Your Interview

Run Every Command in a Real Terminal

Create a test repository right now. Run git init, create some files, make commits, create branches, merge them, deliberately create a conflict and resolve it, do a hard reset and recover using the reflog. Doing the commands once in a real terminal is worth reading about them ten times. Your answers in the interview will feel natural instead of recited.

Be Able to Explain the Three Areas

Working directory, staging area, repository. If someone asks you to explain what happens when you run git add and then git commit, you should be able to walk through it clearly without hesitating. This comes up in different forms in almost every Git interview.

Have One Real Project to Talk About

If you have used Git on any real project — a personal project, a college assignment, an open source contribution, anything — know it well enough to talk about it. What branches did you create? Did you have any merge conflicts? How did you collaborate? Concrete examples from real work are worth far more than perfectly memorised definitions.

Know the Difference Between Git and GitHub Cold

This question appears in nearly every interview and a surprising number of beginners stumble on it. Git is the local tool. GitHub is the hosting platform. Pull Requests are a GitHub feature, not a Git feature. Branches exist in Git. Forks exist in GitHub. Know this cleanly.

Be Honest About What You Have Not Used

If you have not used git cherry-pick or git bisect in a real project, say so. Then explain what you understand about it conceptually. An interviewer who hears “I have not used it yet but I understand it applies individual commits from one branch to another” knows you are honest and have genuinely studied. That is much better than guessing and getting it wrong.

Frequently Asked Questions

Related Resources

For building your Git knowledge before interviews:

• Pro Git (Free Book) — The authoritative reference. Chapters 1, 2, and 3 cover everything in this guide in depth. Free to read online.
• Learn Git Branching — Interactive visual exercises in the browser. The best way to build real intuition for how branches and merges work without needing a terminal set up.
• Oh Shit, Git! — Plain English guide for when things go wrong. Practical and honest. Worth knowing the recovery steps before your interview in case a scenario question comes up.
• GitHub Getting Started Guide — Covers the GitHub-specific features (Pull Requests, forks, Issues) that come up in interviews alongside the Git questions.
• Atlassian Git Tutorials — Well-written with good diagrams. Particularly strong on branching strategy explanations.

More on this site:

• Git Blogs
• DevOps Blogs
• Kubernetes Blogs
• AI Blogs
• Troubleshooting Blogs

Final Thoughts

The honest truth about Git interview questions for beginners is this: they are not testing your ability to recall a list of commands. They are testing whether you have actually sat with a terminal open and used Git on something real. The candidates who answer these well do not sound like they are reciting. They sound like they have been there.

That experience is available to everyone. Start a project today — any project. A to-do app, a script that automates something, a simple website, anything. Use Git properly on it from day one. Create branches for every change. Write commit messages that describe what and why. Push to GitHub. Make a Pull Request even if you are the only one reviewing it. Deliberately create a conflict and resolve it.

Do those things for two weeks and you will answer these questions differently than someone who spent two weeks reading about them. The difference is noticeable and interviewers feel it immediately.

Focus on Q1 through Q15 first. Get those completely solid. Move to Q16 through Q20 once the basics feel natural. The practical questions in Q21 through Q30 will start making sense on their own once you have real experience to connect them to.

Good luck. Git is genuinely one of the easier interview topics to prepare for, because the preparation is the same as just doing good work.

About the Author

Kedar Salunkhe

DevOps Engineer | Seven years of fixing things that break at 2am
Kubernetes • OpenShift • AWS • Coffee

I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy. You can usually find me where the coffee is strong and the error logs are confusing.