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.”

A strong answer is:

Git interviews test whether I can collaborate safely: inspect history, create focused commits, work with branches and remotes, resolve conflicts, and recover from mistakes without damaging shared history.

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 strong answer is:

Git questions usually appear inside the technical or coding rounds. I expect basic workflow questions first, then scenarios around merge versus rebase, conflicts, undoing changes, remotes, and recovering lost work.

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.

A strong answer is:

I would practise Git hands-on: normal commit and branch workflows first, then deliberately create conflicts and mistakes so I can demonstrate merge, rebase, reset, revert, reflog, and bisect rather than only define them.

What interviewers are testing: Whether you know modern team practices—protected branches, signed commits, monorepos—without losing sight of safe daily collaboration.

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

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

A strong answer is:

Modern Git interviews still test readable history and safe collaboration—I know branch protection and signed commits matter, but I lead with how I avoid losing work and breaking shared branches.

What interviewers are testing: Whether you understand Git's distributed model and can distinguish Git itself from hosting platforms such as GitHub.

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 strong answer is:

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.

What interviewers are testing: Whether you can separate the working tree, staging area, and committed history from the .git metadata directory.

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.

What interviewers are testing: Whether you can name practical Git benefits—local commits, branching, speed, and recovery—not just buzzwords.

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.

A strong answer is:

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

What interviewers are testing: Whether you recognize Git's real-world trade-offs: learning curve, binary files, history rewriting, and workflow discipline.

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.

What interviewers are testing: Whether you compare Git and SVN by workflow model—distributed versus centralized—not only by vague performance claims.

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 local repository with full history in a normal clone.

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.

What interviewers are testing: Whether you know the factual implementation detail without overstating its interview importance.

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.

A strong answer is:

“Git is mainly written in C.”

What interviewers are testing: Whether you explain version control as tracked history with commits, not merely file backup.

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.

What interviewers are testing: Whether you understand the working tree, index, and repository as three distinct states in the commit workflow.

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.

What interviewers are testing: Whether you can start version control in an existing project with git init, staging, and an initial 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 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.

What interviewers are testing: Whether you know what git clone copies locally and when shallow or partial clones intentionally fetch less data.

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:

A normal clone creates a local repository with its own Git history and remote-tracking refs. Shallow or partial clone options can intentionally download less history or object data. See Git clone 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.

What interviewers are testing: Whether you can choose between git init for a new repo and git clone for an existing remote project.

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.

What interviewers are testing: Whether you know the two common entry paths—initialize locally or clone an existing remote repository.

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.

What interviewers are testing: Whether you understand git config scopes and why identity settings matter for commit attribution.

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.

What interviewers are testing: Whether you can inspect effective Git configuration and trace a setting back to its source file.

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.

What interviewers are testing: Whether you write commit messages that explain intent, not only which files changed.

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.

What interviewers are testing: Whether you can connect an existing local repository to GitHub without unnecessary re-initialization.

To push a local repository to GitHub, first create an empty repository on GitHub (getting started with GitHub).

If the project is not already a Git repository, initialize and commit it first:

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

Then connect the GitHub repository as a remote and push:

git remote add origin https://github.com/user/repo.git
git branch -M main
git push -u origin main

If the project is already a local Git repository with commits, skip git init and the initial commit—add the remote and push instead.

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.

What interviewers are testing: Whether you can limit git log output to recent history with practical formatting options.

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.

What interviewers are testing: Whether you understand staging as selecting changes for the next commit rather than saving immediately.

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.

What interviewers are testing: Whether you can describe what a commit object stores—tree, parents, author, committer, and message.

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 identity and date
• Committer identity and date
• 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 identity and dates, and commit message.

What interviewers are testing: Whether you know how to inspect unstaged, staged, and committed changes before making or reviewing a commit.

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.

What interviewers are testing: Whether you use git status as a safety check before risky operations such as reset or rebase.

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.

What interviewers are testing: Whether you know when a summary (status) is enough and when line-level detail (diff) is required.

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.

