Git Interview Questions: Complete Guide with Answers

Answer: Git is a distributed version control system (DVCS) created by Linus Torvalds in 2005. Key differences from centralized systems (like SVN):

• Distributed architecture: Every developer has a complete copy of the repository, including full history. Work continues even without network access.
• Snapshot-based, not file-based: Git stores snapshots of the entire repository at each commit, not file differences. This makes branching and merging faster.
• Strong branching model: Branches are lightweight pointers, encouraging frequent branching workflows.
• Data integrity: Everything is checksummed with SHA-1 hashes before storage, making history tamper-evident.
• Staging area: Git has an index/staging area where you can prepare commits before finalizing them.

Why interviewers ask this: This tests whether you understand Git's fundamental architecture, not just memorized commands. It reveals if you know why Git behaves differently from other VCS tools.

Answer: git fetch downloads new data from the remote repository but does not integrate it into your working files. It updates remote-tracking branches (like origin/main) but leaves your local branches unchanged. git pull is essentially git fetch followed by either git merge or git rebase (depending on configuration). It downloads changes and immediately tries to integrate them into your current branch.

Why this matters: Using fetch before pull lets you review changes before integration, avoiding surprise merges. Senior developers often use fetch first to inspect remote changes.

Answer: A merge conflict occurs when Git cannot automatically reconcile changes from two branches that modified the same part of a file. Git pauses the merge and marks conflicted files with special markers:

Resolution steps:

1. Identify conflicted files with git status
2. Edit each file to resolve conflicts: choose one version, combine them, or write new code
3. Remove the conflict markers (<<<<, ====, >>>>)
4. Stage resolved files: git add [file]
5. Complete the merge: git commit (Git generates merge commit message)

You can also use git mergetool to launch a visual merge tool.

Interviewer insight: This tests whether you've actually dealt with conflicts in real work, not just read about them. Follow-up questions might ask about specific conflict scenarios or tools.

Answer: Both integrate changes from one branch into another, but they create different history:

• Merge: Creates a new "merge commit" that has two parents. Preserves the exact history of when branches diverged and were reunited. Shows that parallel development happened.
• Rebase: Takes the commits from your branch and reapplies them on top of another branch, creating new commits with new hashes. Results in a linear history as if the work was done sequentially.

Trade-offs: Merge preserves context but can clutter history. Rebase creates clean history but rewrites commits (dangerous on shared branches).

Answer: There are two main approaches, depending on whether you need to preserve history:

1. git revert (safe for shared branches): Creates a new commit that undoes the changes of a previous commit. History remains intact, and everyone can pull safely.
   $ git revert a1b2c3d # Creates new commit undoing a1b2c3d
   $ git push
