Git Interview Questions and Answers

Git interviews usually test whether you can work safely in a team codebase.

Typical areas:

• Daily workflow — clone, branch, stage, commit, push, pull, and open pull requests
• History reading — log, diff, status, show, and blame
• Collaboration — merge vs rebase, conflict resolution, pull request hygiene
• Recovery — restore, reset, revert, stash, reflog, cherry-pick, and bisect
• Remote workflow — fetch, pull, push, tracking branches, tags
• CI integration — protected branches, required checks, hooks, signed commits

Most interviews are scenario-based.

Example:

“Your feature branch diverged from main. What do you do?”

A strong answer explains the command and the reason:

“I would first fetch the latest remote state, inspect the branch difference, then either merge or rebase depending on team policy. I would avoid rewriting shared history unless the team explicitly allows it.”

Git questions usually appear inside broader developer interviews, not always as a separate round.

Common prompts:

• “How do you undo a bad commit?”
• “How do you resolve a merge conflict?”
• “When would you use rebase instead of merge?”
• “How do you recover a commit that disappeared?”
• “How do you find which commit introduced a bug?”

A strong candidate does not only list commands. They explain safety:

“Before destructive commands, I check git status, read the branch history, and make sure I am not rewriting commits already shared with the team.”

A realistic Git prep plan should include hands-on mistakes and recovery, not only command memorization.

Best practice drill:

Create a commit, reset it by mistake, then recover it using git reflog. Our Git reflog recovery guide walks through that scenario step by step.

That gives real muscle memory for one of the most valuable Git recovery scenarios.

Core Git skills have not changed much, but modern interviews often connect Git to team workflow and software supply chain practices.

Common topics:

• Trunk-based development and short-lived branches
• Pull request hygiene
• Protected branches and required CI checks
• Merge vs rebase policy
• Squash merge vs merge commit
• Signed commits in security-sensitive teams
• Monorepo workflows
• Sparse checkout and partial clone for large repositories
• Git LFS for large binary assets
• AI-assisted code review, with human ownership still required

The core bar remains the same:

• Keep history readable
• Avoid losing work
• Collaborate without breaking shared branches
• Recover safely when mistakes happen
• Explain trade-offs clearly

Git is a distributed version control system used to track changes in source code and collaborate with other developers.

Important points:

• Git stores project history as commits.
• Each developer has a local repository with history.
• You can commit, branch, inspect history, and compare changes locally.
• Remote platforms such as GitHub, GitLab, and Bitbucket help teams collaborate.
• Git was created by Linus Torvalds for Linux kernel development.

A simple interview answer:

Git is a distributed version control system. It helps developers track code changes, work on branches, collaborate through remotes, and recover previous versions when needed.

A Git repository is a project directory whose changes are tracked by Git.

It contains:

• Your working files
• Git history
• Branches and tags
• Configuration
• Metadata stored inside the .git directory

The .git directory is usually located at the root of the project. It stores Git’s internal database and metadata.

Important distinction:

A strong answer is:

A repository is the tracked project plus Git metadata. The working tree contains files I edit, while the .git directory stores history, branches, and internal objects.

Git is popular because it supports fast local work and team collaboration.

Main benefits:

A practical interview answer:

Git is useful because it lets teams work independently, review changes, merge safely, and recover previous versions when something goes wrong.

Git is powerful, but it has some practical challenges.

Common disadvantages:

• Learning curve — commands like rebase, reset, and reflog can confuse beginners.
• Large binary files — Git is not ideal for frequently changing large binaries unless Git LFS or another strategy is used.
• History rewriting risk — force push or incorrect rebase can disrupt shared branches.
• Merge conflicts — collaboration requires discipline around small changes and frequent sync.
• Repository size — very large repos may need sparse checkout, partial clone, or monorepo tooling.
• Workflow inconsistency — teams need agreed rules for branching, merge strategy, and commit style.

A strong answer is:

Git’s main challenge is not daily commit/push work; it is safe collaboration. Teams need clear workflow rules so rebasing, force pushing, and resolving conflicts do not break shared work.

Git and SVN are both version control systems, but their models are different.

Important clarification:

Git can still be used with a central remote such as GitHub or GitLab, but each developer also has a full local repository.

A strong answer is:

The biggest difference is that Git is distributed while SVN is centralized. Git supports local commits and lightweight branching, while SVN relies more directly on a central server workflow.

Git is mainly written in C, with some supporting scripts and tooling historically written in shell, Perl, and other languages.

Interviewers rarely ask this in modern developer interviews, but the expected answer is simple:

“Git is mainly written in C.”

This question is usually factual. More practical interviews focus on daily workflow, recovery, branching, and collaboration.

Git version control means tracking changes to files over time using commits.

It helps developers:

• See what changed
• See who changed it
• Understand why a change was made
• Compare versions
• Create branches for separate work
• Merge changes from different developers
• Roll back or revert bad changes
• Debug when a bug was introduced

A commit is like a snapshot of the project at a point in time, with metadata such as author, timestamp, and message.

A strong answer is:

Git version control records project history as commits, so a team can collaborate, review changes, recover older versions, and understand how the code evolved.

A simple Git workflow has three main areas:

1. Working tree — files you edit.
2. Staging area / index — changes selected for the next commit.
3. Repository history — committed snapshots.

Typical flow:

Working tree  →  Staging area  →  Commit history
   edit              git add          git commit

Example:

git status
git add file.txt
git commit -m "Update file"

Important terms:

A strong answer is:

I edit files in the working tree, stage the changes I want with git add, and save them into history with git commit.

To start using Git in an existing project directory, run:

git init

This creates a .git directory and starts tracking the project as a Git repository. For a fuller walkthrough, see what git init does and when to use it.

