Git Version Control Interview Questions and Answer

1. What is Git?

Git is a distributed version control system that tracks changes in source code and allows multiple developers to work on the same project without overwriting each other’s work.

2. How is Git different from GitHub?

Git is the tool used for version control on your local machine, while GitHub is a cloud platform that hosts Git repositories and provides collaboration features like pull requests, issues, CI/CD, and code reviews.

Example (if required):

• Git = MS Word (the tool)
• GitHub = Google Drive (where the file is stored and shared)

3. What is Version Control? Why do we need it?

Version Control is a system that tracks changes made to files over time, allowing you to restore previous versions, compare changes, and collaborate safely. We need version control to avoid losing work, track history, work collaboratively, and manage multiple versions of code without conflicts. It ensures safe, organized, and traceable development across teams.

4. What is a repository?

A repository is a storage location where your project’s files and their complete version history are kept. It can be local on your machine or remote on platforms like GitHub.

5. Difference between local repo and remote repo.

A local repository exists on your machine where you create, edit, and commit code.
A remote repository is hosted on a server like GitHub, GitLab, or Bitbucket and is used for sharing code and collaborating with others.

In simple terms:

• Local repo = your personal copy
• Remote repo = shared team copy

6. What is git init?

git init is a fundamental Git command that initializes a new Git repository. This action transforms a standard directory into a Git-managed project, enabling version control.

When git init is executed within a directory, it performs the following:

• Creates a .git subdirectory: This hidden folder is the core of the Git repository. It contains all the necessary metadata for Git to track changes, including object databases, references (branches and tags), configuration files, and other internal structures.
• Prepares for version control: The presence of the .git directory allows Git commands like git add, git commit, git branch, and others to function within that directory and its subdirectories.
• Initializes a default branch: Typically, a default branch (often named main or master) is created that points to the repository's initial state.

Example: If you create a new project from scratch, the first step is often

git init

7. What does git clone do?

git clone is used to create a full local copy of a remote Git repository, including all files, commit history, branches, and tags. It essentially downloads the project from platforms like GitHub or GitLab to your machine so you can start working on it.

When you run:

git clone <repository-url>

Git creates a new folder, pulls all the project data, and automatically sets the remote name as origin, allowing you to sync changes later using git pull and git push.

In short, git clone is used when you want to start working on an existing project hosted remotely.

8. What is the difference between git clone and git pull?

git clone is used once to create a complete local copy of a remote repository.

It downloads everything, files, commit history, branches, and sets up the connection to the remote.

Use case: When you're starting with a project for the first time.

git pull is used after you have cloned the repository, to get the latest changes from the remote repository into your existing local repo.

It performs:

• git fetch (downloads changes)
• git merge (merges them into your current branch)

Use case: To keep your local copy updated with the team’s latest changes.

9. What is a commit?

A commit in Git is a snapshot of your project’s files at a specific point in time.
Whenever you make changes and run git commit, Git records:

• The exact state of your files
• Who made the change
• When it was made
• A message describing why the change was made

Commits form the history of your project, allowing you to go back to earlier versions, compare changes, and understand how the code evolved.

Each commit has a unique SHA-1 hash, which acts like an ID for that snapshot.

10. What is the staging area in Git?

The staging area (also called the index) is a place where Git collects and organizes your changes before creating a commit.

When you modify files, they don’t go directly into a commit.
You first add them to the staging area using:

git add <file>

This step allows you to:

• Choose which changes you want to include in the next commit
• Group related changes together
• Avoid committing accidental or incomplete changes

The staging area acts as a buffer between your working directory and the final commit.
It gives developers control and ensures each commit is clean, meaningful, and intentional.

11. Explain the Git file lifecycle (untracked → tracked → staged → committed).

1. Untracked

A file is untracked when it exists in your project folder, but Git is not monitoring it yet. These are usually new files you just created.

Example: You create login.js → Git doesn’t know about it yet.

2. Tracked