What interviewers are testing: Whether you understand git rm versus untracking a file with --cached.

git rm removes a file from the working tree and stages the deletion. See Git rm 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.

What interviewers are testing: Whether you can use git log to investigate history by author, date, path, or branch.

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.

What interviewers are testing: Whether you understand why git add separates editing from committing and enables focused commits.

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.

What interviewers are testing: Whether you know that a commit records both who wrote the change and who created the commit object, and when those identities can differ.

Every commit stores two identities:

They are usually the same person on a normal local commit.

They can differ when someone else applies the change, such as:

• Applying a patch with git am
• Cherry-picking or rebasing commits
• Maintainers committing work from another contributor

Example:

git log -1 --format='author: %an <%ae>%ncommitter: %cn <%ce>'

A strong answer is:

The author wrote the change; the committer created the commit object. They match on ordinary commits but can differ after cherry-pick, rebase, or patch application.

What interviewers are testing: Whether you can format git log output for reports or release notes using --pretty and --format.

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.

What interviewers are testing: Whether you know what makes a commit message useful for future reviewers and release archaeology.

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.

What interviewers are testing: Whether you understand that amending rewrites the commit and therefore becomes risky once that history has been shared.

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 when the team allows history rewriting.

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.

What interviewers are testing: Whether you can list files touched by a specific commit using git show or related commands.

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.

What interviewers are testing: Whether you can compare two commits or branches with git diff to review integration risk.

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.

What interviewers are testing: Whether you know multiple ways to reference a commit—hash, branch, tag, and relative refs like HEAD~1.

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.

What interviewers are testing: Whether you use git blame for line history context without turning it into a personal attack.

git blame shows which commit last changed each line of a file. See git blame 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.

What interviewers are testing: Whether you can compare common branching models and explain which fits a team's release cadence.

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.

What interviewers are testing: Whether you distinguish HEAD as the current checkout from the many branch refs that name commit tips.

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.

What interviewers are testing: Whether you can justify branching for isolated work, review, and safer integration into mainline branches.

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.

What interviewers are testing: Whether you know that feature, release, and hotfix branch names are workflow conventions—not separate Git branch types.

Git does not technically distinguish feature, release, hotfix, or bugfix branches—they are ordinary refs. These names describe workflow conventions used by teams.

Common branch naming conventions 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.

What interviewers are testing: Whether you can create and switch branches with modern git switch syntax safely.

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.

What interviewers are testing: Whether you can describe a feature-branch workflow with explicit remote/upstream updates before branching.

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.

Update main according to the team's pull or rebase policy before creating the feature branch.

Example:

git switch main
git pull --ff-only origin main
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.

What interviewers are testing: Whether you understand pull requests as platform review workflows built on Git branches, not a core Git command.

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.

What interviewers are testing: Whether you can safely delete merged local and remote branches with the right commands.

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.

What interviewers are testing: Whether you understand -d versus -D and why force-deleting an unmerged branch is dangerous.

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.

What interviewers are testing: Whether you know a safer way to update a rewritten remote branch without blindly overwriting a teammate's newer commits.

Both commands can replace remote branch history, but --force-with-lease checks that the remote ref still has the value Git expects before overwriting it. If another developer pushed new commits that you have not incorporated, the push is rejected instead of blindly replacing their work.

git push --force-with-lease origin feature/login

It is commonly used after intentionally rebasing a private feature branch that has already been pushed. It is still history rewriting, so team policy matters. See Git push force examples for lease-based updates versus plain --force.

A strong answer is:

If I intentionally rewrite a pushed feature branch, I prefer --force-with-lease over --force because it refuses to overwrite unexpected remote updates. It reduces the chance of deleting a teammate's work.

What interviewers are testing: Whether you switch branches safely after checking for uncommitted work or stashing it.

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.

What interviewers are testing: Whether you can inspect the latest commit on each branch with git branch -v or related commands.

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.

