Git is one of the most widely used version control systems in modern software development. Whether you are a beginner preparing for your first developer interview or an experienced developer brushing up on Git concepts, understanding how Git works is an important part of working effectively with source code.

Git interview questions can range from simple concepts such as repositories, commits, and branches to more practical topics such as merging, rebasing, stashing, cherry-picking, and resolving conflicts.

This guide covers commonly asked Git interview questions with clear and practical answers. Along with the concepts, you should also practice the related Git commands so that you can explain not only what a feature does, but also how you would use it in a real project.

1. What is Git?

Git is a distributed version control system used to track changes in files, particularly source code, during software development.

Unlike a traditional centralized version control system, Git gives each developer a complete local repository containing the project's history. This makes it possible to create commits, inspect history, create branches, and perform many other operations without continuously connecting to a remote server.

Git is commonly used for:

• Tracking changes in source code
• Working on multiple versions of a project
• Creating and managing branches
• Collaborating with other developers
• Reviewing and integrating changes
• Maintaining a history of project changes

2. What is the difference between Git and GitHub?

Git and GitHub are related, but they are not the same thing.

Git is the version control system that runs on your computer and manages your project's history.

GitHub is a cloud-based platform that hosts Git repositories and provides collaboration features such as pull requests, issues, code reviews, and project management.

In simple terms, Git is the version control tool, while GitHub is one of the platforms that can host Git repositories.

Other platforms, such as GitLab and Bitbucket, can also host Git repositories.

3. What is a Git repository?

A Git repository is a project directory that is being tracked by Git.

A repository contains the files required for the project along with Git's internal data, including information about commits, branches, references, and other objects. This Git data is normally stored in the hidden .git directory.

A repository can exist locally on your computer, while a remote repository can be hosted on a service such as GitHub or GitLab.

4. Explain the basic Git workflow.

A typical Git workflow looks like this:

Working directory → Staging area → Commit → Remote repository

For example, after modifying a file, you can check the changes with:

git status

You can then stage the changes:

git add filename

Create a commit:

git commit -m "Add new feature"

And push the commit to a remote repository:

git push

When working with other developers, you may also fetch or pull changes from the remote repository before continuing your work.

5. What is a Git branch?

A branch is a separate line of development within a Git repository.

Branches allow developers to work on features, bug fixes, experiments, or other changes without directly modifying another branch.

For example, a team might have:

main
feature/login
feature/payment
bugfix/header

A developer can work on feature/login while the stable code remains on main.

6. How do you create a new branch in Git?

There are several ways to create and switch to a new branch.

The traditional command is:

git checkout -b feature/login

Modern Git also provides the switch command:

git switch -c feature/login

The -b or -c option creates the new branch and switches to it.

7. What is the difference between git init and git clone?

git init creates a new Git repository in an existing directory.

For example:

git init

This creates the .git directory and starts Git tracking for that directory. The directory does not have to be completely empty.

git clone, on the other hand, creates a local copy of an existing repository, including its Git history.

For example:

git clone https://example.com/project.git

So, the basic difference is:

• git init → start a new Git repository
• git clone → copy an existing repository

8. What is a Git commit?

A commit is a recorded snapshot of changes in a Git repository.

When you commit changes, Git records information such as the changes included in the snapshot, the author, the commit message, and its relationship to previous commits.

A typical commit command is:

git commit -m "Fix login validation"

Good commit messages should briefly explain what the commit changes.

9. What is the staging area in Git?

The staging area is an intermediate area between your working directory and your next commit.

When you modify files, those changes are initially in your working directory. You can select which changes should be included in the next commit using git add.

For example:

git add app.js

The staged changes can then be committed:

git commit -m "Update application logic"

This gives developers control over exactly what goes into a commit.

10. What is HEAD in Git?

HEAD represents the currently checked-out position in your repository.

In normal branch-based work, HEAD usually refers to the current branch, and that branch points to the current commit.

For example:

HEAD → main → latest commit

Git can also enter a detached HEAD state, where HEAD points directly to a commit instead of a branch.

Understanding HEAD is particularly useful when working with commands such as reset, checkout, switch, and rebase.

11. How do you view the commit history in Git?

The git log command is commonly used to view commit history.

git log

For a more compact view, you can use:

git log --oneline

You can also customize the output to display branches and commit relationships:

git log --oneline --graph --all

