Basic Git Interview Questions & Answers

1. What is Git?

 Answer: Git is a free and open-source distributed version control system (DVCS)
designed to handle everything from small to very large projects with speed and
efficiency. It allows multiple developers to collaborate on a project, tracking changes in
source code over time, enabling them to revert to previous versions, and merge
different lines of development.

2. What is a Git repository?

 Answer: A Git repository is a data structure that contains all the files, history, and
metadata associated with a project. It can be stored locally on your machine (local
repository) or remotely on a server (remote repository, e.g., GitHub, GitLab,
Bitbucket).

3. Explain the difference between Git and GitHub.

 Answer:

o Git: A version control system (the tool itself) that you install and run locally. It
allows you to track changes to your code, manage different versions, and
collaborate.

o GitHub: A web-based platform for hosting Git repositories. It provides a

centralized location for teams to store, share, and collaborate on Git projects,
offering features like pull requests, issue tracking, and project management.

4. What are the three states in Git?

 Answer: Git has three main states for your files:

o Working Directory: Your local files that you are currently editing.

o Staging Area (Index): A temporary area where you prepare changes to be

included in the next commit. You use git add to move changes here.

o Git Directory (Repository): Where Git permanently stores the history of your
project in the form of commits.

5. What is a commit in Git?

 Answer: A commit is a snapshot of your project's files at a specific point in time. It's a
record of the changes you've made, along with a unique identifier (SHA-1 hash),
author information, and a commit message describing the changes.
6. How do you create a new Git repository?

 Answer:

o To initialize a new repository in an existing project directory: git init

o To clone an existing remote repository: git clone <repository_url>

7. What is branching in Git?

 Answer: Branching in Git allows you to diverge from the main line of development to
work on new features, bug fixes, or experiments without affecting the stable
codebase. Each branch represents a separate line of development.

8. How do you create and switch to a new branch?

 Answer:

o Create a new branch: git branch <branch_name>

o Switch to an existing branch: git checkout <branch_name>

o (Shorthand to create and switch): git checkout -b <new_branch_name>

9. What is git add used for?

 Answer: git add stages changes for the next commit. It tells Git which modified, added,
or deleted files you want to include in the upcoming commit.

10. What is git commit used for?

 Answer: git commit saves the staged changes to the local repository, creating a new
commit object with a descriptive message.

11. What is git push used for?

 Answer: git push uploads your local commits to a remote repository, making your
changes available to others.

12. What is git pull used for?

 Answer: git pull fetches changes from a remote repository and automatically merges
them into your current local branch. It's a combination of git fetch and git merge.

Intermediate Git Interview Questions & Answers

1. Explain the difference between git fetch and git pull.

  Answer:

o git fetch: Downloads commits, files, and refs from a remote repository into
your local repository, but does not automatically merge them into your current
working branch. It updates your remote-tracking branches (e.g., origin/main).

o git pull: Is a combination of git fetch and git merge. It fetches changes from the
remote and then automatically merges them into your current local branch.

2. What is a merge conflict and how do you resolve it?

 Answer: A merge conflict occurs when Git cannot automatically reconcile changes
between two branches during a merge or rebase operation. This typically happens
when both branches have modified the same lines in a file, or one branch deletes a file
while the other modifies it.

o Resolution:

1. Git will mark the conflicting sections in the affected files (using <<<<<<<,
=======, >>>>>>> markers).

2. Manually edit the files to resolve the discrepancies, deciding which

changes to keep.

3. After resolving, git add the modified files to stage them.

4. Finally, git commit to complete the merge.

3. Explain git rebase and when would you use it?

 Answer: git rebase is used to integrate changes from one branch onto another by
moving or combining a sequence of commits to a new base commit. Instead of
creating a new merge commit, it rewrites the project history by applying commits from
one branch on top of another, making the history linear and "cleaner."

o When to use:

 To keep your feature branch up-to-date with the main branch before
merging.

 To clean up your commit history before pushing to a shared remote

(e.g., squashing small commits into a single logical one).

o Caution: Avoid rebasing branches that have already been pushed to a shared
remote, as it rewrites history and can cause issues for collaborators.

4. How do you revert a commit that has already been pushed?

  Answer: Use git revert <commit_hash>. This command creates a new commit that
undoes the changes introduced by the specified commit. It's considered safe for public
history because it doesn't rewrite existing commits.

5. How do you reset a Git repository to a previous commit? What's the difference between
soft, mixed, and hard reset?

 Answer: git reset <commit_hash> is used to move the HEAD pointer and optionally
modify the index and working directory to a previous state.

o git reset --soft <commit_hash>: Moves HEAD to the specified commit. The
changes from the commits after the target commit are kept in the staging area
(index).

