In this article
Before you start
This page is one step of the DevOps and cloud interview learning path. It teaches the commands in the order a working day uses them.
Why interviewers ask this
A mistyped Git command can erase uncommitted work or rewrite shared history, so Git questions test judgement as much as memory. A strong answer shows you know which command changes which area, which are safe on shared branches, and how to recover from a mistake.
See also version control systems and Git DevOps interview questions. A weak answer lists commands: "add, commit, push, pull." A strong answer explains what each command moves, and why the order matters. A Staff-level answer adds the failure modes: what git pull does when branches have diverged, why you do not rewrite pushed history, and how you would undo a bad merge without losing a teammate's work. Delivery pipelines, such as those run by Jenkins, are commonly triggered by Git changes, and Kubernetes configuration files are usually kept in Git too.
Git commands from first principles
- Commit
- A commit is a saved snapshot of every tracked file in a project, stored in the repository with a message, an author and a link to its parent commit (two for a merge commit, none for the first), so the history of a project is a chain of snapshots that you can return to at any time.
- Staging area
- The staging area is the place where Git holds the changes you have chosen for your next commit, sitting between your working files and the repository, so a commit can contain some of your edits and leave the others out.
- Branch
- A branch is a movable name that points at one commit; when you commit while on it, the name moves forward to the new commit, so creating a branch is cheap and copies no files.
In plain words
Think of a photo shoot. Your working files are the set, where you rearrange things freely. The staging area is the frame you arrange before pressing the shutter: only what is in the frame goes into the picture. A commit is the saved photograph, and the repository is the album of every photograph so far. The analogy breaks in one place. Git photographs your whole project each time, but it stores unchanged files only once, so the album stays small.
In one precise sentence: Git stores a project as a chain of snapshots. A handful of commands move changes between your files, the staging area, the repository and other copies of it.
Step 1: Three areas hold your files
The Pro Git book describes three states for a file: modified, staged and committed. They map onto three areas: the working tree (your files on disk), the staging area, and the Git directory. A repository is the .git folder inside a project, which stores every commit and the pointers into them.
Input: the files you edit. Output: nothing yet, since editing changes only the first area. Run git status to see which files are modified and which are staged; it changes nothing, so it is safe to run at any time. Run git init once in a folder to create a new repository there, or git clone <address> to copy an existing one together with its history. Before your first commit, tell Git who you are with git config --global user.name "Your Name" and git config --global user.email "you@example.com"; every commit records them. You now know where everything lives, which is all the next step needs.
Step 2: add and commit move changes into history
git add <file> copies the current version of a file into the staging area. git commit -m "message" turns everything in the staging area into a new commit and moves the current branch forward to it. Input: staged changes and a message. Output: one new commit.
The two-command split is deliberate. If you changed a login page and also fixed an unrelated typo, you stage and commit them separately, so each commit tells one story and can be undone alone. git diff shows edits that are not staged yet, and git diff --staged shows what the next commit will contain. git log lists the history, newest first, and git log --oneline prints one line per commit. git restore <file> goes the other way: it copies a file back from the staging area (or from a commit, with --source) into your working files. You now know how history grows: one commit at a time, from what you staged.
Step 3: Branches let work diverge and merge back
Create a branch with git branch <name>, move onto it with git switch <name>, or do both with git switch -c <name>. The older git checkout <name> also changes branch, but it has several other jobs, which is why newer commands such as git switch and git restore split them apart. The name HEAD is the pointer to the commit or branch you currently have checked out, so a new commit is added where HEAD points. In short, a branch is a movable pointer to a commit, stored inside the repository.
To bring two lines of work together, switch to the target and run git merge <name>. If the target has no new commits of its own, Git does a fast-forward: it simply moves the branch pointer ahead and creates no new commit. If both sides have new commits, Git creates a merge commit with two parents. If both sides changed the same lines, Git stops and asks you to resolve the conflict by editing the file, then staging and committing it.
Step 4: Remotes share history with other copies
A remote is another copy of the repository, usually on a server, that you exchange commits with. Git is the tool and GitHub is one company's hosting service for such copies; the commands work with any remote. git push sends your commits to a remote branch. git fetch downloads new commits from it without changing your current branch. git remote add origin <address> links a remote to your repository, and git remote -v lists the remotes you have.
git pull is the two-in-one: according to the git-pull manual, it first runs git fetch and then integrates the fetched branch into your current one, and --rebase makes the second half a rebase while --no-rebase makes it a merge. A vendor tutorial describes the fetch-then-merge default. Input: remote commits. Output: an updated local branch. Since Git 2.33.1 (2021), with no pull.rebase or pull.ff setting, a pull fast-forwards when it can and stops with an error if the branches have diverged, asking you to choose merge or rebase; older Git merged by default.
Step-by-step description
- Files, staging area and repository.
- Changes move into history and back.
- A branch points at a commit.
- Push out, fetch and pull back.
- Git add copies changes into the staging area.
- Git commit saves the staged snapshot into the repository.
- Git restore copies a file back from the staging area or a commit into your working files.
- A branch is a movable pointer to a commit.
- A remote is another copy of the repository; push sends commits to it and fetch brings them back.
Quick reference: the commands in one table
The quick reference below lists the git commands from the steps above, plus a few more you will meet in daily work, and names the area each one changes: working files, staging area, repository or remote. Commands that only report change nothing at all, and the commands that rewrite history are marked unsafe on branches other people share, so check that column before you run one. Read the table once now, then use it as a lookup while you work.
| Command | What it does | Area it changes | Safe on shared branches? |
|---|---|---|---|
git config --global user.name / user.email | Sets the name and email stored in your commits | Git settings | Yes |
git init, git clone | Creates a repository, or copies one with its history | Repository, working files | Yes |
git status, git diff, git log, git show | Reports state, differences, history or one commit | None | Yes |
git add | Stages the current version of a file | Staging area | Yes |
git commit | Saves staged changes as a new commit | Repository | Yes |
git commit --amend | Replaces the last commit with a new one | Repository | No, once pushed |
git branch, git switch | git branch <name> creates a branch; git switch <name> changes to it (-c does both) | Branch pointer, working files | Yes |
git merge | Joins two lines of work | Repository, working files | Yes |
git rebase | Replays commits on another base | Repository | No, for shared commits |
git cherry-pick | Copies one commit onto the current branch as a new commit | Repository | Yes |
git tag | Names a commit | Repository | Yes |
git rm, git mv | Deletes or renames a tracked file and stages that change | Working files, staging area | Yes |
git restore | Copies a file back from the staging area or a commit | Working files | Yes, local only |
git reset | Moves the branch pointer; modes also reset staging and files | Repository, staging area, files | No, after push |
git revert | Adds a commit that undoes an earlier one | Repository | Yes |
git stash | Shelves uncommitted changes | Working files, staging area | Yes, local only |
git remote add, git remote -v | Links a remote or lists remotes | Git settings | Yes |
git fetch, git pull | Downloads commits; pull also integrates them | Repository (pull: files too) | Yes |
git push | Sends commits to a remote branch | Remote | Yes, but never a forced push over others' work |
git reflog | Lists where HEAD has been | None | Yes |
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 →Worked example
The numbers below come from a small model of a repository, not from a real project, so treat every value as illustrative.1 Start with three commits on the main branch, whose files hold the contents "one", "two" and "three" in turn. Now run git reset back to the second commit in each of its three modes. The git-reset manual describes the modes: --soft leaves the staging area and files alone, --mixed (the default) resets the staging area, and --hard resets both the staging area and the files.
| Mode | Branch pointer | Staging area holds | Files hold |
|---|---|---|---|
--soft | second commit | "three" | "three" |
--mixed | second commit | "two" | "three" |
--hard | second commit | "two" | "two" |
In the model, a git revert of the third commit instead leaves the branch with 4 commits, the fourth holding "two", so no history is lost.1
Now count commits for the two ways of combining work. Main has 3 commits, then gets 1 more of its own while a feature branch gets 2. A merge leaves 7 commits reachable from the result, because the merge commit is added. A rebase replays the two feature commits on top of main's new commit and leaves 6; the two old feature commits are no longer reachable from the branch. In short, a merge adds one merge commit; a rebase adds none. If main had gained nothing, a fast-forward would leave 5 and create no merge commit.1
| Case | Commits reachable afterwards | New merge commit |
|---|---|---|
| Fast-forward (main had no new commits) | 5 | no |
| Merge (both sides have new commits) | 7 | yes, 1 |
| Rebase then fast-forward | 6 | no |
Text description of the diagram
- A merge leaves 7 commits reachable.
- A rebase leaves 6 commits reachable.
- A merge adds one merge commit; a rebase adds none.
Trade-offs and edge cases
Merge and rebase trade history accuracy against readability. A merge records what really happened, including when lines of work joined. A rebase gives a straight line that is easier to read, but it creates new commits in place of the old ones. That is safe for commits only you hold and risky for commits others already pulled, because their copies still contain the old commits. The usual rule is to rewrite only history you have not shared.
The same rule decides how to undo. git restore <file> throws away edits to a file in your working tree. git reset moves the branch pointer and rewrites history. git revert <commit> adds a new commit that undoes an old one, so it is the choice after you have pushed.
Text description of the diagram
- Git restore discards edits to files in your working tree.
- Git reset moves the branch pointer and rewrites history.
- Git revert adds a new commit that undoes an earlier one, so it suits shared history.
git stash shelves uncommitted changes so you can switch branches, and git stash pop brings them back. Two edge cases matter. First, the behaviour of a bare git pull depends on your setup. In Git 2.33.1 and later, with neither pull.rebase nor pull.ff set, git pull fast-forwards when it can and stops with an error when the branches have diverged, asking you to choose merge or rebase; the v1.8.1.1 manual shows the older default, fetch followed by merge. Second, git reset --hard cannot bring back edits that were never committed, so commit or stash first. Commits lost to a reset can usually be found again with git reflog, which lists where HEAD has been, as the git-reflog manual describes.
How to answer it in an interview
Walk me through the main git commands and what they do.
Git keeps three areas: my working files, a staging area and the repository. I edit files, run git add to stage the changes I want, and git commit to save them as a snapshot. Branches are pointers to commits, so I switch branches freely and bring work together with merge or rebase. I share with push and fetch, and pull is fetch plus an integration step. To undo, I use revert on shared commits and reset only on local ones.
The spoken structure: name the three areas, walk a change through them, then branches and remotes, and finish with the one safety rule about undoing.
Common mistakes
- "
git addsaves my work." (wrong) It only stages a change. (right) "git addstages, andgit commitsaves the snapshot." - "
git pulljust downloads." (wrong) It also integrates the fetched commits into your current branch. (right) "git fetchdownloads;git pullfetches and then merges or rebases." - "Undo a pushed commit with
git reset --hard." (wrong) That rewrites history others may have. (right) "I usegit revertso the history stays intact." - "Git and GitHub are the same thing." (wrong) GitHub is a hosting service. (right) "Git is the version control tool; GitHub hosts remotes."
- "
git checkoutis the only way to switch branches." (wrong)git switchdoes that one job. (right) "I usegit switchfor branches andgit restorefor files."
Follow-up questions
What is the difference between git fetch and git pull?
git fetch only downloads new commits from a remote. git pull runs git fetch and then integrates the result into your current branch, by merge or rebase depending on options and settings, as the git-pull manual describes.
What is the difference between git merge and git rebase?
A merge joins two lines with a new commit and keeps both histories. A rebase replays your commits on top of another branch, giving a straight history but new commits, so do not rebase commits that others already have.
What is the difference between git reset and git revert?
git reset moves the branch pointer back and rewrites history; git revert adds a new commit that cancels an earlier one. Use revert on shared branches.
How do you undo the last commit?
If it is still local, git reset --soft HEAD~1 removes the commit and keeps its changes staged. If it is already pushed, git revert HEAD adds an undoing commit instead.
What does git pull do by default?
In current Git, with no pull.rebase or pull.ff setting, git pull fetches and fast-forwards if it can; if your branch has diverged it stops and asks you to choose --rebase or --no-rebase. Git before 2.33.1 merged by default.
- Most git commands move changes between working files, the staging area, the local repository and a remote; a few, such as
git status, only report. git addstages andgit commitsaves; two steps let a commit hold one story.- A branch is a movable pointer, and a fast-forward only moves it.
git pullis fetch plus an integration step, and current Git stops when the branches have diverged.- Revert shared history, and reset only what is still local.
Sources
- Pro Git, Getting Started: What is Git? — Git project (Pro Git book), 1 Jan 2014
- git-reset Documentation — Git project, 20 Apr 2026
- git-pull Documentation — Git project, 29 Jun 2026
- git-pull manual at release v1.8.1.1 — Git project on GitHub, 1 Jan 2013
- Git 2.33.1 release notes — Git project on GitHub, 12 Oct 2021
- git-reflog Documentation — Git project, 26 Oct 2026
- git pull, Atlassian Git Tutorial — Atlassian, 26 Oct 2026