A file becomes tracked as soon as you add it to Git using:

git add <file>

Tracked means Git is aware of the file and will monitor its future changes.
Tracked files can be unmodified, modified, or staged.

3. Staged (Index)

A staged file is one whose latest changes are prepared for the next commit.

When you run git add <file>, the file is moved from modified → staged.

This allows you to control exactly which changes will go into the next commit.

4. Committed

When you run:

git commit -m "message"

all staged changes are saved into Git’s repository history.

A commit represents a permanent snapshot that you can revert to or compare later.

Simple Summary

• Untracked: Git doesn’t know about the file.
• Tracked: Git knows the file exists.
• Staged: File is ready to be committed.
• Committed: File changes are permanently stored in Git history.

This lifecycle ensures clean, controlled, and well-organized version management.

12. What do git add . and git add -A do?

Both commands are used to move changes from the working directory to → staging area, but they behave slightly differently.

git add .

This command stages:

• New files
• Modified files

within the current directory and its subdirectories.

But it does NOT stage deleted files.

Example: If you delete a file, git add . will ignore that deletion.

git add -A

This command stages all changes in the entire repository, including:

• New files
• Modified files
• Deleted files

It ensures your staging area represents the exact state of your working directory.

Simple Difference

• git add . → add new + modified files (no deletions)
• git add -A → add new + modified + deleted files (complete sync)

Most developers use git add -A when preparing a clean commit.

13. What does git status show?

git status gives a clear summary of the current state of your working directory and staging area.

It helps you understand what Git sees before you commit.

1. Untracked files: Files Git is not tracking yet (new files).

2. Modified files: Files that have been changed but are NOT staged.

3. Staged files: Files that are added to the staging area and will be included in the next commit.

4. Branch information: It shows which branch you're currently on and whether your branch is ahead/behind the remote.

5. Instructions/help: It often suggests next steps, like:

• “Use git add to stage changes.”
• “Use git restore to discard.”

14. What does git log do?

git log displays the history of commits in your repository.

It shows each commit in reverse chronological order (newest first), along with important details like:

• Commit hash (SHA) → unique ID of the commit
• Author → who made the commit
• Date → when the commit was made
• Commit message → why the change was made

Example:

commit 8f3a2c...
Author: John Doe
Date:   Tue Dec 2

    Added login validation

15. What is .gitignore? Why is it used?

.gitignore is a special configuration file in a Git project that tells Git which files or folders it should completely ignore.

Files listed inside .gitignore will not be tracked, not appear in git status, and won’t be added to commits, even if they exist in your project directory.

It is used to keep your repository clean and free from files that should not be version-controlled, such as:

• Temporary or cache files (e.g., dist/, temp/)
• Build outputs and compiled code (bin/, obj/)
• Dependency folders (e.g., node_modules/)
• Sensitive files (API keys, credentials)
• IDE/system-specific files (.vscode/, .DS_Store)

Using .gitignore prevents unnecessary or private files from being committed, reducing repo size and avoiding security risks.

16. How to remove a file from Git but keep it locally?

To remove a file from Git’s tracking without deleting it from your local system, you use:

git rm --cached <file>

This command removes the file from the staging/index, meaning Git will no longer track its changes, but the file itself remains in your working directory.

After running this, you commit the change:

git commit -m "Stop tracking file"

If it's a file you never want Git to track again, add it to .gitignore.

17. What is a branch in Git?

A branch in Git is a separate line of development that allows you to work on new features, bug fixes, or experiments without affecting the main codebase.

When you create a branch, Git simply creates a new pointer to a commit. It doesn’t copy the entire project, so branching is very fast and lightweight.

Developers commonly use branches to isolate work:

• main or master → stable production-ready code
• feature/login → new login feature
• bugfix/payment → fix for payment issue

Once the work is complete, the branch can be merged back into the main branch through a merge or pull request.

18. How to create a branch?

Use git branch <name> to create a branch, and git switch -c <name> to create and start working on it immediately.

