In this article
How to use this list
Read each answer, then say it aloud in your own words. Git sits underneath most pipeline work, so these questions often open a wider conversation covered in the DevOps interview questions overview. For the shell skills that go with Git, see Linux commands and how to combine them. Where a question rests on a documentation page, the link follows the answer.
Git basics
How does Git differ from older version control systems?
Git thinks about its data as a stream of snapshots. A snapshot is a record of what every tracked file looked like at one moment. Older tools such as Concurrent Versions System (CVS), Subversion and Perforce are described as delta-based, storing a list of changes per file. Git keeps unchanged files as a link to the identical file it already stored, so snapshots stay efficient (Pro Git, What is Git?, read October 2026).
Why it is asked: it shows whether you hold the right mental model: conceptually Git records snapshots, even though its packfiles delta-compress objects on disk to save space. Read the full explanation: version control systems and how Git works.
What is the difference between Git and GitHub?
Git is the version control tool that runs on your machine and keeps the history in a local repository. GitHub and GitLab are hosting services that store a shared copy of a repository and add pull requests, access control and automation around it. You can use Git with no hosting service at all, and a pipeline reads from the hosted copy.
Why it is asked: it separates a tool from a platform, a distinction that matters when you design pipelines. Read the full explanation: version control systems and how Git works.
What are the three states and three areas in Git?
A file is in one of three states: modified, staged or committed. They map to three areas of a project: the working tree, the staging area and the Git directory. Modified means changed but not yet committed; committed means safely stored in your local database. The staging area is a file, in technical terms the index, that records what will go into your next commit (Pro Git, What is Git?, read October 2026).
Text description of the diagram
- A Git project has three main sections: the working tree, the staging area and the Git directory.
- The staging area stores information about what will go into your next commit.
Why it is asked: staging is the step many beginners skip over, and reset questions depend on it. Read the full explanation: version control systems and how Git works.
Is the staging area the same thing as the index?
Yes. The staging area and the index are two names for one thing. Pro Git says the technical name in Git parlance is the index, and that the phrase staging area works just as well (Pro Git, What is Git?, read October 2026). Because it sits between the working tree and the history, you can commit part of your changes and leave the rest for a later commit.
Why it is asked: interviewers use the two names to check you are not thrown by vocabulary. Read the full explanation: version control systems and how Git works.
What is a branch in Git?
A branch is a movable pointer to a commit, so creating one is cheap: Git adds a new name, not a copy of the project. When you commit on a branch, its pointer moves forward to the new commit. Teams use branches to work on a feature or fix in isolation and bring the result back through a merge or a pull request.
Why it is asked: it checks that you see branches as pointers, which explains why merge and rebase behave as they do. Read the full explanation: the main git commands and what each one does.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Undoing changes
What is the difference between git reset --soft, --mixed and --hard?
All three move the current branch to a chosen commit; they differ in what else they reset. The --soft mode leaves the staging area and working tree alone, so changes stay staged. The --mixed mode, the default, also resets the staging area, so changes stay in your files but unstaged. The --hard mode resets the working tree too and discards uncommitted changes to tracked files; untracked files stay. Commits it moves away from usually remain recoverable through the reflog for a while (git-reset manual, opened October 2026).
Why it is asked: it tests the three-area model and whether you know which command can lose work. Read the full explanation: git-reset documentation.
What is the difference between git revert and git reset?
The git revert command adds a new commit that undoes the changes of an earlier one, so history is kept and only grows. The git reset command moves the branch pointer to another commit, usually an earlier one, which rewrites what the branch looks like. On a branch other people have already pulled, revert is the safe choice, because reset would make their history disagree with yours.
Why it is asked: it shows whether you think about shared history before you undo anything. Read the full explanation: git-reset documentation.
How do you change or undo your last commit?
If the commit is not shared, git commit --amend replaces it with a new commit, which lets you fix the message or add a forgotten file. To undo it but keep the work, git reset --soft HEAD~1 moves the branch back one commit and leaves the changes staged. If the commit is already pushed to a shared branch, use git revert instead.
Why it is asked: it is a daily task, and the right answer depends on whether the commit is shared. Read the full explanation: git-reset documentation.
How do you recover a commit after git reset --hard?
The reflog records where HEAD and your branch tips have pointed, so a commit that a reset or rebase moved away from can usually still be found there for a while, until Git cleans up old entries. Run git reflog, find the entry from before the reset, and point a branch at it with git branch rescue <hash> or git reset --hard <hash>. Changes that were never committed generally cannot be recovered this way (git-reflog manual, opened October 2026).
Why it is asked: it is the natural next question after reset --hard, and it shows you know history is rarely lost at once. Read the full explanation: the main git commands and what each one does.
Sharing work and history
What is the difference between git fetch and git pull?
The git fetch command downloads new commits and branch updates from the remote without changing your working files or your branch. The git pull command does a fetch and then integrates the result into your current branch, by merge or by rebase depending on your configuration; when the histories have diverged and no choice is set, current Git versions stop and ask you to pick (git-pull manual, opened October 2026). Fetching first lets you inspect what changed before you decide how to combine it.
Why it is asked: it checks whether you know what runs behind a convenient command. Read the full explanation: the main git commands and what each one does.
What is the difference between merge and rebase?
A merge joins two branches and, unless it is a fast-forward, records a merge commit, so the real branching history stays visible. A rebase takes your commits and replays them on top of another branch, creating new commits and a straighter history (Pro Git, Rebasing, opened October 2026). Merge preserves what happened; rebase gives a cleaner story. Both bring the same final content.
Why it is asked: teams have strong, different habits here, and interviewers want your reasoning. Read the full explanation: Pro Git, Rebasing.
When should you not rebase?
Do not rebase commits that others may already have based work on, such as commits pushed to a shared branch. Rebase creates new commits in place of the old ones, so collaborators holding the old commits end up with a history that conflicts with yours. Pro Git covers this in its discussion of the risks of rebasing (Pro Git, Rebasing, opened October 2026). Rebase your private work freely.
Why it is asked: it separates people who know the command from people who know its blast radius. Read the full explanation: Pro Git, Rebasing.
Why is a force push risky, and what is --force-with-lease?
A force push makes the remote branch match your local one even when that discards commits you have never seen, including a teammate's work. The --force-with-lease option is safer: it refuses to overwrite the remote branch if it has moved since you last fetched. You still need it after a rebase of your own already-pushed branch, but never aim it at a shared main branch. A background fetch can defeat the lease; --force-if-includes adds a further check.
Why it is asked: lost commits on a shared branch are a real production-process risk. Read the full explanation: the main git commands and what each one does.
How do you resolve a merge conflict?
A conflict happens when two branches change the same lines, or one deletes what the other edits, and Git cannot choose. Git marks the file with conflict markers. You open it, keep the correct result, remove the markers, stage the file with git add and finish the merge with a commit. Running the tests before you commit the resolution catches a wrong guess.
Why it is asked: it shows whether you stay calm and verify rather than pick one side blindly. Read the full explanation: the main git commands and what each one does.
Everyday workflow
What does git stash do?
The git stash command shelves your uncommitted changes and restores a clean working tree, so you can switch branches for an urgent fix. Later git stash pop reapplies the changes. It is a short-term parking place, not storage: for work you want to keep, commit it on a branch instead.
Why it is asked: it tests practical habits when priorities change mid-task. Read the full explanation: the main git commands and what each one does.
What does git cherry-pick do, and when do you use it?
The git cherry-pick command takes the changes of one chosen commit and applies them as a new commit on your current branch. A common use is moving a single bug fix to a release branch without bringing along the rest of the feature branch. Because it creates a copy, the same change then exists as two commits.
Why it is asked: it checks that you can move one fix between branches without merging everything. Read the full explanation: the main git commands and what each one does.
How would you find the commit that introduced a bug?
Use git bisect, which performs a binary search through history. You mark one commit as bad and an older one as good; Git checks out a commit in the middle, you test it and mark it good or bad, and the range halves each time. A script that exits with a failure status can automate the test.
Why it is asked: it shows systematic debugging instead of reading history by hand. Read the full explanation: the main git commands and what each one does.
What is the difference between trunk-based development and GitFlow?
In trunk-based development everyone integrates small changes into one main branch often, with short-lived branches at most. GitFlow uses long-lived branches such as develop and release, which adds structure but delays integration and makes merges larger. Reported practice differs by team: frequent integration suits continuous delivery, while scheduled releases may justify more branches. Explain the trade-off, not a favorite.
Why it is asked: it reveals how you think about integration risk and release cadence. Read the full explanation: how a continuous integration (CI)/continuous delivery (CD) pipeline works.
Git in the DevOps pipeline
How does a push to Git trigger a pipeline?
Continuous integration (CI) is the practice of building and testing every change automatically when it is pushed. The Git host usually sends a webhook, which is a Hypertext Transfer Protocol (HTTP) request the host makes to another system when an event such as a push happens. The CI server receives it, fetches the commit and runs the configured pipeline. Some servers poll the repository instead.
Why it is asked: it connects Git to the automation most DevOps roles own. Read the full explanation: how a CI/CD pipeline works, and see What is Jenkins? for one CI server.
What is a Git tag, and how is it used in releases?
A Git tag is a name attached to a specific commit, usually to mark a release. A lightweight tag is only that name; an annotated tag is a full object that also stores the tagger, a date and a message, and is the usual choice for releases. Tags do not move as you commit. A pipeline is often set to build and deploy when a tag is pushed (Pro Git, Git Basics: Tagging, opened October 2026).
Why it is asked: releases need a fixed, named point in history, and the answer shows you can tie Git to deployment. Read the full explanation: the main git commands and what each one does.
What happens if a secret is committed to Git?
Deleting the secret in a later commit does not remove it, because earlier commits still contain it in history, and anyone with a clone has it. Treat it as exposed: revoke and rotate the credential first, then clean the history if needed. Prevention is better, with secret scanning in CI and secrets kept in a dedicated store.
Why it is asked: leaked credentials are a routine incident, and the order of your steps shows judgment. Read the full explanation: how a CI/CD pipeline works.
What is .gitignore for?
A .gitignore file lists patterns for files Git should not track, such as build output, dependency folders, local settings and secret files. It only affects files not yet tracked: a file already committed stays tracked until you remove it from the index with git rm --cached. Commit the file itself so the whole team shares the rules.
Why it is asked: it checks hygiene that keeps repositories small and free of secrets. Read the full explanation: the main git commands and what each one does.
What are Git hooks, and why not rely on them alone?
Git hooks are scripts that Git runs at set points, such as before a commit or before a push. They are handy for local checks like formatting. They live on each person's machine and can be skipped, so enforce important rules in CI or on the server side as well.
Why it is asked: it tests whether you know where a rule can be enforced reliably. Read the full explanation: how a CI/CD pipeline works.
What is GitOps?
GitOps is a way of operating infrastructure in which the desired state of a system is kept in Git, and an automated process makes the running system match it. A change then goes through a normal review and merge, and rollback is a revert. It is often discussed alongside Kubernetes clusters.
Why it is asked: it tests whether you see Git as the source of truth for operations, not only for code. Read the full explanation: Kubernetes interview questions and answers.
Follow-up questions
What Git questions are asked in a DevOps interview?
Common topics include the snapshot model, staging, reset versus revert, merge versus rebase, force push, branching strategy and how Git triggers a pipeline. The list above covers these. Expect the interviewer to move from a command to the reason behind it.
What is HEAD, and what is a detached HEAD?
The HEAD pointer marks the commit you have checked out, normally through a branch name. Detached means it points straight at a commit, so new commits belong to no branch until you create one, for example with git switch -c <name>; otherwise they can be lost once the reflog entries expire.
Which Git commands should I know for a DevOps role?
Know status, add, commit, branch, switch, merge, rebase, fetch, pull, push, reset, revert, stash, cherry-pick, log and diff, and what each does to the three areas. See the main git commands and what each one does for a command-by-command reference, and pair them with shell skills from Linux commands.
How do I practice Git questions before an interview?
Make a throwaway repository and create the situations yourself: a conflict, a bad commit to undo, a rebase of a private branch. Then explain each fix aloud in two or three sentences. Connect the answers to automation by reading about Jenkins pipelines.
- Git stores snapshots, and files move through three states: modified, staged, committed.
- The staging area and the index are the same thing.
- Reset moves the branch pointer; revert adds a new commit, which is safer on shared branches.
- Merge keeps history as it happened; rebase replays commits, so keep it to private work.
- A pipeline normally starts from a webhook sent by the Git host, and a leaked secret needs rotation, not just deletion.
Sources
- What is Git? (Pro Git, 2nd edition, chapter 1.3) — Git project (Chacon and Straub), read 2026-10-26, 26 Oct 2026
- Git Branching: Rebasing (Pro Git, 2nd edition) — Git project (Chacon and Straub), opened 2026-10-26, 26 Oct 2026
- git-reset Documentation — Git project (manual for Git 2.54.0), opened 2026-10-26, 20 Apr 2026
- git-pull Documentation — Git project, opened 2026-10-26, 26 Oct 2026
- git-reflog Documentation — Git project, opened 2026-10-26, 26 Oct 2026
- Git Basics: Tagging (Pro Git, 2nd edition) — Git project (Chacon and Straub), opened 2026-10-26, 26 Oct 2026