o git reset --mixed <commit_hash> (default): Moves HEAD to the specified

commit and unstages any changes that were part of the commits after the
target commit. These changes are moved to the working directory.

o git reset --hard <commit_hash>: Moves HEAD to the specified commit, and
discards all changes in the staging area and working directory that were part of
the commits after the target commit. This is destructive and should be used
with caution.

6. What is git stash?

 Answer: git stash temporarily saves changes that are not yet ready to be committed
(e.g., changes in your working directory and staging area) without committing them.
This allows you to switch branches, pull changes, or perform other Git operations, and
then reapply your stashed changes later.

7. What is git reflog and how is it used?

 Answer: git reflog (reference logs) records changes to the tip of branches and other
references in your local repository. It's a powerful safety net that allows you to recover
lost commits or undo actions that would otherwise be permanent (like git reset --
hard). It shows you a history of where HEAD has been.

8. Explain the purpose of the .gitignore file.

 Answer: The .gitignore file specifies intentionally untracked files and directories that
Git should ignore. This is crucial for keeping your repository clean by preventing the
accidental committing of files like build artifacts, temporary files, editor configuration
files, or sensitive information.
Advanced Git Interview Questions & Answers

1. Describe a common Git branching strategy you've used or are familiar with (e.g., Git Flow,
GitHub Flow, Trunk-Based Development).

 Answer: (Choose one and explain its principles, pros, and cons.)

o Git Flow: A more complex, highly structured branching model with dedicated
branches for features, releases, hotfixes, develop, and main. Good for projects
with strict release cycles.

o GitHub Flow: A simpler, lightweight branching model. main branch is always

deployable. Features are developed in branches, and pull requests are used for
code review before merging into main. Ideal for continuous delivery.

o Trunk-Based Development: All developers commit directly to a single main

branch (trunk), or very short-lived feature branches that are merged back
frequently. Relies heavily on continuous integration and robust testing.

2. What are Git hooks and how might you use them?

 Answer: Git hooks are scripts that Git executes automatically before or after certain
events, such as committing, pushing, or receiving commits. They allow you to
automate tasks and enforce policies in your Git workflow.

o Examples:

 pre-commit: Run linting, code formatting, or unit tests before a commit

is created.

 pre-push: Run integration tests or prevent pushes to certain branches if

tests fail.

 post-receive (server-side): Trigger a deployment or update a CI/CD

pipeline after a successful push.

3. How do you squash multiple commits into one using git rebase?

 Answer:

1. git rebase -i HEAD~N (where N is the number of commits you want to squash,
including the first one).

2. An interactive editor will open, showing a list of commits.

 3. Change pick to squash (or s) for the commits you want to combine into the
previous one.

4. Save and exit the editor. Git will then prompt you to write a new commit
message for the squashed commit.

4. Explain "detached HEAD" state in Git and how to fix it.

 Answer: A "detached HEAD" state occurs when your HEAD pointer directly points to a
specific commit instead of a branch. This often happens when you git checkout a
commit hash or a tag. If you make new commits in this state, they won't be associated
with any branch, making them "lost" unless you explicitly create a new branch from
that commit.

o How to fix:

 If you just checked out a commit to inspect it and don't want to make
changes: Simply git checkout <your_branch_name> to return to your
branch.

 If you made new commits and want to keep them: git checkout -b
<new_branch_name> to create a new branch pointing to your current
HEAD.

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

 Answer: git cherry-pick is a command that allows you to apply a specific commit from
one branch onto another branch. It's useful when you only want to bring over a single
commit's changes without merging the entire branch.

o When to use:

 Applying a hotfix from a hotfix branch to main and then to a develop

branch.

 Backporting a specific feature or bug fix to an older release branch.

General Git Interview Preparation Tips:

 Understand the "Why": Don't just memorize commands. Understand why each
command exists and its purpose in the Git workflow.
  Practice Regularly: The best way to learn Git is by using it. Create personal projects,
experiment with commands, and simulate different scenarios (e.g., conflicts, reverting
changes).

 Know Your Workflow: Be ready to describe the Git workflow you typically use in a
team setting (e.g., feature branching, pull requests).

 Real-world Scenarios: Interviewers often ask situational questions. Think about how
you've handled common Git issues like merge conflicts, accidental commits, or
needing to undo changes.

 Explain Concepts Clearly: Be able to explain technical concepts in simple,

understandable terms.

 "Show, Don't Just Tell": If allowed, be prepared to demonstrate some basic commands
on a terminal or whiteboard.

 Be Honest: If you don't know an answer, admit it, but also express your willingness to
learn.

Good luck with your Git interview!