Typical first steps:

git status
git add .
git commit -m "Initial commit"

A strong interview answer is:

I use git init for a new local repository, then stage files with git add and save the first snapshot with git commit.

git clone creates a local copy of an existing remote repository.

Example:

git clone https://github.com/user/project.git

It downloads:

• Project files
• Commit history
• Branch references
• Remote configuration, usually named origin

Important point:

Unlike a simple file download, a cloned Git project is a full local repository. You can create branches, inspect history, commit locally, and then push changes if you have permission. See Git clone command examples for SSH, depth, and branch options.

A strong answer is:

git clone copies an existing repository to my machine and sets up the remote connection so I can fetch, pull, and push changes.

There are two common ways to create a Git repository.

For a new local project:

mkdir my-project
cd my-project
git init

For an existing remote project:

git clone <repository-url>

After git init, Git creates a .git directory where it stores metadata, objects, refs, and configuration.

A strong answer is:

I create a new repository with git init, or I use git clone when the repository already exists on a remote server like GitHub or GitLab.

You can start work in Git in two main ways:

Use git init when the project is already on your machine and you want Git to track it.

Use git clone when the project already exists on GitHub, GitLab, Bitbucket, or another remote server.

A strong answer is:

I use git init for a new local repo and git clone when I need a local copy of an existing remote repo.

git config is used to read and write Git configuration settings.

Common examples:

git config --global user.name "Deepak Prasad"
git config --global user.email "deepak@example.com"
git config --global init.defaultBranch main

Configuration can be set at different levels:

For global username, email, and defaults, see Git config global settings.

A strong answer is:

git config controls Git settings such as username, email, default branch, editor, aliases, and repository-specific behavior.

Use this command to list Git configuration:

git config --list

Useful variants:

git config --global --list
git config --local --list
git config user.name
git config user.email

If you want to see where each setting comes from:

git config --list --show-origin

A strong answer is:

I use git config --list to view current Git settings, and --show-origin when I need to know which config file set a value.

Use git commit -m to create a commit with a message.

git commit -m "Add login form validation"

Good commit messages should explain the purpose of the change, not only the file edited.

Weak message:

git commit -m "changes"

Better message:

git commit -m "Fix login validation for empty email"

A strong answer is:

I use git commit -m for short commit messages, but for larger changes I write a clear subject and body explaining what changed and why.

To push a local repository to GitHub, first create an empty repository on GitHub (getting started with GitHub), then connect your local repo to it.

Typical flow:

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/user/repo.git
git push -u origin main

Important points:

• git remote add origin connects the local repo to the GitHub repo — see Git remote add examples.
• git push -u origin main pushes the branch and sets upstream tracking.
• After upstream is set, future pushes can usually use git push.

A strong answer is:

I commit locally first, add the GitHub repo as a remote, then push my branch to GitHub with upstream tracking.

Use git log with a number.

Example: show the 3 most recent commits:

git log -3

Useful compact format:

git log --oneline -3

A strong answer is:

I use git log -n or git log --oneline -n to see the most recent commits quickly.

To stage means to select changes for the next commit.

Git has three common areas:

Example:

git add login.js
git commit -m "Add login validation"

Why staging is useful:

Suppose you changed two files, but only one change is ready. You can stage and commit only the finished file, while keeping the other file as work in progress. To unstage by mistake, see how to unstage files in Git.

A strong answer is:

Staging lets me choose exactly which changes go into the next commit, so I can keep commits focused and readable.

A Git commit object stores metadata about a snapshot of the project.

It includes:

• Tree reference, which points to the project snapshot
• Parent commit reference or references
• Author name and email
• Committer name and email
• Timestamp
• Commit message

A commit is identified by a commit hash. In many repositories this is shown as a shortened hash such as:

a1b2c3d

A strong answer is:

A commit stores a reference to the project snapshot, parent commit information, author/committer metadata, timestamp, and commit message.

git diff shows changes between different Git states.

Common uses:

git diff

Shows unstaged changes in the working tree.

git diff --staged

Shows staged changes that will go into the next commit.

git diff main feature-branch

Shows differences between two branches.

git diff <commit1> <commit2>

Shows differences between two commits.

For staged, unstaged, and branch comparisons, see Git diff explained with examples.

A strong answer is:

I use git diff to inspect exact line-level changes before staging, committing, reviewing, or comparing branches.

git status shows the current state of the working tree and staging area.

It tells you:

• Current branch
• Files changed but not staged
• Files staged for commit
• Untracked files
• Whether your branch is ahead, behind, or diverged from remote

Example:

git status

Interview use:

Before running risky commands such as reset, rebase, or checkout, check git status.

A strong answer is:

git status is my first safety check. It tells me what changed, what is staged, what is untracked, and whether my branch is in sync with the remote.

git status gives a summary. git diff shows the actual content changes.

Example:

Use git status to see that app.js changed.

Use git diff app.js to see what changed inside app.js.

A strong answer is:

git status tells me what changed at a file level. git diff tells me exactly how the content changed.

git rm removes a file from the working tree and stages the deletion. See Git rm command examples for remove, undo, and --cached usage.

Example:

git rm old-file.txt
git commit -m "Remove old file"

To remove a directory recursively:

git rm -r old-directory

If you want to stop tracking a file but keep it locally, use:

git rm --cached config.local

A strong answer is:

git rm removes a tracked file and stages that deletion. I use git rm --cached when I want Git to stop tracking a file but keep it on disk.

git log shows commit history.

Common uses:

git log
git log --oneline
git log --author="Deepak"
git log --since="2 weeks ago"
git log -- path/to/file

It helps you:

• Review project history
• Find when a change was made
• Search commits by author/date/file
• Understand branch history
• Prepare for debugging or release review

A strong answer is:

I use git log to inspect committed history, understand what changed over time, and find commits related to a bug or feature.

git add moves changes from the working tree to the staging area.

Example:

git add index.html
git commit -m "Update homepage layout"

Why it matters:

• Lets you choose what goes into the next commit
• Helps create focused commits
• Allows partial staging
• Separates editing from committing

Useful command:

git add -p

This stages selected parts of a file interactively.

A strong answer is:

git add prepares changes for commit. It gives me control over what belongs in the next snapshot.

A commit object contains information needed to represent one point in project history.

It includes:

• Reference to a tree object
• Parent commit or commits
• Author
• Committer
• Timestamp
• Commit message

Important distinction:

• The commit does not simply store a loose list of changed files.
• It points to a tree that represents the project snapshot at commit time.

A strong answer is:

A commit object records a project snapshot reference plus metadata such as parent, author, committer, time, and message.

Use git log --pretty or git log --format.

Examples:

git log --pretty=oneline

Custom format:

git log --pretty=format:"%h - %an, %ar : %s"

Example output:

ba72a6c - Dave Adams, 3 years ago : Update version number

Useful compact format:

git log --oneline --graph --decorate

A strong answer is:

I use git log --pretty or --format when I need a custom history view for review, release notes, or debugging.

A commit message explains what changed and why.

A good commit message helps future developers understand project history.

Good commit messages are:

• Clear
• Specific
• Written in imperative style when possible
• Linked to ticket/issue ID if the team uses one
• Focused on the reason, not only the file name

Weak:

fix

Better:

Fix null user check in login flow

See how to write good Git commit messages for team-style examples.

A strong answer is:

A commit message should explain the intent of the change so future reviewers can understand the history without reading every line of diff.

To change the most recent commit message before pushing, use:

git commit --amend -m "New commit message"

Important correction:

The command is --amend, not --ammend. Our Git commit amend guide covers safe use before and after push.

If the commit was already pushed, be careful. Amending rewrites commit history and creates a new commit hash.

For a shared branch, prefer team policy:

• Avoid rewriting shared history unless allowed.
• Use a new commit if safer.
• Coordinate before force pushing.

A strong answer is:

I use git commit --amend for an unpushed commit. If it is already pushed, I avoid rewriting shared history unless the team allows it.

You can use git show with --name-only. See the Git show command guide for commit details, diffs, and file lists.

git show --name-only --pretty="" <commit>

Another option:

git diff-tree --no-commit-id --name-only -r <commit>

Example:

git show --name-only --pretty="" a1b2c3d

A strong answer is:

I use git show --name-only or git diff-tree --name-only to list files changed in a specific commit.

Use git diff with two commit hashes.

git diff <commit1> <commit2>

Example:

git diff a1b2c3d e4f5g6h

To see only file names:

git diff --name-only <commit1> <commit2>

To see a summary:

git diff --stat <commit1> <commit2>

A strong answer is:

I use git diff commit1 commit2 for line-level changes, --name-only for changed files, and --stat for a summary.

A commit can be identified in several ways.

Common ways:

Examples:

git show HEAD
git show HEAD~1
git show v1.0.0
git show origin/main

Relative refs like HEAD~1 are explained in our Git HEAD reference guide.

A strong answer is:

A commit can be referenced by hash, branch, tag, or relative refs like HEAD~1. In daily work, short hashes and branch names are common.

git blame shows which commit last changed each line of a file. See git blame command examples for syntax and practical usage.

Example:

git blame app.js

To inspect a line range:

git blame -L 12,19 app.js

It shows:

• Commit hash
• Author
• Timestamp
• Line content

Useful for:

• Finding when a line changed
• Understanding context before modifying code
• Locating the commit that introduced a behavior
• Asking the right teammate for background

Important interview note:

git blame should be used for context, not blaming people.

A strong answer is:

I use git blame to understand the history of a line before changing it. It helps with context, but it should not be used to shame a developer.

There is no single branching strategy that fits every team.

Common Git branching strategies include:

Modern teams often prefer short-lived feature branches with pull requests, CI checks, and protected main. Our Git workflow guide compares trunk-based, feature-branch, and GitFlow models in more detail.

A strong answer is:

I prefer short-lived feature branches or trunk-based development when CI is strong. GitFlow can still work for release-heavy products, but long-lived branches increase merge conflict risk.

In Git, HEAD usually refers to the current commit checked out in your working tree.

Important distinction:

• HEAD points to your current branch or commit.
• Branch names are references that point to commits.
• A repository can have many branches, but your working tree has one current HEAD.

Example:

git branch
git status

If you switch from main to feature/login, HEAD now points to feature/login.

A strong answer is:

A repository can have many branch heads, but HEAD is the special reference for the current checkout.

Branches let developers work on changes independently without disturbing the main code line.

Common reasons to create branches:

• Build a new feature
• Fix a bug
• Try an experiment
• Prepare a release
• Apply a hotfix
• Review code through a pull request

Example:

git switch -c feature/login-form

Benefits:

• Keeps work isolated
• Makes code review easier
• Reduces risk to main
• Allows multiple tasks in parallel
• Supports CI checks before merge

A strong answer is:

I create branches to isolate work, keep commits focused, and merge only reviewed/tested changes into the main branch.

Common branch types include:

Example names:

feature/login-form
bugfix/cart-total
hotfix/payment-timeout
release/v2.1

A strong answer is:

Branch names should communicate purpose. Teams should also agree on branch lifetime and merge policy.

Use git switch -c to create and switch to a new branch.

git switch -c feature/login-form

See Git branch examples for creating and naming branches.

Older syntax also works:

git checkout -b feature/login-form

To create a branch without switching:

git branch feature/login-form

A strong answer is:

I usually use git switch -c branch-name because it creates the branch and moves me to it in one step.

A safe workflow is:

1. Create a feature branch from latest main.
2. Make changes and commit them.
3. Push the feature branch.
4. Open a pull request.
5. Run CI checks and request review.
6. Resolve feedback and conflicts.
7. Merge into main using the team’s merge policy.

Example:

git switch main
git pull
git switch -c feature/login-form
# make changes
git add .
git commit -m "Add login form"
git push -u origin feature/login-form

A strong answer is:

I do not directly push feature work to main. I use a feature branch, pull request, CI checks, and review before merge.

A pull request is a collaboration workflow used on platforms such as GitHub, GitLab, and Bitbucket.

It lets developers:

• Compare a feature branch with a target branch
• Review code changes
• Discuss comments
• Run CI checks
• Request approval
• Merge the change safely

A pull request is not a core Git command. It is a platform feature built around Git branches and commits.

A strong answer is:

A pull request is a review and integration process around Git changes. It helps teams discuss, test, approve, and merge code safely.

To delete a local branch after it has been merged, use:

git branch -d feature/login-form

The -d option is safe because Git warns you if the branch has unmerged changes.

To delete a remote branch:

git push origin --delete feature/login-form

A strong answer is:

I use git branch -d for a safely merged local branch and git push origin --delete for a remote branch.

To force delete a local branch with unmerged changes, use:

git branch -D feature/old-work

Be careful: this can remove branch work that is not merged elsewhere.

Before force deleting, check:

git log --oneline feature/old-work
git branch --contains feature/old-work

A strong answer is:

I use git branch -D only when I am sure the branch work is no longer needed or is saved somewhere else.

To delete a local branch safely:

git branch -d branch-name

To force delete a local branch:

git branch -D branch-name

To delete a remote branch:

git push origin --delete branch-name

See how to delete Git branches for local -d/-D deletes, remote cleanup, and common errors.

Use -d when the branch is already merged. Use -D only when you intentionally want to discard unmerged branch work.

A strong answer is:

I delete local branches with git branch -d, force delete with -D only when safe, and delete remote branches with git push origin --delete.

Use git switch to move between branches.

git switch main
git switch feature/login-form

Our Git switch vs checkout guide covers modern branch switching and older checkout syntax.

Older syntax:

git checkout main

Before switching, check whether you have uncommitted changes:

git status

If your work is unfinished, commit it, stash it, or move it before switching branches.

A strong answer is:

I use git switch branch-name and check git status first so I do not accidentally carry uncommitted changes into another branch.

Use:

git branch -v

This shows local branches and the latest commit on each branch. See how to list Git branches for local, remote, and merged views.

To include remote branches:

git branch -av

Example output:

feature/login  83b576c Add login form
* main           7b96605 Merge pull request #42
  testing        972ac34 Add test data

A strong answer is:

I use git branch -v to see each local branch with its latest commit, and git branch -av when I also want remote branches.

To list branches already merged into the current branch:

git branch --merged

To check branches merged into main:

git branch --merged main

To list branches not yet merged:

git branch --no-merged main

Remote variants:

git branch -r --merged origin/main
git branch -a --merged main

A strong answer is:

I use git branch --merged main before deleting a branch, and --no-merged to find branches that still contain unmerged work.

A merge conflict happens when Git cannot automatically combine changes from two branches.

Common causes:

• Same lines changed differently in both branches
• One branch deletes a file while another edits it
• Same file renamed differently
• Large formatting changes mixed with logic changes

Example:

<<<<<<< HEAD
const label = "Save";
=======
const label = "Submit";
>>>>>>> feature/button-copy

A strong answer is:

A merge conflict means Git needs human help to decide the final content. I resolve it by understanding both changes, editing the file, staging it, and completing the merge.

A safe conflict resolution process is:

1. Run git status to see conflicted files.
2. Open each conflicted file.
3. Remove conflict markers.
4. Keep the correct final content.
5. Run tests if needed.
6. Stage resolved files.
7. Continue the merge or rebase.

For a merge conflict:

git status
# edit files
git add conflicted-file.js
git commit

For a rebase conflict:

git status
# edit files
git add conflicted-file.js
git rebase --continue

To abort:

git merge --abort
git rebase --abort

Our Git merge conflict resolution guide walks through fast-forward merges, manual fixes, and aborting safely.

A strong answer is:

I resolve conflicts by understanding intent, not by blindly choosing one side. After editing, I stage the file and continue the merge or rebase.

The common alternative to merging is rebasing.

git rebase main

Merge and rebase both integrate changes, but they affect history differently.

See Git merge vs rebase for when teams choose each approach.

A strong answer is:

The alternative to merge is rebase. Merge preserves branch history, while rebase creates a cleaner linear history by replaying commits.

Rebasing means moving or replaying commits from one base commit to another.

Example:

git switch feature/login
git rebase main

This takes commits from feature/login and reapplies them on top of the latest main. For command syntax and conflict handling, see Git rebase explained with examples.

Benefits:

• Cleaner linear history
• Easier commit review
• Avoids unnecessary merge commits in feature branches

Risks:

• Rewrites commit hashes
• Can confuse collaborators if done on shared branches
• Conflicts may need to be resolved during the rebase

A strong answer is:

Rebase is useful for cleaning up local feature branch history, but I avoid rebasing shared public branches unless the team explicitly allows it.

The golden rule is:

Do not rebase commits that other people may already be using.

Rebase rewrites commit history and creates new commit hashes. If others have based work on the old commits, rebasing can create confusion and duplicate-looking history.

Safe use cases:

• Rebase your local feature branch before opening a pull request
• Clean up commits before pushing
• Rebase private branches that only you use

Risky use cases:

• Rebasing main
• Rebasing a shared release branch
• Rebasing a branch other teammates are actively using

A strong answer is:

I rebase private work, not shared history. If a branch is public and used by others, I prefer merge or coordinate carefully.

Interactive rebase lets you edit commit history before sharing or merging a branch.

Common uses:

• Squash multiple small commits
• Reword commit messages
• Reorder commits
• Drop accidental commits
• Split a large commit
• Clean up noisy local history

Example:

git rebase -i HEAD~3

In the editor, you can use actions such as:

pick
reword
edit
squash
fixup
drop

A strong answer is:

I use interactive rebase to clean up my private feature branch before review. I avoid using it on shared history.

Basic command:

git rebase main

Typical workflow:

git switch feature/login
git fetch origin
git rebase origin/main

Interactive rebase:

git rebase -i HEAD~3

Continue after resolving conflicts:

git rebase --continue

Abort a rebase:

git rebase --abort

A strong answer is:

I use git rebase <base-branch> to replay my branch on top of another branch, and git rebase -i when I need to clean up local commits.

ours and theirs are options used during conflict resolution to prefer one side.

During a merge:

• ours = current branch
• theirs = branch being merged in

Example:

git merge -X ours feature/login

This tells Git to prefer the current branch’s changes when conflicts occur.

git merge -X theirs feature/login

This tells Git to prefer the incoming branch’s changes when conflicts occur.

Important caution:

Do not use these options blindly. They can discard meaningful changes from one side.

A strong answer is:

ours means prefer the current branch; theirs means prefer the branch being merged. I use them only when I understand which side should win.

Use a merge strategy option that ignores whitespace changes.

Example:

git merge -X ignore-space-change feature/formatting

Other useful option:

git merge -X ignore-all-space feature/formatting

This is useful when one branch has formatting-only whitespace changes and another branch has logic changes.

Important caution:

Ignoring whitespace can be risky in languages or files where whitespace is meaningful.

A strong answer is:

I can use -X ignore-space-change during merge, but I still review the result because whitespace can be meaningful in some files.

git stash drop removes a stash entry.

List stashes:

git stash list

Drop the latest stash:

git stash drop

Drop a specific stash:

git stash drop stash@{2}

Be careful: dropping a stash deletes that saved work from the stash list.

A strong answer is:

I use git stash drop when I no longer need a saved stash. I check git stash list first so I do not drop the wrong one.

git stash temporarily saves uncommitted changes and gives you a clean working tree. See Git stash explained with examples for apply, pop, and list workflows.

Use it when:

• You need to switch branches quickly
• You are interrupted by an urgent bug
• Your current work is not ready to commit
• You want to pull or rebase with a clean working tree

Example:

git stash push -m "WIP login form"

List stashes:

git stash list

A strong answer is:

git stash is for temporary work-in-progress. I use it when I need a clean working tree but do not want to commit unfinished changes.

To apply the latest stash:

git stash apply

To apply a specific stash:

git stash apply stash@{1}

Difference between apply and pop:

A strong answer is:

I use git stash apply when I want to keep the stash, and git stash pop when I want to apply and remove it.

git reset moves HEAD and can also change the staging area and working tree depending on the mode.

Common modes:

Default reset mode is --mixed. Our Git reset examples compare soft, mixed, and hard modes.

Important warning:

git reset --hard

can permanently discard uncommitted changes.

A strong answer is:

I use git reset to move branch history or unstage changes. I avoid --hard unless I am sure I do not need the local changes.

Use git revert.

Example:

git revert <commit>

git revert creates a new commit that undoes the changes from the selected commit. See Git revert command examples for shared-branch safety.

This is safer for public/shared branches because it does not rewrite history.

Do not use git reset on a public branch unless your team has explicitly agreed to rewrite history.

A strong answer is:

For a pushed public commit, I use git revert because it preserves shared history and creates a new undo commit.

Use interactive rebase. Our how to squash commits in Git guide shows squash and fixup workflows.

Example: squash the last 3 commits:

git rebase -i HEAD~3

In the editor, keep the first commit as pick and change the later commits to squash or fixup.

Example:

pick a1b2c3d Add login form
squash d4e5f6g Fix validation typo
squash h7i8j9k Update button text

Important warning:

Squashing rewrites commit history. Do this on local/private branches, not shared public branches unless the team allows it.

A strong answer is:

I use interactive rebase to squash local commits before review. I avoid squashing commits that other developers already depend on.

Use git clean to remove untracked files from the working tree.

Preview what will be removed:

git clean -n

Remove untracked files:

git clean -f

Remove untracked directories too:

git clean -fd

Remove ignored files also:

git clean -fdx

Important warning:

git clean can permanently delete untracked files. Always run git clean -n first — see Git clean command examples for safe preview flags.

A strong answer is:

I use git clean -n to preview, then git clean -f or -fd only when I am sure the untracked files can be removed.

git cherry-pick applies the changes from an existing commit onto the current branch. See Git cherry-pick examples for backport workflows.

Example:

git switch release/v1.0
git cherry-pick a1b2c3d

Common use cases:

• Backport a bug fix to a release branch
• Apply one commit without merging the full branch
• Move a small fix from one branch to another

Important points:

• Your working tree should be clean before cherry-picking.
• Conflicts may occur and must be resolved.
• Cherry-pick creates a new commit with a different hash.
• It should not replace normal merging for full feature branches.

A strong answer is:

I use cherry-pick when I need one specific commit from another branch, such as backporting a production fix without merging unrelated work.

git pull updates the current branch with changes from a remote branch.