19. Difference between git merge and git rebase.

git merge and git rebase both integrate changes from one branch into another, but they do it in very different ways, affecting your project history.

• git merge: When you merge a branch, Git combines the commit histories of two branches and creates a merge commit.
• git rebase: Rebase takes your commits and reapplies them on top of another branch, as if you created them from there originally.

In short:

• Merge preserves history; Rebase rewrites it.
• Merge is safer for collaboration; Rebase is best for clean, linear commits.

20. What is a merge conflict?

A merge conflict happens when Git is unable to automatically combine changes from two branches because both branches modified the same part of the same file, or one branch deleted something that the other branch edited.

Git doesn’t know which version is correct, so it stops the merge and asks the developer to resolve it manually.

During a merge conflict, Git marks the conflicting sections in the file using:

<<<<<< HEAD
Your changes
======
Other branch changes
>>>>>> branch-name

21. What is a detached HEAD state?

A detached HEAD state happens when your HEAD pointer (which normally points to the latest commit of a branch) points directly to a specific commit, tag, or old revision instead of a branch.

In this state, you are not on any branch.
You are simply viewing or modifying code at a past commit.

Example of entering detached HEAD:

git checkout a7c9d12

Here, HEAD points to commit a7c9d12, not to a branch like main or dev.

Any new commits you make in a detached HEAD are not tied to a branch, so they can be lost if you switch branches unless you create a new branch for them.

22. What is git checkout used for?

git checkout is used to switch branches or restore files, making it one of the most essential commands in Git.

In modern Git, git checkout has been split into two clearer commands:

• git switch → for switching branches
• git restore → for restoring files

But git checkout still works, and developers commonly use it.

23. What is a feature branch workflow?

A Feature Branch Workflow is a Git development strategy where each new feature, enhancement, or bug fix is developed in its own separate branch instead of directly in the main or develop branch.

The goal is to isolate work so developers can build, test, and review changes without affecting the stable codebase.

24. Difference between git pull and git fetch?

git pull and git fetch both interact with the remote repository, but they behave very differently.

git fetch - Downloads changes but DOES NOT merge

1. git fetch only retrieves new commits from the remote repository and updates your remote-tracking branches (like origin/main). It does not modify your working directory or your current branch.

Example:

git fetch

After fetching, you can compare or review the changes before merging manually:

git merge origin/main

When to use it:

• When you want to see what others have changed without affecting your code
• When you want full control before merging

2. git pull - Fetch + Merge (auto-merge)

git pull does both steps automatically:

• Fetch latest changes
• Merge them into your current branch

Example:

git pull

Your working directory is immediately updated with the remote changes.

When to use it:

• When you want the latest code quickly
• When you trust the remote changes and don’t need review

In short:

• git fetch = safely download changes without touching your work.
• git pull = download + merge changes into your current branch.

Most developers use git fetch when they want control, and git pull when they want quick updates.

25. How do you undo the last commit?

Undoing the last commit depends on whether the commit has been pushed and whether you want to keep the changes or discard them.

Here are the common and safe ways:

1. Undo last commit but KEEP the changes (soft reset)

Use this when you made a wrong commit message or forgot to include a file.

git reset --soft HEAD~1

This removes the commit but keeps all your changes staged.

2. Undo last commit but KEEP changes unstaged (mixed reset - default)

This removes the commit and moves your changes back to the working directory.

git reset HEAD~1

You can edit them again and recommit.

3. Undo last commit and REMOVE the changes (hard reset - destructive)

Use this only if you don’t need the changes.

git reset --hard HEAD~1

This deletes the commit and all file changes.

4. If the commit is already pushed - use revert (safe way)

If you’ve pushed the commit to a shared branch (like main), never reset.

Instead, create a new commit that reverses the old one:

git revert HEAD

This is safe for team collaboration.

In short:

• Use reset to undo local commits (soft/mixed/hard).
• Use revert to undo a commit that is already pushed and shared.