This is particularly useful when investigating how branches have developed.

12. What is git revert?

git revert creates a new commit that reverses the changes introduced by an earlier commit.

For example:

git revert <commit>

This is different from simply deleting a commit from history. The original commit remains in the history, while a new commit is added to undo its changes.

This approach is often useful when changes have already been shared with other developers.

13. What is the difference between git reset and git revert?

Both commands can be used when you want to undo changes, but they work differently.

git revert creates a new commit that reverses an earlier commit.

git revert <commit>

git reset moves the current branch to another commit and can also change the staging area and working tree depending on the reset mode.

For example:

git reset HEAD~1

By default, this performs a mixed reset: the branch moves back one commit and the changes remain in the working directory but are unstaged.

Because reset can rewrite local branch history, you should be particularly careful when using it on commits that have already been shared with others.

14. How do you undo the last commit?

The correct command depends on what you want to happen to the changes.

To remove the last commit while keeping its changes in your working directory:

git reset HEAD~1

To keep the changes staged:

git reset --soft HEAD~1

To remove the commit and discard tracked working-tree changes as well:

git reset --hard HEAD~1

The --hard option should be used carefully because it can discard local changes.

15. What is Git stash?

Git stash temporarily stores changes that you have made but are not ready to commit.

For example, suppose you are working on a feature but need to switch branches to fix an urgent issue. You can temporarily stash your changes:

git stash

After completing the other work, you can reapply the stashed changes:

git stash apply

You can view your stashes with:

git stash list

Stashing is useful when you need to temporarily clean your working directory without creating an incomplete commit.

16. What is the difference between git fetch and git pull?

git fetch downloads information from a remote repository without integrating those changes into your current branch.

git fetch

git pull first fetches the remote changes and then integrates them into the current branch. Depending on the command options and configuration, that integration can happen through a merge or a rebase.

In simplified terms:

git fetch → download remote changes
git pull  → fetch + integrate changes

Using git fetch is useful when you want to inspect remote changes before deciding how to integrate them.

17. What is the purpose of .gitignore?

The .gitignore file tells Git which files or directories should normally be left untracked.

For example, a project might not want to commit:

node_modules/
.env
*.log
build/

A .gitignore file helps prevent generated files, local configuration files, temporary files, and other unwanted files from being accidentally added to the repository.

One important point for interviews: adding a file to .gitignore does not automatically remove a file that Git is already tracking. A tracked file generally needs to be removed from the index separately.

18. How do you delete a Git branch?

To delete a local branch that has already been merged:

git branch -d branch-name

To force-delete a local branch:

git branch -D branch-name

To delete a branch from a remote repository:

git push origin --delete branch-name

The -D option should be used carefully because it can delete a branch even when Git believes it contains unmerged work.

19. What is a merge conflict in Git?

A merge conflict happens when Git cannot automatically combine changes from different lines of development.

A common example is when two branches modify the same part of the same file in incompatible ways.

Git marks the conflicting section in the file, and the developer must decide which changes should remain.

A conflict may look similar to:

<<<<<<< HEAD
Current branch changes
=======
Incoming branch changes
>>>>>>> other-branch

The developer then edits the file, removes the conflict markers, and keeps the desired content.

After resolving the conflict, stage the file:

git add filename

Then complete the merge with a commit when required.

20. How do you resolve a merge conflict?

A typical conflict-resolution process is:

1. Run the merge or pull operation.
2. Check which files contain conflicts.
3. Open the affected files.
4. Review the conflicting sections.
5. Choose or combine the required changes.
6. Remove Git's conflict markers.
7. Stage the resolved files.
8. Complete the merge.

You can check the current state with:

git status

The exact final command depends on whether the conflict occurred during a merge, rebase, cherry-pick, or another operation.

21. What is the difference between git merge and git rebase?

Both commands can be used to integrate changes, but they produce different histories.

git merge combines two lines of development and may create a merge commit.

For example:

git merge main

git rebase replays commits from one branch onto another base, which can produce a more linear history.

For example:

git rebase main

A simplified example:

Before rebase:

main:    A---B---C
              \
feature:       D---E

After rebase:

main:    A---B---C
                   \
feature:            D'---E'

The rebased commits are new commits, so their commit IDs change.

Because rebase rewrites commit history, it should be used carefully when working with commits that other people have already based work on.