2. git reset + force push (only if you're sure): Rewrites history by removing commits. Dangerous on shared branches because others may have pulled the old commits.
   $ git reset --hard HEAD~1 # Remove last commit
   $ git push --force-with-lease # Safer than --force

Rule of thumb: On shared branches, use revert. On personal branches that no one else uses, reset is acceptable.

Answer: Git is fundamentally a content-addressable filesystem with four object types:

• Blob (Binary Large Object): Stores file content, but not the filename. Identical file content = identical blob hash. Stored as blob <size>\0<content>.
• Tree: Represents a directory. Maps filenames to blobs (or other trees) and includes file modes. Stores directory structure.
• Commit: Points to a tree (snapshot of entire repository at that point). Contains parent commit(s), author/committer info, timestamp, and commit message.
• Tag (annotated): Points to a specific commit, with tagger info and message. Used for marking releases.

All objects are stored in .git/objects/, identified by SHA-1 hash of their content. This design ensures data integrity and enables Git's efficiency.

Why this matters: Understanding internals helps debug complex issues, recover lost data, and explains why Git behaves the way it does. Senior roles often require this depth.

Answer: The reflog (reference log) records every movement of HEAD and branch tips in your local repository. It's your safety net for recovering "lost" commits.

Common use cases:

• Recover after bad reset: git reset --hard HEAD@{1} to undo a reset
• Restore deleted branch: Find the last commit hash of the branch in reflog, then git branch recovered-branch [hash]
• Undo rebase mistakes: Find pre-rebase commit in reflog and reset

Reflog entries expire after 90 days by default (configurable with gc.reflogExpire).

Answer: When merging branch B into branch A:

• Fast-forward merge: Possible if A hasn't changed since B branched off. Git simply moves A's pointer forward to B's commit. No merge commit is created.
• Non-fast-forward merge (true merge): Occurs when both branches have diverged. Git creates a new merge commit with two parents.

You can force a merge commit even when fast-forward is possible with git merge --no-ff, which some teams prefer to preserve branch history.

Answer: Git isn't designed for large binary files—they bloat the repository and slow operations. Solutions include:

• Git LFS (Large File Storage): Replaces large files with text pointers in the repository, storing the actual file content on a separate server. When you clone, you get pointers; the actual files are downloaded on demand.
• BFG Repo-Cleaner: Removes large files that were accidentally committed from history.
• Shallow clones: git clone --depth 1 for CI/CD to avoid downloading history.
• Partial clones: git clone --filter=blob:none to fetch blobs only when needed.

Answer: Common branching strategies for environments:

• GitFlow: main (production), develop (integration), release/* (release preparation), hotfix/* (emergency fixes). Good for scheduled releases.
• GitHub Flow: Simple: main is always deployable. Feature branches, PRs, and immediate deployment. Good for continuous delivery.
• GitLab Flow: Adds environment branches (production, pre-production) with merge rules.
• Trunk-based development: Short-lived feature branches, frequent merges to main, release from main with tags.

Configuration management: Never store environment-specific values in Git. Use environment variables, secrets managers, or templated config files with CI/CD substitution.

Answer: Git's garbage collection (git gc) performs several housekeeping tasks:

• Compresses loose objects into packfiles (saves space)
• Removes unreachable objects that are older than gc.pruneExpire (default 2 weeks)
• Consolidates multiple packfiles
• Removes stale reflog entries

Git automatically runs git gc --auto when certain thresholds are met (too many loose objects or packfiles). Manual triggers are useful when:

• After large history rewrites (filter-branch) to clean up
• Before archiving a repository
• When repository performance degrades
• After removing sensitive data from history

Answer: git bisect performs a binary search through commit history to find which commit introduced a bug. It's invaluable for debugging when you know a bug existed in a known bad commit and didn't exist in a known good commit.

Automation: You can automate with git bisect run and a test script:

Answer: When you run git commit, several steps occur:

1. Create blob objects: For each staged file, Git creates a blob object from the file content (if not already existing).
2. Create tree objects: Git builds tree objects representing the directory structure, referencing the new blobs (and existing blobs for unchanged files).
3. Create commit object: Git creates a commit object containing:
   • The hash of the root tree (snapshot)
   • Hash of parent commit(s)
   • Author information (name, email, timestamp)
   • Committer information (may differ from author)
   • Commit message
4. Update HEAD and branch refs: The current branch ref is updated to point to the new commit.
5. Update reflog: An entry is added to the reflog recording this commit.

Answer: Repository corruption requires careful diagnosis and recovery:

1. Diagnose with fsck: git fsck --full identifies corrupted or missing objects.
2. Restore from remote: If corruption is local and remote is healthy, clone fresh and reapply uncommitted work.
3. Recover from other clones: Add a healthy clone as remote: git remote add backup ../healthy-repo; git fetch backup
4. Manual object recovery: For missing objects, try git unpack-objects from packfiles or copy objects from backups.
5. Reinitialize if hopeless: git init in a backup of your working directory, then re-add remotes.

Answer: Git security spans multiple layers:

• Authentication: SSH keys (recommended) with passphrases, or HTTPS with tokens (never passwords). Rotate keys regularly.
• Commit signing: GPG signatures verify that commits genuinely come from claimed authors. Enable with commit.gpgSign and enforce with branch protection.
• Branch protection: Require PR reviews, status checks, and signed commits on protected branches.
• Secrets management: Pre-commit hooks to detect secrets, secret scanning in CI, and tools like git-secrets.
• Access control: Repository permissions (read/write/admin), team-based access, and SAML/SSO integration.
• Audit logging: Enable audit logs on Git hosting platforms and ship to SIEM systems.
• Signed tags: Sign release tags to verify authenticity of releases.

Enterprise implementation: Use Git hosting with enterprise features (GitHub Enterprise, GitLab Self-Managed). Implement automated compliance checks in CI/CD.

Answer: This requires immediate, coordinated action:

1. ROTATE SECRETS FIRST: Immediately revoke the exposed API keys. The secret was public for 30 minutes—assume compromise.
2. Clean Git history: Use git filter-repo or BFG to remove the file from all history. This rewrites history, changing commit SHAs.
3. Force push clean history: git push --force --all (with coordination).
4. Notify all developers: They must reset their local repositories:
   $ git fetch --all
   $ git reset --hard origin/main
5. Check for forks/clones: If the repository was public or widely cloned, consider the secret permanently exposed.
6. Prevent recurrence: Add pre-commit hooks with secret detection, enable secret scanning in GitHub/GitLab.

Answer: Implement path-based filtering in CI/CD:

• GitHub Actions: Use paths in workflow triggers:

• GitLab CI: Use changes keyword:

• Custom script: In CI, compute changed files with git diff --name-only $PREVIOUS_SHA $CURRENT_SHA and conditionally run steps.
• Dependency awareness: Include shared libraries in deployment triggers for services that depend on them.

Answer: Follow the hotfix workflow:

1. Create hotfix branch from the production tag (not main):
   $ git checkout -b hotfix/critical-bug v2.1.0
2. Apply the fix, commit with message: hotfix: resolve critical bug
3. Test thoroughly
4. Merge to main and tag:
   $ git checkout main
   $ git merge --no-ff hotfix/critical-bug
   $ git tag -a v2.1.1 -m "Hotfix release"
5. Also merge to develop to ensure fix isn't lost:
   $ git checkout develop
   $ git merge --no-ff hotfix/critical-bug
6. Delete hotfix branch: git branch -d hotfix/critical-bug

Key point: Merging to both main and develop ensures the fix persists in all future releases.

Answer: Follow this recovery process:

1. Check if branch was ever pushed: git branch -a | grep feature-name
2. If found on remote, recover with: git checkout -b recovered-branch origin/feature-name
3. If not on remote, check local reflog: git reflog | grep feature-name
4. Look for commits around the time the branch was last active:
   $ git reflog --date=local | grep "checkout: moving from feature"
   $ git log --oneline -g --grep="feature"
   $ git fsck --lost-found | grep commit
5. Once you find likely commit hashes, inspect them: git show [hash]
6. Create branch at found commit: git branch recovered-feature [hash]
7. If multiple commits, cherry-pick or rebase to reconstruct

Prevention: Encourage regular pushing to remote and educate about reflog as safety net.

Answer: A structured migration plan:

1. Assessment: Analyze SVN repository structure, identify large files, understand branching patterns.
2. Tool selection: Use git svn clone for migration, or specialized tools like svn2git.
3. Pilot migration: Migrate a non-critical project first to test workflow.
4. Training:
   • Workshop on Git concepts (distributed, staging, branching)
   • Common workflows (feature branches, PRs)
   • Daily commands vs. SVN equivalents
   • GUI tools for those who prefer visual interfaces
5. Documentation: Create team-specific Git workflow guide, cheat sheets, and troubleshooting FAQ.
6. Migration weekend: Final conversion of all repositories, update CI/CD pipelines.
7. Post-migration support: Pair programming, office hours for questions, collect feedback.

Common pitfalls: Ignoring .gitignore, committing large files, force-pushing to shared branches.