What interviewers are testing: Whether you can verify whether a branch's commits are already contained in another branch.

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.

What interviewers are testing: Whether you understand why merge conflicts occur when Git cannot auto-merge competing changes.

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.

What interviewers are testing: Whether you can resolve conflicts by editing markers, staging fixes, 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.

What interviewers are testing: Whether you know rebase as the main alternative integration strategy and when teams prefer it.

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.

What interviewers are testing: Whether you can explain rebase as replaying commits and when it rewrites history.

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.

What interviewers are testing: Whether you know not to rebase commits that others may already have based work on.

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.

What interviewers are testing: Whether you understand interactive rebase for cleaning up local commit history before review.

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.

What interviewers are testing: Whether you know the basic rebase commands and how to continue or abort after conflicts.

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.

What interviewers are testing: Whether you understand -X ours / -X theirs as per-hunk merge preferences—not whole-branch replacement—and how rebase can invert the meaning.

During a normal merge, -X ours favors the current side when Git encounters conflicting hunks, while -X theirs favors the other side. Non-conflicting changes from both branches are still merged.

Example:

git merge -X ours feature/login
git merge -X theirs feature/login

Do not confuse -X ours with the ours merge strategy, which ignores the other tree's content entirely.

During rebase, the meaning of "ours" and "theirs" can be counterintuitive because Git is replaying commits onto the new base.

A strong answer is:

During a normal merge, -X ours or -X theirs influences automatic resolution of conflicting hunks; it does not mean "replace the whole branch with this side." I use these options cautiously.

What interviewers are testing: Whether you know whitespace-related merge strategy options and their risks.

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.

What interviewers are testing: Whether you understand that git stash drop permanently removes a stash entry.

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.

What interviewers are testing: Whether you use stash to park unfinished work without creating a premature commit.

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.

What interviewers are testing: Whether you know the difference between git stash apply and git stash pop.

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.

What interviewers are testing: Whether you understand the difference between moving a ref and changing the index/working tree, particularly the destructive effect of --hard.

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.

git reset remains important for moving refs and changing the index, while git restore --staged is often clearer when your only intention is to unstage a file.

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.

What interviewers are testing: Whether you choose git revert for shared history instead of rewriting public commits.

Use git revert.

Example:

git revert <commit>

git revert creates a new commit that undoes the changes from the selected commit. See Git revert 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.

What interviewers are testing: Whether you can squash local commits with interactive rebase without rewriting shared branches.

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.

What interviewers are testing: Whether you use git clean carefully with preview flags before deleting untracked files.

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 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.

What interviewers are testing: Whether you understand cherry-pick as applying one commit's changes onto the current branch.

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.

What interviewers are testing: Whether you know that pull combines fetching with integration and can explain why some teams prefer explicit fetch + merge/rebase.

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

git pull first fetches from the remote, then integrates the fetched branch into the current branch. In current Git, when no reconciliation method is configured, a pull is fast-forward-only and fails if the histories have diverged. You can explicitly choose rebase with --rebase or merge with --no-rebase; configuration can also set the preferred behavior.

1. git fetch — downloads objects and updates remote-tracking refs.
2. Integration — fast-forward, rebase, merge, or squash according to options/configuration.

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

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 first and then integrates the upstream branch. Current Git defaults to fast-forward-only when no reconciliation method is configured; teams can explicitly configure or request merge, rebase, or squash behavior.

What interviewers are testing: Whether you understand when a push is rejected because the remote ref cannot fast-forward—not merely because the remote has any newer commits.

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:

• Updating the target branch would require a non-fast-forward update because its current tip is not an ancestor of the commit you are pushing
• 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 sends objects needed by the remote and requests ref updates. A normal push is rejected when updating the target branch would not be a fast-forward or when server policy blocks it.

What interviewers are testing: Whether you distinguish cloning a repository from managing remotes in an existing local repo.

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.

What interviewers are testing: Whether you can rename or update remote URLs with git remote subcommands.

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.

What interviewers are testing: Whether you know origin is a remote nickname, not a special branch.

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.