22. Why is Git rebase used?

Rebase is commonly used to replay a branch's commits on top of a newer base.

For example, if your feature branch is behind main, you might update it with:

git rebase main

Rebase can help produce a cleaner, more linear project history.

However, rebase is not automatically "better" than merge. The appropriate choice depends on the team's workflow and whether rewriting the relevant history is acceptable.

23. What is an interactive rebase?

Interactive rebase gives you more control over a series of commits.

You can start one with:

git rebase -i HEAD~3

Interactive rebase can be used to:

• Reorder commits
• Edit commit messages
• Combine commits
• Remove commits
• Modify individual commits

For example, you can use squash to combine commits or fixup when you want to combine a commit without retaining its commit message.

Interactive rebase is particularly useful for cleaning up local history before sharing it.

24. What is Git cherry-pick?

git cherry-pick applies the changes introduced by a specific commit to your current branch.

For example:

git cherry-pick <commit>

Suppose a bug fix exists as a commit on another branch, but you do not want to merge the entire branch. Cherry-pick allows you to apply that particular commit to your current branch.

Cherry-picking is useful, but it can create duplicate or confusing history if used without a clear reason.

25. What is Git bisect?

git bisect helps identify the commit that introduced a bug by performing a binary search through the project's history.

You typically start with:

git bisect start

Then identify a known bad commit:

git bisect bad

And a known good commit:

git bisect good <commit>

Git checks out commits between those points, allowing you to test whether each version is good or bad.

By repeatedly marking commits as good or bad, Git narrows the search until the problematic commit is identified.

This can be extremely useful when a bug was introduced somewhere in a long commit history.

26. What are Git hooks?

Git hooks are scripts that Git can execute at specific points during Git operations.

They can be used to automate tasks or enforce development rules.

For example, a team might use hooks to:

• Run tests
• Check formatting
• Validate commit messages
• Perform custom checks before certain operations

Hooks are stored in the repository's hooks directory by default, although Git also supports configuring a different hooks path.

One important interview point is that Git hooks are not the same as CI/CD pipelines. Hooks generally run in the developer's local environment, while CI/CD checks normally run in an external build or deployment environment.

27. What is a Git tag?

A Git tag is a named reference to a particular point in a repository's history.

Tags are commonly used to identify releases or other important versions.

For example:

git tag v1.0.0

You can list tags with:

git tag

Tags can also be created for a specific commit.

For release management, annotated tags are often useful because they contain additional tag metadata:

git tag -a v1.0.0 -m "Version 1.0.0"

28. What is a Git submodule?

A Git submodule allows one Git repository to include another Git repository as a dependency.

Instead of copying the external repository's files directly into your project history, the main repository records a specific commit of the submodule.

A submodule can be added with:

git submodule add <repository-url>

Submodules can be useful when a project depends on another independently maintained repository and you need to control exactly which version is being used.

29. What is forking in Git?

Forking is not a core Git command. It is primarily a feature provided by repository-hosting platforms such as GitHub and GitLab.

A fork creates a separate copy of a repository under another user's or organization's account.

A common workflow is:

Original repository
        ↓
      Fork
        ↓
Personal repository
        ↓
Make changes
        ↓
Pull/Merge Request
        ↓
Original repository

Forks are commonly used in open-source projects where contributors do not have direct write access to the original repository.

30. How do you rename a remote branch?

There is no single command that simply renames the branch on every remote automatically. A common approach is to rename the local branch, push the new branch name, and remove the old remote branch.

For example:

git branch -m old-name new-name
git push origin -u new-name
git push origin --delete old-name

If the branch is currently checked out, you can also use:

git branch -m new-name

The exact workflow can vary depending on the repository's branch protections and hosting platform.

31. What is git diff used for?

git diff is used to inspect differences between versions of files or different Git states.

For example:

git diff

shows unstaged changes in the working tree.

To inspect staged changes:

git diff --staged

You can also compare branches or commits:

git diff main feature/login

This makes git diff an important command for reviewing changes before committing or merging.

32. How do you configure Git?

Git can be configured using the git config command.

For example, you can configure your name:

git config --global user.name "Your Name"

And your email:

git config --global user.email "you@example.com"

You can view configuration values with:

git config --list

Git supports different configuration scopes, including system-wide, user-level, and repository-specific configuration.

Repository-specific configuration can override broader configuration settings.