Internally, it usually does two steps:

1. git fetch — downloads commits and updates remote-tracking branches.
2. git merge — merges the fetched branch into your current branch.

See Git fetch vs pull for when to fetch without merging.

In some teams, git pull may be configured to rebase instead of merge.

Equivalent commands:

git fetch origin
git merge origin/main

Or with rebase:

git pull --rebase

Our Git pull --rebase guide explains when teams prefer rebase over merge on pull.

A strong answer is:

git pull fetches remote changes and then integrates them into my current branch, usually by merge or rebase depending on configuration.

git push uploads local commits to a remote repository and updates the matching remote branch or ref. See Git push explained with examples for upstream, rejection, and error handling.

Example:

git push origin main

This sends commits from local main to origin/main if the remote can accept the update.

Important correction:

git push does not do fetch + merge. That describes git pull, not git push.

A push may be rejected if:

• The remote branch has commits you do not have locally
• Branch protection blocks direct push
• Required CI checks failed
• You do not have permission
• Signed commits are required but missing

A strong answer is:

git push transfers my local commits to the remote and updates the remote branch. If the remote has newer commits, I need to fetch/pull first.

git clone and git remote are related but used for different purposes.

Example clone:

git clone https://github.com/user/project.git

Example remote add:

git remote add origin https://github.com/user/project.git

When you clone a repository, Git usually creates a remote named origin automatically.

A strong answer is:

git clone creates a new local repository from a remote. git remote manages remote URLs after a repository already exists.

Use git remote rename.

git remote rename old-name new-name

Example:

git remote rename origin upstream

To verify:

git remote -v

A strong answer is:

I use git remote rename to change the local nickname of a remote. It does not rename the actual repository on GitHub or GitLab.

No. origin is not a branch.

origin is the default name Git gives to the remote repository when you run git clone.

Example:

git remote -v

You may see:

origin  https://github.com/user/project.git (fetch)
origin  https://github.com/user/project.git (push)

Remote-tracking branches look like:

origin/main
origin/feature-login

Important distinction:

A strong answer is:

origin is the default remote name, not a branch. origin/main is a remote-tracking branch.

Use a credential helper, SSH key, or platform-specific authentication tool.

Common options:

git config --global credential.helper cache

This caches credentials temporarily in memory.

On many systems, Git Credential Manager or OS keychain storage is preferred:

git config --global credential.helper manager

For GitHub and similar platforms, use:

• Personal access token for HTTPS
• SSH key authentication
• GitHub CLI or credential manager

Important:

Do not store plain-text passwords in scripts or repository files.

A strong answer is:

I use SSH keys or a credential manager so Git can authenticate securely without asking for credentials on every push.

Git can transfer data using several protocols.

Common protocols:

In modern hosted workflows, HTTPS and SSH are the most common.

A strong answer is:

Git supports local, HTTPS, SSH, and Git protocol URLs. In daily work, I mostly use HTTPS with a token/credential manager or SSH keys.

The Git protocol is a native Git transfer protocol that usually runs on port 9418.

It was designed for fast transfer, but it does not provide authentication by itself.

Because of that, modern teams usually prefer:

• HTTPS
• SSH
• Hosted Git platforms with access control

A strong answer is:

The Git protocol is a native transfer protocol, but because it lacks authentication, HTTPS and SSH are more common for real team repositories.

If you do not have push access, use a fork-based workflow.

Important correction:

There is no standard git fork command. Forking is usually a feature of platforms such as GitHub, GitLab, or Bitbucket.

Typical flow:

1. Fork the repository on the hosting platform.
2. Clone your fork.
3. Create a feature branch.
4. Push to your fork.
5. Open a pull request to the original repository.

Example:

git clone https://github.com/your-user/project.git
cd project
git remote add upstream https://github.com/original/project.git
git switch -c fix/readme

A strong answer is:

If I do not have push access, I fork the repository, push changes to my fork, and open a pull request to the upstream project.

Git hooks are scripts that run automatically when certain Git events happen.

Examples:

Common uses:

• Run formatters
• Run lint checks
• Validate commit messages
• Block secrets from being committed
• Enforce server-side policies
• Trigger notifications or deployment steps

A strong answer is:

Git hooks automate checks around commits and pushes. Local hooks help developers catch issues early, while server-side hooks enforce team-wide rules.

Git hooks can be written in any language that can run as an executable script on the machine.

Common choices:

• Shell script
• Python
• Perl
• Ruby
• Node.js
• PowerShell

The file must be executable and placed in the correct hook path.

Example:

chmod +x .git/hooks/pre-commit

A strong answer is:

Hooks are executable scripts. They are often shell scripts, but they can be written in Python, Node.js, Perl, or any language available in the environment.

Git protects repository integrity using content hashes.

Important correction:

Git does not encrypt your source code by default. Hashing is not encryption.

Git uses hashes to identify objects and detect accidental or malicious changes to stored history.

Repository security also depends on:

• Access control on the Git server
• SSH keys or token-based authentication
• Branch protection rules
• Required reviews
• Required CI checks
• Signed commits or tags in stricter environments
• Secret scanning and dependency scanning

A strong answer is:

Git hashes objects to protect integrity, but access security comes from the hosting platform, authentication, branch protection, reviews, and CI policies.

Use a pre-commit hook for fast local checks.

Common checks:

• Formatting
• Linting
• Secret scanning
• Basic unit tests
• Commit size checks

Example flow:

Developer runs git commit
→ pre-commit hook runs checks
→ commit succeeds only if checks pass

For heavier tests such as integration tests, UAT, browser tests, or deployment checks, CI is usually better than a local pre-commit hook.

A strong answer is:

I use pre-commit hooks for fast checks and CI for heavier validation. Hooks improve feedback, but CI remains the source of truth for team-wide enforcement.

Use server-side hooks or CI/CD.

Git server-side hooks include:

• pre-receive
• update
• post-receive

Use cases:

In modern hosted platforms, CI/CD pipelines often replace custom server hooks for tests and deployments.

A strong answer is:

For push-time automation, I can use server-side hooks or CI/CD. I use hooks for repository policy and CI for build, test, and deployment workflows.

These are server-side hooks that run during a push.

Example:

• Use pre-receive to block commits without ticket IDs.
• Use update to protect a specific branch.
• Use post-receive to notify a chat channel.

A strong answer is:

pre-receive can reject the whole push, update runs per ref, and post-receive runs after acceptance for follow-up actions.

Git hooks normally live in the local .git/hooks directory, and they are not automatically shared when someone clones the repository.

To share hook logic across a team, common approaches are:

• Store hook scripts in the repository under a directory such as .githooks/
• Configure core.hooksPath
• Use tools such as Husky, Lefthook, or pre-commit
• Enforce critical checks in CI or server-side hooks

Example:

git config core.hooksPath .githooks

Important point:

Local hooks are helpful, but they can be skipped or missing. Critical rules should also run in CI or server-side enforcement.

A strong answer is:

Hooks can be versioned in the repo, but local hooks are not automatically shared by default. For reliable enforcement, I combine shared hook setup with CI or server-side checks.

HEAD is Git’s reference to the currently checked-out commit.

Usually, HEAD points to the current branch.

Example:

cat .git/HEAD

Output may look like:

ref: refs/heads/main

If you checkout a specific commit instead of a branch, you enter a detached HEAD state.

A strong answer is:

HEAD points to what I currently have checked out. Usually it points to a branch, but it can point directly to a commit in detached HEAD state.

rerere means reuse recorded resolution.

It lets Git remember how you resolved a conflict. If the same conflict appears again, Git can reuse your previous resolution.

Enable it:

git config --global rerere.enabled true

Useful when:

• You repeatedly rebase a long-running branch
• You resolve the same conflicts multiple times
• You work on release branches with repeated backports

A strong answer is:

git rerere records conflict resolutions and reuses them when the same conflict appears again.

Common git diff commands are:

--cached is another name for --staged.

Example:

git diff --staged

A strong answer is:

I use git diff before staging, git diff --staged before committing, and git diff HEAD to see all uncommitted changes.

Git is flexible because it supports many workflows and history operations.

Examples:

• Local commits without network access
• Lightweight branching
• Merging and rebasing
• Tags for releases
• Stash for temporary work
• Cherry-pick for selective commits
• Worktrees for multiple working directories
• Hooks for automation
• Remote workflows with multiple remotes

This flexibility supports different team styles:

• Trunk-based development
• Feature branch workflow
• Release branches
• Fork-based open source workflow

A strong answer is:

Git is flexible because it supports local history, cheap branches, multiple remotes, tags, hooks, and different collaboration workflows.

git commit --amend rewrites the most recent commit and creates a new commit hash.

This is fine for local, unpushed commits.

But if the commit is already pushed and shared, amending it can disrupt other developers because their history still points to the old commit.

Use an additional commit when:

• The commit is already public
• Other developers may have pulled it
• The branch is protected
• You want an auditable fix

Use amend when:

• The commit is local
• You are only fixing the last commit message or small mistake
• No one else depends on it

A strong answer is:

I amend local commits, but for shared commits I usually create a new commit to avoid rewriting public history.

A bare repository is a Git repository without a working tree.

Create one with:

git init --bare

In a normal repository, Git metadata is stored in .git/.

In a bare repository, the repository metadata is stored directly in the repository directory.

Bare repositories are commonly used as shared remote repositories because no one edits files directly inside them.

A strong answer is:

A bare repository stores Git history but has no checked-out working files. It is useful as a remote repository that developers push to and fetch from.

Use git bisect.

git bisect uses binary search to find the commit that introduced a bug.

Typical flow:

git bisect start
git bisect bad
git bisect good <known-good-commit>

Git checks out a commit between good and bad. You test it and mark it:

git bisect good
# or
git bisect bad

When finished:

git bisect reset

A strong answer is:

I use git bisect when I know one commit is good and a later commit is bad. Git narrows the range until it finds the commit that introduced the bug.

Git uses refs.

A branch is a reference stored under:

.git/refs/heads/

HEAD usually points to the current branch.

Example:

cat .git/HEAD

Output:

ref: refs/heads/main

The branch ref then points to the latest commit on that branch.

Example:

cat .git/refs/heads/main

A strong answer is:

HEAD points to the current branch, and that branch ref points to the latest commit hash for the branch.

Git has two main types of tags.

Create a lightweight tag:

git tag v1.0.0

Create an annotated tag:

git tag -a v1.0.0 -m "Release v1.0.0"

See Git tag tutorial for create, push, delete, and release tagging.

Push a tag:

git push origin v1.0.0

A strong answer is:

Lightweight tags are simple pointers. Annotated tags store extra metadata and are better for official releases.

Use interactive rebase.

Example: reorder the last 4 commits:

git rebase -i HEAD~4

In the editor, reorder the pick lines.

Example:

pick a1b2c3d Add API endpoint
pick d4e5f6g Add frontend form
pick h7i8j9k Add validation
pick k1l2m3n Add tests

Important warning:

Reordering commits rewrites history. Do this on private/local branches, not shared public branches unless your team agrees.

A strong answer is:

I use interactive rebase to reorder local commits before review. I avoid rewriting shared branch history.

Use interactive rebase.

Typical flow:

git rebase -i HEAD~3