26. Difference between git revert and git reset.

The main difference is that git revert is a safe, forward-moving operation that creates a new commit to undo changes, preserving project history, while git reset rewrites history by moving the branch pointer to a previous commit, potentially losing work.

Example:

git revert <commit-id>
git reset --hard HEAD~1

In short:

• Use git revert to safely undo a pushed commit without breaking history.
• Use git reset to rewrite or clean up local commit history before pushing.

27. What is a soft, mixed, and hard reset?

git reset has three main modes that determine how the staging area and working directory are affected when you move the HEAD pointer to a previous commit.

28. What is an interactive rebase?

Interactive rebase is a powerful Git tool for modifying and cleaning up a series of commits in your project's history. It allows you to control exactly how commits are integrated or changed, rather than just blindly moving them. 

This process involves using the git rebase -i <base-commit> command, which opens a text editor showing a list of commits in the specified range. You can then use various commands to manipulate individual commits. 

Interactive rebase is typically used on local, unshared branches to create a clean, linear, and meaningful history before sharing it with a team.

29. How to squash commits?

Squashing commits means combining multiple commits into a single commit so that your Git history looks clean and meaningful (for example, before merging a feature branch).

The most common way to squash commits is to use an interactive rebase.

Steps to squash the last N commits

Suppose you want to squash the last 3 commits into one:

git rebase -i HEAD~3

This opens an editor showing something like:

pick a1b2c3 First commit
pick d4e5f6 Second commit
pick 789abc Third commit

You then change it to:

pick a1b2c3 First commit
squash d4e5f6 Second commit
squash 789abc Third commit

• pick → keep this commit as is
• squash (or s) → combine this commit into the one above

After saving and closing, Git will ask you to edit the final commit message (you can keep one or write a new combined message).

Important Note: If the branch is already pushed and used by others, squashing rewrites history, so you should coordinate with your team (or avoid squashing shared history).

30. What does git stash do?

git stash temporarily saves your uncommitted changes (both staged and unstaged) and cleans your working directory, allowing you to switch branches or pull updates without losing your work.

It’s like putting your work on a temporary shelf.

You use it when you need to:

• Switch branches quickly
• Pull the latest test code
• Work on an urgent bug fix
• Pause your current work without committing half-done changes

Example scenario:

You're working on feature/login, but suddenly need to fix a production bug on main.

Your changes aren’t complete, so you can't commit them.

• git stash → saves changes and cleans the working directory
• git stash list → shows stashed items
• git stash apply → restores the most recent stash
• git stash drop → removes the stash
• git stash pop → restores + deletes the stash in one step

31. Fork vs Clone vs Branch.

Forking creates an independent copy of a repository on a hosting service (like GitHub) for separate development, Cloning makes a local copy on your machine for offline work, and Branching creates isolated development lines within a single repository (local or remote) for features, all enabling parallel work, but Forks are for public contribution, Clones for local sync, and Branches for features inside a project.

32. What happens during git pull --rebase?

The git pull --rebase command is a combination of git fetch and git rebase. It is used to update a local branch with changes from a remote branch while maintaining a linear commit history.

Here is a breakdown of what happens:

• git fetch: Git first fetches the latest changes from the remote repository and updates the remote-tracking branch (e.g., origin/main). These changes are downloaded but not yet integrated into your local working branch.
• git rebase: After fetching, Git then takes your local commits (those that are not yet pushed to the remote) and temporarily "puts them aside." It then "rewinds" your local branch to the point where it diverged from the remote-tracking branch. Finally, it reapplies your local commits one by one on top of the newly fetched remote changes.

33. You accidentally deleted a branch—how to restore it?

To restore a deleted Git branch, use git reflog to find the commit hash (SHA) of the branch's tip, then git checkout -b <branch-name> <sha> to recreate it locally; for remote/hosted repos (GitHub, Azure DevOps), use the platform's UI to find branch deletions in activity logs or closed pull requests and click "Restore".