33. What is a remote repository in Git?

A remote repository is another copy of a Git repository that is typically hosted on a server or repository-hosting platform.

A remote allows developers to exchange commits and other repository data.

You can view configured remotes using:

git remote -v

A common remote name is origin.

For example:

git push origin main

pushes the local main branch to the remote named origin.

34. What is the difference between git push and git fetch?

git fetch downloads updates from a remote repository into your local repository without changing your current working branch.

git fetch origin

git push sends local commits and references to a remote repository.

git push origin main

In simple terms:

fetch → remote → local
push  → local → remote

Understanding this difference is important when working with shared repositories.

35. What is a detached HEAD state?

Normally, HEAD points to your current branch. A detached HEAD state occurs when you check out a specific commit instead of a branch.

For example:

git checkout <commit>

You can inspect the project at that point in history, but new commits made there will not automatically belong to a named branch.

If you want to keep new work created from a detached HEAD state, you can create a branch:

git switch -c my-new-branch

Detached HEAD is not necessarily an error; it is simply a different state of the repository.

36. What is the difference between git checkout and git switch?

git checkout is an older, multifunctional command that can be used for switching branches and checking out files or commits.

Modern Git introduced git switch specifically for changing branches.

For example:

git switch main

Create and switch to a new branch:

git switch -c feature/login

git restore is now also available for restoring files, separating another common use case that historically belonged to git checkout. Git's current command reference lists switch and restore alongside checkout.

37. What is a fast-forward merge?

A fast-forward merge occurs when the target branch has not diverged from the branch being merged.

In this situation, Git can simply move the target branch pointer forward instead of creating a new merge commit.

For example:

A---B---C
         \
          D---E

If the target branch is still at C, Git may be able to move its pointer directly to E.

Fast-forward behavior is one reason Git histories can sometimes remain very simple even when branches are used during development.

38. What is a merge commit?

A merge commit is a commit created when Git combines two divergent lines of development and cannot perform a simple fast-forward.

A simplified history might look like:

A---B---C
     \     \
      D---E---M

Here, M represents the merge commit that brings the two lines of development together.

Merge commits can preserve information about how branches were integrated.

39. What is the difference between git revert, git reset, and git restore?

These commands are often confused because their names sound similar, but they have different purposes.

git revert

Creates a new commit that reverses the changes from an earlier commit.

git revert <commit>

git reset

Moves the current branch to another commit and can also modify the staging area and working tree depending on the selected mode.

git reset HEAD~1

git restore

Restores files in the working tree or staging area from another state.

For example:

git restore filename

The Git documentation specifically distinguishes these three commands by their effects on commits, branches, the index, and the working tree.

40. What should you prepare for a Git interview?

Learning Git commands by memorizing their syntax is not enough for a technical interview.

You should understand what happens to your working directory, staging area, local repository, branches, and remote repository when you execute a command.

At a minimum, practice these commands:

git init
git clone
git status
git add
git commit
git log
git diff
git branch
git switch
git merge
git rebase
git fetch
git pull
git push
git stash
git reset
git restore
git revert
git cherry-pick
git tag
git remote
git submodule
git bisect

You should also be comfortable explaining practical situations, such as:

• How to create and switch to a feature branch
• How to update a feature branch with the latest changes from main
• How to resolve a merge conflict
• How to undo a local commit
• How to undo a commit that has already been pushed
• How to temporarily save unfinished work
• How to apply one commit from another branch
• How to investigate which commit introduced a bug
• When merging and rebasing produce different results
• Why rewriting shared history can cause problems

Final Thoughts

Git is much easier to understand when you practice it instead of learning commands in isolation.

Start with the basic workflow of creating a repository, making changes, staging files, committing them, creating branches, and sharing changes with a remote repository. Once those concepts are clear, move on to more advanced operations such as rebase, cherry-pick, stash, reset, revert, bisect, and conflict resolution.

For interview preparation, try to explain each command in your own words and practice it in a small test repository. This will help you answer both theoretical questions and practical Git scenarios with confidence.

Remember: Git interview preparation should cover both concepts and commands. Knowing the syntax is useful, but understanding what a command actually changes in your repository is even more important.

If you want to strengthen your command-line knowledge, continue with our guide on Basic Git Commands You Need to Know, where you can learn the most commonly used Git commands along with their syntax and practical usage.