What interviewers are testing: Whether you can configure authentication without storing plain-text passwords—using SSH or an OS-appropriate credential helper.

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.

Configure the credential helper provided by your OS or Git installation—for example Git Credential Manager where installed—or use SSH keys.

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.

What interviewers are testing: Whether you can name Git's common transport protocols and when each is used in practice.

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.

What interviewers are testing: Whether you understand the unauthenticated git:// transport and why HTTPS or SSH is preferred for team repositories.

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

It was designed for fast transfer, but the protocol itself has no authentication built into that transport.

Because of that, modern teams usually prefer:

• HTTPS
• SSH
• Hosted Git platforms with access control

A strong answer is:

The git:// protocol is an unauthenticated transport; HTTPS and SSH are more common for real team repositories.

What interviewers are testing: Whether you can describe a fork-and-pull-request workflow when you lack push access to upstream.

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.

What interviewers are testing: Whether you understand client-side and server-side hooks and what problems they solve.

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.

What interviewers are testing: Whether you know hooks are executable scripts and can be written in any language available on the system.

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 hook must be runnable by Git in the target environment and placed in the configured hooks path. On Unix-like systems, script hooks normally also need the executable bit set.

Example on Linux:

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.

What interviewers are testing: Whether you distinguish Git's content-integrity mechanisms from authentication, authorization, encryption, and signed provenance.

Git uses object hashes so object names are tied to their contents, which provides strong integrity checking and makes accidental corruption detectable.

Important clarifications:

• Git does not encrypt your source code by default. Hashing is not encryption.
• Hashes alone do not authenticate who created a commit or prove that a ref has not been intentionally rewritten; signatures and trusted hosting/access controls address those concerns.
• Git is also transitioning from SHA-1 toward SHA-256 repository formats; official Git documentation describes SHA-256 as the chosen successor.

Repository security also depends on:

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

A strong answer is:

Git uses content hashes to identify objects and detect inconsistent or corrupted content. Authentication and provenance are separate concerns handled with access controls and, where required, signed commits or tags.

What interviewers are testing: Whether you can use pre-commit hooks for fast local checks while relying on CI for heavier validation.

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.

What interviewers are testing: Whether you know server-side hooks versus CI for enforcing policy on pushed commits.

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.

What interviewers are testing: Whether you can differentiate pre-receive, update, and post-receive hook timing and rejection behavior.

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

Example:

• Use pre-receive to reject a push when any proposed ref update violates a repository-wide policy.
• Use update for policy specific to an individual ref or 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.

What interviewers are testing: Whether you understand that hooks are local by default and how teams share hook logic reliably.

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.

What interviewers are testing: Whether you understand HEAD as a symbolic ref and what detached HEAD means.

HEAD normally stores a symbolic reference to the currently checked-out branch, such as refs/heads/main; that branch ref names the tip commit.

In detached HEAD state, HEAD directly identifies a commit instead of going through a branch ref.

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 normally points to the current branch ref, and that branch ref points to the tip commit. In detached HEAD state, HEAD points directly to a commit hash instead.

What interviewers are testing: Whether you know rerere records conflict resolutions for repeated merges or rebases.

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.

What interviewers are testing: Whether you can name the three common git diff comparisons—working tree, staged, and against HEAD.

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.

What interviewers are testing: Whether you can explain Git's flexibility across branching, remotes, tags, stash, and workflow styles.

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.

What interviewers are testing: Whether you know when a new commit is safer than amending already-shared history.

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.

What interviewers are testing: Whether you understand bare repositories as remotes without a working tree.

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.

What interviewers are testing: Whether you can use repository history systematically to locate a regression rather than manually checking commits one by one.

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.

What interviewers are testing: Whether you understand branch refs conceptually and how to inspect them with Git commands instead of assuming loose files always exist.

Git uses refs.