Mark the commit to split as edit.

When Git stops at that commit:

git reset HEAD~1

Now the changes are back in the working tree. Stage and commit them in smaller pieces:

git add part1.js
git commit -m "Add first part"

git add part2.js
git commit -m "Add second part"

Then continue:

git rebase --continue

A strong answer is:

I split a commit with interactive rebase by stopping at the commit, resetting it, then staging and recommitting the changes in smaller logical pieces.

git filter-branch is an older command used to rewrite Git history across many commits.

It can be used for tasks such as:

• Removing a file from history
• Rewriting author information
• Changing paths across history

However, modern Git interviews should mention that filter-branch is generally discouraged for new work because it is slow and easy to misuse.

Preferred modern options:

• git filter-repo
• BFG Repo-Cleaner for removing large files or secrets
• For legacy workflows, see how to reduce Git repo size with filter-branch — but prefer modern tools for new work

Important warning:

History rewriting affects commit hashes. If the repository is shared, coordinate carefully and rotate any leaked secrets. Removing a secret from Git history does not make the secret safe again.

A strong answer is:

filter-branch rewrites history, but today I would usually use git filter-repo or BFG. For leaked secrets, I would also rotate the secret, not only remove it from history.

Git commonly works with three trees:

Typical flow:

Working tree  →  Index  →  HEAD
   edit          git add   git commit

Useful commands:

See Git restore explained with examples for unstaging and undoing file changes.

A strong answer is:

The working tree contains my current files, the index contains what I plan to commit, and HEAD points to the last committed snapshot.

SubGit is a tool used for SVN-to-Git migration and synchronization.

It can create a Git mirror of a Subversion repository and keep Git and SVN history synchronized during a migration period.

Common use cases:

• Migrating from SVN to Git
• Running Git and SVN in parallel temporarily
• Creating a two-way bridge while teams move gradually to Git

Interview-level answer:

“SubGit is mainly used when an organization is migrating from SVN to Git and needs both systems to stay synchronized for some time.”

This is a niche topic. Most modern Git interviews focus more on daily Git workflow, branching, conflict resolution, and recovery.

git instaweb starts a local web interface for browsing a Git repository.

It sets up gitweb with a small local web server so you can view repository history in a browser.

Example:

git instaweb

To stop it:

git instaweb --stop

Use cases:

• Browse commit history locally
• Demo repository history without a hosted platform
• Inspect a repo with a simple web UI

Modern note:

Most teams use GitHub, GitLab, Bitbucket, IDE Git views, or desktop Git clients instead. So git instaweb is useful to know, but not a high-priority interview topic.

A strong answer is:

git instaweb launches a local web view of a Git repository using gitweb. It is useful for local browsing, but hosted platforms are more common in daily work.

Many developers use Git from the command line, but GUI tools are also common.

Popular Git GUI options include:

• GitHub Desktop
• GitKraken
• Sourcetree
• Fork
• Tower
• SmartGit
• Git Extensions
• VS Code Git integration
• IntelliJ IDEA / WebStorm Git integration

A good interview answer should not depend on one tool.

A strong answer is:

I am comfortable with Git CLI for core operations, but I also use IDE or GUI tools for visual diffs, conflict resolution, and reviewing history.

git tag is used to mark important points in repository history, commonly releases.

Common commands:

git tag
git tag v1.0.0
git tag -a v1.0.0 -m "Release v1.0.0"
git push origin v1.0.0
git push origin --tags

Git has two common tag types:

Annotated tags are usually preferred for official releases.

A strong answer is:

I use tags to mark release points. Lightweight tags are simple labels, while annotated tags include metadata and are better for releases.

git shortlog summarizes commit history, usually grouped by author.

It is useful for:

• Release notes
• Contributor summaries
• Reviewing who contributed what
• Summarizing commits between versions

Examples:

git shortlog
git shortlog -sn
git shortlog v1.0.0..v1.1.0

Common options:

A strong answer is:

git shortlog gives a release-friendly summary of commit history, often grouped by author.

git co is usually a Git alias. The built-in command is git checkout — see our Git checkout command guide for branch, commit, and file checkout patterns.

You can create aliases with git config.

Example:

git config --global alias.co checkout

After that, this works:

git co main

Common aliases:

git config --global alias.st status
git config --global alias.br branch
git config --global alias.cm commit
git config --global alias.lg "log --oneline --graph --decorate"

A strong answer is:

git co is not a built-in Git command by default. It works when someone has configured it as an alias for git checkout.

git grep searches for a string or regular expression in tracked Git files.

Example:

git grep "TODO"

Search with line numbers:

git grep -n "handleLogin"

Search in a specific commit or branch:

git grep "oldFunction" HEAD~1
git grep "apiUrl" main

Why use it:

• Fast code search inside a repository
• Can search committed trees, not only current files
• Useful during debugging and refactoring

A strong answer is:

git grep searches tracked files or a specific Git tree for text patterns. I use it when I want Git-aware code search.

A Git submodule lets you keep one Git repository inside another Git repository.

The parent repository stores a pointer to a specific commit of the submodule.

Common use cases:

• Shared library used by multiple projects
• Vendor dependency that must be pinned to a specific commit
• Keeping separate repositories while composing them together

Add a submodule:

git submodule add https://github.com/user/library.git libs/library

Clone a repository with submodules:

git clone --recurse-submodules <repo-url>

Initialize submodules after cloning:

git submodule update --init --recursive

Important trade-off:

Submodules give clear version pinning, but they add workflow complexity. Developers must remember to update, initialize, and commit submodule pointer changes.

A strong answer is:

A submodule is a repository inside another repository, pinned to a specific commit. It is useful for shared dependencies, but it adds extra workflow steps.