Feeling nervous about your upcoming tech interview? You’re about to face questions about Git, and the pressure is building. Many job seekers struggle with Git questions because they use the tool daily but haven’t thought deeply about how it works. The good news? With some focused preparation, you can turn these questions into opportunities to shine and stand out from other candidates.
In this post, I’m sharing the most common Git interview questions you’ll face, along with expert tips on how to answer them confidently. These aren’t just any answers – they’re crafted to showcase your technical knowledge and problem-solving abilities in ways that impress hiring managers.
GIT Interview Questions & Answers
Ready to ace your next technical interview? These carefully selected Git questions will help you prepare for what interviewers actually ask, with practical answers that demonstrate both your knowledge and experience.
1. What is Git and how is it different from other version control systems?
Interviewers ask this question to assess your fundamental understanding of Git and to see if you can articulate its distinctive features. Your answer shows whether you grasp the core concepts that make Git valuable in modern development environments.
First, explain that Git is a distributed version control system designed to handle projects of any size with speed and efficiency. Unlike centralized systems like SVN, Git gives each developer a complete local copy of the entire repository history, enabling offline work and faster operations.
Moreover, Git’s branching system is lightweight and powerful, making parallel development workflows much easier to manage. Its data integrity model ensures that the content of your files is cryptographically protected against accidental or malicious changes, giving teams confidence in their codebase.
Sample Answer: “Git is a distributed version control system created by Linus Torvalds in 2005. Unlike centralized systems such as SVN or CVS, Git stores a complete copy of the repository on each developer’s machine. This distributed approach offers several advantages: it allows for offline work, faster operations since most commands run locally, and built-in redundancy. Git also uses a different approach to track changes—it takes snapshots of your files rather than storing just the differences, which makes branching and merging much more efficient. Its content-addressable storage model ensures data integrity through SHA-1 hashing. These features make Git particularly well-suited for modern development practices like continuous integration and deployment.”
2. How do you create a new Git repository?
Interviewers ask this question to check your familiarity with the basic setup process of Git. Your answer reveals whether you can hit the ground running on day one with the fundamental skills needed to start a new project.
To create a new Git repository, you can use two main approaches. The first method is initializing a new repository in an existing project directory using the git init command, which creates a hidden .git folder containing all the necessary repository files.
Alternatively, you can create a repository by cloning an existing one using git clone followed by the repository URL, which downloads the remote repository to your local machine with its entire version history intact. This approach is common when joining an existing project or starting from a template.
Sample Answer: “I can create a new Git repository in two ways. If I’m starting from scratch, I navigate to my project folder and run git init, which creates the necessary Git infrastructure in a .git directory. After that, I add my files using git add and make the initial commit with git commit and an initial commit message. If I need to connect it to a remote repository, I would use git remote add origin followed by the URL and push with git push. Alternatively, if I’m working with an existing repository, I simply use git clone followed by the URL to create a local copy with the complete history. I always verify the setup worked correctly by checking the status with git status.”
3. What’s the difference between ‘git pull’ and ‘git fetch’?
This question helps interviewers evaluate your understanding of Git’s remote operations. Your answer demonstrates whether you know how to properly synchronize your local environment with remote repositories, a critical skill for team collaboration.
The main distinction is that git fetch only downloads new data from the remote repository but doesn’t integrate changes into your working files. It updates your remote-tracking branches, allowing you to review changes before merging.
In contrast, git pull is essentially a combination of git fetch followed by git merge. It downloads new data from the remote repository and immediately integrates those changes into your current working copy. Understanding this difference is crucial for maintaining control over your workflow and avoiding unexpected conflicts.
Sample Answer: “When I use git fetch, I’m only downloading new changes from the remote repository to my local repository, but not applying those changes to my working files. This gives me a chance to see what’s changed before deciding how to incorporate those updates. The command updates my remote-tracking branches, which I can then inspect with commands like git log to see what’s different. On the other hand, git pull combines fetching and merging in one step—it downloads the changes and immediately tries to merge them into my current branch. While convenient, this can sometimes lead to unexpected merge conflicts. I typically prefer using fetch first in complex projects to maintain more control over when and how I integrate changes.”
4. How do you resolve merge conflicts in Git?
Interviewers ask this question to assess your problem-solving abilities in real-world scenarios. Your answer reveals your experience with one of the most challenging aspects of collaborative development and your approach to maintaining code quality.
When Git can’t automatically merge changes, it marks the conflicted areas in your files. To resolve these conflicts, first identify the conflicted files using git status. Then, open these files and look for the conflict markers (less than signs, equal signs, and greater than signs) that indicate the conflicting changes.
After deciding which changes to keep, remove the conflict markers and edit the content as needed. Once you’ve resolved all conflicts, add the modified files with git add and complete the merge with git commit. Clear communication with team members is often necessary during this process to ensure the correct resolution.
Sample Answer: “When facing merge conflicts, I first run git status to identify which files are conflicted. Then I open each file and look for the conflict markers—lines containing special symbols that Git inserts to show exactly where the conflicts occur. I carefully review both versions (mine and the incoming changes) and decide what code should remain, removing the conflict markers in the process. Sometimes I need to preserve parts from both versions or create an entirely new solution. After editing all conflicted files, I use git add to mark them as resolved, and then git commit to complete the merge. For complex conflicts, I might consult with the team member whose changes are conflicting with mine to ensure we’re making the right decisions. I also use tools like git mergetool when dealing with numerous or complex conflicts, as visual diff tools make the process more manageable.”
5. What is a Git branch and why would you use it?
This question helps interviewers gauge your understanding of Git’s core workflow concepts. Your answer shows whether you appreciate how branching facilitates parallel development and supports modern software development practices.
A Git branch is essentially a lightweight movable pointer to a commit, representing an independent line of development. Branches allow multiple developers to work independently on different features or bug fixes without interfering with the main codebase.
Using branches is fundamental to modern development workflows like GitFlow or GitHub Flow. They enable you to isolate work in progress, experiment with new ideas safely, and maintain a clean, stable main branch. Branches also facilitate code reviews through pull requests and support continuous integration practices.
Sample Answer: “A Git branch is a separate line of development that lets me work on features or fixes independently from the main codebase. Technically, it’s a lightweight, movable pointer to a commit that advances as I make new commits. I regularly use branches in my workflow to isolate different tasks—this keeps the main branch stable while development continues in parallel. For example, when implementing a new feature, I create a feature branch from the main branch, make my changes there, test thoroughly, and only merge back when everything works properly. This approach is particularly valuable in team settings as it prevents merge conflicts, supports code review processes through pull requests, and enables continuous integration. It also gives me the freedom to experiment with different approaches without affecting production code. In essence, branches are central to maintaining a clean, organized, and efficient development workflow.”
6. Explain the difference between ‘git merge’ and ‘git rebase’.
Interviewers pose this question to evaluate your understanding of Git’s history manipulation features. Your answer reveals whether you can make informed decisions about preserving history versus creating a cleaner project timeline.
Both git merge and git rebase are commands used to integrate changes from one branch into another, but they work differently. Merging creates a new “merge commit” that has two parent commits, preserving the branch history exactly as it happened but potentially creating a more complex history graph.
Rebase, on the other hand, moves or “replays” your commits on top of the target branch, creating a linear history. This results in a cleaner project history but rewrites commit history by creating new commits with new hashes. Understanding when to use each approach demonstrates your ability to maintain appropriate version control practices.
Sample Answer: “Both git merge and git rebase integrate changes from one branch into another, but they use different approaches with distinct advantages. When I use git merge, Git creates a new commit that ties together the histories of both branches. This preserves the complete history exactly as it happened and is non-destructive, making it safer for shared branches. The downside is that it can create a more complex, non-linear commit history that’s harder to follow. In contrast, git rebase works by moving my branch’s commits to the tip of the target branch, creating a linear history. This results in a cleaner, more straightforward project timeline, but it rewrites history by creating new commits with new SHA hashes. For this reason, I never rebase commits that have been pushed to public repositories, as it can cause issues for other developers. As a rule, I use merge for integrating feature branches into main branches and prefer rebase when I need to incorporate the latest changes from a main branch into my feature branch during development.”
7. What is a detached HEAD state and how would you recover from it?
This question helps interviewers assess your troubleshooting skills and deeper understanding of Git’s internal workings. Your answer demonstrates whether you can handle unexpected Git states that sometimes confuse even experienced developers.
A detached HEAD state occurs when you check out a specific commit, tag, or remote branch instead of a local branch. In this state, HEAD points directly to a commit rather than to a branch reference. While you can make changes and commits, these aren’t associated with any branch and may be lost when you switch to another branch.
To recover from a detached HEAD, you should create a new branch at your current position using git branch followed by a new branch name before switching away. This captures your work in a branch, making it part of your repository’s history and allowing you to merge it elsewhere later.
Sample Answer: “A detached HEAD state happens when HEAD—Git’s pointer to the current snapshot—is pointing directly to a commit hash rather than to a branch reference. This typically occurs when I check out a specific commit, a tag, or a remote branch. While in this state, I can view files and even make commits, but these new commits aren’t attached to any branch. If I switch to another branch without saving this work, those commits might become ‘orphaned’ and eventually be garbage collected. To recover from a detached HEAD, I first determine if I’ve made any valuable changes that need saving. If I have, I create a new branch right where I am with git branch followed by a new branch name, which anchors those commits to a branch. If I haven’t made any important changes, I can simply checkout an existing branch with git checkout and the branch name. I’ve learned to watch for Git’s warning messages about being in a detached HEAD state to catch this situation early.”
8. How do you undo the last commit in Git?
Interviewers ask this question to test your ability to recover from mistakes. Your answer shows whether you understand Git’s various history modification tools and can select the appropriate one based on the situation.
To undo the last commit, you have several options depending on whether the commit has been pushed to a shared repository. If the commit is only local, you can use git reset with the soft flag and HEAD~1 to undo the commit but keep all changes staged, or use the hard flag to completely discard the commit and its changes.
For commits that have been pushed to a shared repository, git revert is usually the safer option as it creates a new commit that undoes the changes without rewriting history. This distinction is crucial for maintaining collaboration in team environments.
Sample Answer: “The approach I take to undo the last commit depends on whether it’s been shared with others. For a local commit that hasn’t been pushed yet, I use git reset with the soft flag and HEAD1, which moves the branch pointer back one commit but keeps all the changes staged. This lets me make adjustments before recommitting. If I want to completely discard the commit and all its changes, I would use git reset with the hard flag and HEAD1, though I’m careful with this command as it permanently removes work. For commits that have already been pushed to a shared repository, I avoid reset because it rewrites history. Instead, I use git revert followed by HEAD, which creates a new commit that undoes the previous commit’s changes. This approach is safer for collaborative work because it preserves the commit history while still effectively canceling out unwanted changes. I’ve found that understanding these different techniques helps me recover from mistakes without disrupting my team’s workflow.”
9. What is Git rebase interactive mode and how would you use it?
This question helps interviewers evaluate your expertise with Git’s more advanced features. Your answer reveals whether you can effectively manage and clean up commit history before sharing code with your team.
Interactive rebase (git rebase with the -i flag) is a powerful tool that allows you to modify commits in various ways before rebasing. With it, you can reorder, edit, squash, or drop commits to create a cleaner, more logical commit history.
You would typically use interactive rebase to clean up your commit history before pushing to a shared repository, combining related small commits into logical units, removing unnecessary commits, or editing commit messages to better describe your changes. This demonstrates your commitment to maintaining a clear and useful version history.
Sample Answer: “Git’s interactive rebase mode gives me fine-grained control over my commit history. I start it with git rebase with the -i flag followed by the base commit, which opens a text editor listing all commits since the specified base commit. For each commit, I can choose several actions: ‘pick’ to keep it as is, ‘reword’ to change just the commit message, ‘edit’ to pause and amend the commit, ‘squash’ or ‘fixup’ to combine it with the previous commit, or ‘drop’ to remove it completely. I regularly use interactive rebase before sharing my work to clean up my local commit history. For example, if I’ve made several small ‘work in progress’ commits while developing a feature, I’ll squash them into a single meaningful commit that clearly describes the complete change. This creates a more logical and easier-to-review history. I’m always careful to only rebase commits that haven’t been shared yet, as rebasing public commits can cause problems for other developers. Interactive rebase is an excellent tool for crafting a clean, professional commit history that makes future maintenance and understanding easier.”
10. How do you use Git stash?
Interviewers ask this question to assess your workflow management skills. Your answer demonstrates whether you can efficiently handle interruptions and context switches that are common in professional development environments.
Git stash temporarily shelves (or stashes) changes you’ve made to your working copy so you can work on something else, and then come back and re-apply those changes later. This is particularly useful when you need to switch branches but aren’t ready to commit your current work.
To use stash, you run git stash save to store your current changes, work on other tasks as needed, and then either git stash apply to reapply your changes while keeping the stash, or git stash pop to apply and remove the stash. You can manage multiple stashes and apply specific ones as needed.
Sample Answer: “I use Git stash to temporarily save changes I’m not ready to commit when I need to switch contexts. The basic workflow is: when I’m in the middle of some work and need to switch to another task, I run git stash save followed by a descriptive message to store my current modifications. This cleans my working directory and lets me switch branches or pull updates without conflicts. After handling the interruption, I can return to my work by applying the stashed changes with git stash pop, which reapplies the changes and removes the stash, or git stash apply if I want to keep the stash for later use. If I’ve created multiple stashes, I can list them with git stash list and apply a specific one using its index. I find stash particularly valuable in fast-paced environments where I might get pulled into urgent issues while in the middle of feature development. It helps me manage my workflow without creating unnecessary commits or losing work.”
11. What is Git cherry-pick and when would you use it?
This question helps interviewers gauge your knowledge of specialized Git tools. Your answer reveals whether you can selectively apply changes across branches, which is useful in complex project management scenarios.
Git cherry-pick is a command that allows you to apply a specific commit from one branch to another. It takes the changes introduced in a single commit and creates a new commit with those same changes on your current branch.
You might use cherry-pick when you want to apply a specific bug fix to multiple branches without merging entire feature branches, when backporting fixes to maintenance branches, or when you need to recover specific changes from a branch that can’t be merged entirely. Understanding this tool shows you can maintain branch-specific functionality while sharing critical fixes.
Sample Answer: “Git cherry-pick allows me to apply the changes from a specific commit to my current branch. The command git cherry-pick followed by the commit hash takes the changes introduced in that commit, applies them to my current branch position, and creates a new commit with a new hash but the same message. I find cherry-pick especially useful in several scenarios. First, when maintaining multiple release branches, I can fix a bug in the development branch and then cherry-pick that fix to release branches without merging other unrelated changes. Second, if a feature branch contains some valuable work but can’t be merged as a whole, I can selectively pick the useful commits. Third, when a developer accidentally commits to the wrong branch, I can cherry-pick those commits to the correct branch. While cherry-pick is powerful, I’m careful with it because it creates duplicate commits with different hashes, which can complicate history if overused. I generally prefer normal merging workflows when possible, using cherry-pick as a targeted tool for specific situations rather than as a primary integration strategy.”
12. What is Git bisect and how would you use it to find a bug?
Interviewers ask this question to assess your debugging skills and knowledge of Git’s more advanced troubleshooting tools. Your answer demonstrates whether you can efficiently locate the source of problems in large codebases.
Git bisect is a binary search tool used to find which commit introduced a bug. You start by marking a known good commit and a known bad commit, then Git checks out commits in between, helping you test each one to narrow down when the bug was introduced.
To use bisect effectively, you begin with git bisect start, then mark commits as good or bad using git bisect good or git bisect bad after testing each one. Git guides you through a binary search process, significantly reducing the number of commits you need to check to find the problematic one.
Sample Answer: “Git bisect is an efficient debugging tool that uses binary search to find which commit introduced a bug. I start the process with git bisect start, then mark a known bad commit (typically the current state) with git bisect bad and a known good commit (usually an older version) with git bisect good. Git then checks out a commit halfway between these points. I test this version and mark it as either good or bad with the appropriate command. Based on my feedback, Git continues to divide the remaining commit range in half, helping me narrow down the problematic commit with logarithmic efficiency. For example, in a project with 1,000 commits between the good and bad versions, I’d only need to test about 10 commits to find the exact one that introduced the issue. For repetitive tests, I can automate the process with git bisect run followed by a test script, where my script returns 0 for good versions and non-zero for bad ones. Once the process identifies the commit that introduced the bug, I can examine that specific change to understand and fix the issue. Bisect has saved me countless hours of debugging, especially in large codebases where manually checking every commit would be impractical.”
13. How do you use Git hooks?
This question helps interviewers evaluate your knowledge of Git’s automation capabilities. Your answer shows whether you can implement process controls and quality checks that are essential in professional development environments.
Git hooks are scripts that Git executes before or after events such as commit, push, and receive. They allow you to customize Git’s internal behavior and trigger custom actions at key points in your development workflow.
You would typically use hooks to enforce coding standards by running linters pre-commit, validate commit messages for formatting, trigger continuous integration processes post-push, or prevent pushes to certain branches. Hooks can be client-side (like pre-commit) or server-side (like pre-receive), giving you control over both personal and team workflows.
Sample Answer: “Git hooks are scripts that run automatically at specific points in Git’s workflow. They’re stored in the .git/hooks directory of a repository, and I can create custom scripts for various trigger points. I commonly work with client-side hooks like pre-commit to run linters and tests before allowing a commit, ensuring code quality standards are met before changes are recorded. I also use commit-msg hooks to enforce commit message formatting according to team conventions, like requiring issue IDs or following conventional commit standards. For team-wide enforcement, I implement server-side hooks like pre-receive or update that run on the remote repository when developers push changes. These can reject pushes that don’t meet quality standards or attempts to push directly to protected branches. To share hooks with my team, I store them in the project repository (outside the .git directory) and create a setup script that symlinks them to each developer’s .git/hooks directory. While hooks need to be executable to work, I make them as simple as possible to avoid creating friction in the development process. Git hooks have been invaluable for maintaining code quality and ensuring consistent practices across teams I’ve worked with.”
14. What’s the difference between a fast-forward and recursive merge?
Interviewers pose this question to test your understanding of Git’s different merge strategies. Your answer reveals whether you can make informed decisions about maintaining repository history in various scenarios.
A fast-forward merge occurs when the target branch is a direct descendant of the source branch—there are no divergent changes to reconcile. Git simply moves the pointer of the target branch forward to match the source branch, without creating a new merge commit.
In contrast, a recursive merge happens when both branches have diverged from their common ancestor and have different changes that need to be combined. Git creates a new merge commit with two parent commits, preserving the history of both branches. Understanding this distinction helps you maintain appropriate history granularity for your project.
Sample Answer: “When I merge branches in Git, the system uses different strategies depending on the relationship between the branches. A fast-forward merge happens when the branch I’m merging into hasn’t had any new commits since I created my feature branch. In this scenario, Git simply moves the pointer of the target branch forward to match my feature branch—it’s like catching up to where my feature branch is. No new commit is created; the history remains linear. This is clean but doesn’t preserve the fact that development happened on a separate branch. A recursive merge, on the other hand, occurs when both branches have new commits since their common ancestor. Git needs to reconcile these divergent changes by creating a new ‘merge commit’ with two parents, one pointing to each branch’s tip. This preserves the complete history, showing that parallel development occurred. I can force Git to create a merge commit even when a fast-forward is possible by using the no-ff flag, which is useful when I want to explicitly record that a feature was developed in isolation. Understanding these strategies helps me make appropriate choices about how to maintain our project’s history based on our team’s needs.”
15. How would you recover deleted commits in Git?
This question helps interviewers assess your troubleshooting and recovery skills. Your answer demonstrates whether you understand Git’s safety mechanisms and can recover from potentially serious mistakes.
To recover deleted commits in Git, you would typically use the git reflog command, which shows a log of all reference updates in your local repository, including commits that are no longer referenced by any branch or tag. This acts as a safety net for commands that rewrite history.
Once you find the commit hash of the deleted commit in the reflog, you can recover it by creating a new branch at that commit with git branch followed by a recovery branch name and the commit hash, or by resetting your current branch to that commit using git reset with the hard flag and the commit hash. This ability to recover “lost” work is one of Git’s powerful safety features.
Sample Answer: “If I accidentally delete commits through commands like git reset with the hard flag or by force-pushing, I turn to git reflog as my recovery tool. The reflog records all changes to branch tips and HEAD in my local repository, acting as a safety net for the last 30-90 days. To recover deleted commits, I first run git reflog to view the history of HEAD movements. Each entry shows a commit hash and the action that moved HEAD to that position. I look for the last known good state before the deletion and note its hash. Then I create a new branch at that commit with git branch followed by a recovery branch name and the hash, or directly reset my current branch with git reset with the hard flag and the hash. If the deleted commits were on a branch that was deleted, I can recreate the branch with git checkout with the -b flag, the branch name, and the hash. This approach works for locally deleted commits, but it’s important to note that if garbage collection has run, or if the commits were never in my local repository, recovery might not be possible. That’s why I always make sure critical branches are pushed to remote repositories and follow careful practices with history-altering commands.”
Wrapping Up
With these fifteen Git interview questions and sample answers, you’re now much better prepared to showcase your version control expertise. Take time to practice these answers in your own words, adding personal experiences to make them authentic.
Going into your interview with this level of preparation gives you confidence that shows through in your responses. Rather than stumbling through basic Git concepts, you’ll demonstrate the depth of knowledge that employers are looking for in their technical teams.