Conceptually, a local branch is a ref such as refs/heads/main that names the branch's tip commit object ID. A loose ref may appear as .git/refs/heads/main, but Git can store refs in other internal formats—including packed refs—so applications should use Git commands rather than depend on that file existing.

Example:

git rev-parse main
git symbolic-ref HEAD

Traditional repositories use SHA-1 object IDs; Git also supports SHA-256 repository formats.

A strong answer is:

Normally, HEAD → a branch ref such as refs/heads/main → commit object ID. In detached HEAD state, HEAD identifies the commit directly.

What interviewers are testing: Whether you know lightweight versus annotated tags and when to sign release tags.

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.

What interviewers are testing: Whether you can reorder local commits with interactive rebase before sharing them.

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.

What interviewers are testing: Whether you can split an oversized commit into smaller logical commits during interactive rebase.

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.

What interviewers are testing: Whether you understand history-rewrite tools, including that git filter-repo is a separately installed modern alternative to filter-branch.

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 — a separately installed tool recommended for modern history-rewrite workflows
• BFG Repo-Cleaner — another third-party option 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.

What interviewers are testing: Whether you can explain Git's working tree, index, and HEAD as the three main trees.

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.

What interviewers are testing: Whether you understand how a local branch knows which remote branch to fetch from and push to.

An upstream (tracking) branch links a local branch to a remote-tracking ref such as origin/main.

When upstream is set:

• git status can report ahead/behind counts
• git pull and git push can use defaults without repeating remote and branch names

Set upstream on first push:

git push -u origin feature/login

Or configure it explicitly:

git branch --set-upstream-to=origin/feature/login

A strong answer is:

An upstream branch tells my local branch which remote branch it tracks. After git push -u, git pull and git push know where to synchronize without extra arguments.

What interviewers are testing: Whether you pick the right undo mechanism instead of using one command for every recovery scenario.

Examples:

git restore file.js
git restore --staged file.js
git reset --soft HEAD~1
git revert <commit>

A strong answer is:

I use restore for file-level undo, reset to move branch history or unstage, and revert when I need to undo a public commit without rewriting shared history.

What interviewers are testing: Whether you know Git can intentionally download less than a full repository when history or objects are huge.

A normal clone copies the project's history and sets up remote-tracking refs.

A shallow clone limits history depth:

git clone --depth 1 https://github.com/user/large-repo.git

Useful for CI or situations where you only need recent history.

Partial clone reduces which Git objects are fetched initially, while sparse checkout limits which tracked paths are populated in the working tree. They are often useful together for very large repositories.

Trade-off: shallow or partial clones may lack older commits locally, so some history operations need a deeper fetch first.

A strong answer is:

Shallow clones reduce history depth; partial clone and sparse checkout address object fetch and working-tree size separately. I use them for CI or huge repos, then deepen history only when debugging needs it.

What interviewers are testing: Whether you can explain how a pull request lands on the target branch and why teams choose different integration styles.

These are platform or team policies for integrating a feature branch—not three different core Git commands with identical names everywhere.

Example on the command line, a merge commit is the classic:

git switch main
git merge feature/login

Squash workflows are common on GitHub/GitLab pull requests. Rebase-and-merge replays commits onto updated main before integration.

A strong answer is:

A merge commit keeps full branch history, squash merge collapses a feature into one commit on main, and rebase merge replays commits for a linear mainline—I pick based on team policy and how much history we want preserved.

What interviewers are testing: Whether you can summarize contributor activity with git shortlog for release notes.

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.

What interviewers are testing: Whether you understand Git aliases and that shortcuts like git co are not built-in commands by default.

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.

What interviewers are testing: Whether you know git grep searches tracked content and specific trees in history.

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.

What interviewers are testing: Whether you understand submodule pointers, initialization, and the workflow complexity they add.

A Git submodule lets a parent repository reference another Git repository at a specific commit.

The parent records the submodule path and the exact commit it expects, while the submodule keeps its own independent history.

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 lets one repository pin another repository to a specific commit. It keeps histories separate, but developers must initialize and update the submodule explicitly.