Latest Top Git Interview Questions & Answers

Whether you are a junior developer or a senior DevOps engineer, mastering Git is non-negotiable. Below is a curated list of the most critical Git interview questions, ranging from core concepts to real-world troubleshooting scenarios.

Section 1: Git Basics & Core Concepts
1. What is the difference between a centralized version control system (like SVN) and a distributed version control system (like Git)?
Answer: In a Centralized Version Control System (CVCS) like SVN, there is a single central server that stores all the files, and developers check out a single version of the code. If the central server goes down, no one can collaborate or save versioned changes.
Git is a Distributed Version Control System (DVCS). Every developer clones the entire repository, including its full history, to their local machine. This allows developers to work offline, branch locally, and merge seamlessly without relying constantly on a central server. It eliminates the single point of failure.
2. Explain the three main states that a file can reside in within Git.
Answer: Files in Git can be in one of three main states:

1. Modified: You have changed the file locally but have not yet committed it to your database.

2. Staged: You have marked a modified file in its current version to go into your next commit snapshot (using git add).

3. Committed: The data is safely stored in your local Git repository database (using git commit).

3. What is the purpose of the .gitignore file?
Answer: The .gitignore file tells Git which files or directories to ignore and not track. This is crucial for keeping the repository clean of compiled code (e.g., .class, .o files), environment variables (.env), OS-generated files (.DS_Store), and sensitive credentials or large log files.

Section 2: Branching, Merging, and Rebasing
4. What is the exact difference between git merge and git rebase?
Answer: Both commands integrate changes from one branch into another, but they do it differently:

• git merge: Combines the histories of both branches by creating a new "merge commit." It preserves the exact history and chronological order of all commits but can lead to a cluttered, non-linear history.

• git rebase: Moves or "replays" the commits from your current branch onto the tip of the target branch. This rewrites the commit history to create a perfectly linear, clean project history, but it alters the original commit IDs.

Pro Tip: Never rebase commits that have already been pushed to a shared, public repository.

5. What is a "detached HEAD" state in Git?
Answer: The HEAD pointer normally points to the name of the current branch (like main or feature-branch). A "detached HEAD" state occurs when you check out a specific commit hash or a remote branch directly instead of a local branch. You can still make changes and commits, but they will not belong to any branch. If you switch away, those commits will be lost and eventually garbage-collected unless you create a new branch from that detached state using git checkout -b <new-branch-name>.
6. How do you resolve a merge conflict?
Answer: Merge conflicts happen when two branches have competing changes on the exact same lines of a file. To resolve it:

1. Git halts the merge and marks the conflicting files as modified.

2. Open the conflicting files. Git marks the conflict zones with <<<<<<<, =======, and >>>>>>>.

3. Manually edit the file to keep the desired changes and delete the conflict markers.

4. Save the file and run git add <file> to mark the conflict as resolved.

5. Run git commit to finalize the merge.

Section 3: Advanced Operations
7. What does git cherry-pick do, and when would you use it?
Answer: `git cherry-pick` allows you to pick a specific commit from one branch and apply it to your current branch.
Use Case: If a colleague made a bug fix commit in a development branch, but you desperately need that specific fix in the production branch right now without merging all the other unready development code, you can find the commit hash of the bug fix and run git cherry-pick <commit-hash>.
8. Explain the git stash command.
Answer: 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 them later.

• Use git stash to save changes.

• Use git stash pop to apply the stashed changes back and remove them from the stash list.

• Use git stash apply to apply the changes but keep them in the stash list for future use.

9. What is the difference between git reset, git revert, and git checkout?
Answer: * git checkout: Used to switch branches or restore working tree files. It does not alter commit history.

• git revert: Creates a new commit that undoes the changes of a previous commit. This is the safest way to undo changes that have already been pushed to a shared repository because it does not alter history.

• git reset: Rewinds the current branch's history to a previous state. It rewrites history. It should only be used on local commits that haven't been pushed yet. (Variants: --soft, --mixed, --hard).

10. What is git bisect?
Answer: git bisect is a binary search tool that helps you find the specific commit that introduced a bug. You tell Git a "bad" commit (usually HEAD) where the bug exists, and a "good" commit where the code was working. Git will then check out a commit halfway between them. You test the code and tell Git if it's good or bad, and Git halves the search space again until it isolates the exact commit that broke the code.

Section 4: Real-World Scenario Questions
11. Scenario: You just made a commit with a typo in the commit message. You haven't pushed it yet. How do you fix it?
Answer: You can run git commit --amend -m "New corrected commit message". This replaces the last commit with a new one.
12. Scenario: You accidentally pushed a file containing an API key to the remote repository. How do you completely scrub it from the Git history?
Answer: Just deleting the file and committing again is not enough, as the credential will still exist in the commit history. You must rewrite the history.
You can use third-party tools like BFG Repo-Cleaner or the git filter-repo command (which replaces the deprecated git filter-branch). After running the tool to scrub the file from all past commits, you must run a git push --force to overwrite the remote history. (Note: Anyone who has already pulled the compromised history will need to pull a fresh copy, and the API key should still be rotated immediately).
13. Scenario: How do you squash your last 5 commits into a single commit before pushing to the main branch?
Answer: You would use interactive rebase.

1. Run git rebase -i HEAD~5.

2. An editor will open listing the 5 commits. Leave the top commit as pick and change the word pick to squash (or s) for the other 4 commits.

3. Save and close the editor.

4. Git will prompt you to create a new, consolidated commit message. Save and close again.

14. Scenario: Your main branch is broken, and you need to deploy a quick hotfix, but your current branch is full of messy, half-finished work. What do you do?
Answer: 1. Run git stash to safely shelve the uncommitted, half-finished work.
2. Checkout the main branch: git checkout main.
3. Create a hotfix branch: git checkout -b hotfix-issue.
4. Make the fix, commit, and push/merge the hotfix to main.
5. Switch back to your feature branch: git checkout feature-branch.
6. Retrieve your work: git stash pop and continue working.