Git Interview Questions and Answers

Basic Git Concepts

1. What is Git?
Answer: Git is a distributed version control system that tracks changes in source code during software
development. It was designed for coordinating work among programmers, but can be used to track
changes in any set of files. Git's key features include its distributed nature, branching model, staging area,
and speed.

2. What is the difference between Git and GitHub?

Answer: Git is a version control system that allows developers to track changes in their code. GitHub is a
cloud-based hosting service that lets you manage Git repositories. In simple terms, Git is the tool, while
GitHub is a service that hosts Git repositories and provides additional collaboration features like pull
requests, issues, and project management tools.

3. What is a repository in Git?

Answer: A Git repository is a directory or storage space where your project lives. It contains all of your
project's files and stores each file's revision history. Repositories can exist locally on your computer or as a
remote copy on another computer or server.

4. Explain the basic Git workflow.

Answer: The basic Git workflow consists of:

1. Modify files in your working directory

2. Stage the changes you want to include in your next commit using git add

3. Commit your changes with a meaningful message using git commit

4. Push your changes to a remote repository using git push (if working with remote repositories)

5. What's the difference between Git pull and Git fetch?

Answer:

git fetch downloads new data from a remote repository but doesn't integrate any of this new data
into your working files. It updates your remote-tracking branches.

git pull does a git fetch followed by a git merge . It updates your remote-tracking branches
and then merges the remote changes into your local working branch.

Intermediate Git Questions

6. What is Git rebase and how is it different from merge?

Answer: Both git rebase and git merge are designed to integrate changes from one branch into
another branch.

git merge creates a new commit (merge commit) that combines changes from both branches while

preserving the branch history.

git rebase moves or combines a sequence of commits to a new base commit, effectively rewriting

the commit history. It results in a linear project history.

Key difference: Merge preserves history as it actually happened, while rebase creates a cleaner, linear
history.

7. What is Git stash?

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. It's useful when you need to
switch contexts quickly or when you're not ready to commit your changes but need to work on
something else.

8. What is a detached HEAD state in Git?

Answer: A detached HEAD state in Git 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. Any new commits made in this state won't belong to any branch and can be lost if you switch
to another branch without creating a new branch to retain these commits.

9. How do you resolve merge conflicts in Git?

Answer: To resolve merge conflicts in Git:

1. Run git status to identify conflicting files

2. Open the conflicting files and look for the conflict markers ( <<<<<<< , ======= , >>>>>>> )

3. Edit the files to resolve the conflicts by deciding which changes to keep

4. Stage the resolved files using git add

5. Complete the merge by running git commit

10. What is Git bisect and how do you use it?

Answer: git bisect is a Git utility that uses a binary search algorithm to find which commit in your
project history introduced a bug. Basic usage:

1. Start the bisect process: git bisect start

2. Mark the current commit as bad: git bisect bad

3. Mark a known good commit: git bisect good <commit-hash>

 4. Git will checkout a commit halfway between the good and bad commits
5. Test your code and mark the commit as good or bad: git bisect good or git bisect bad

6. Repeat until Git identifies the first bad commit

7. End the bisect process: git bisect reset

Advanced Git Questions

11. Explain Git hooks.

Answer: 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 customizable actions at key points in the
development life cycle. Common hooks include pre-commit (run before a commit is finalized), post-
commit, pre-push, and post-receive. Hooks are stored in the .git/hooks directory of a Git repository.

12. What is Git cherry-pick?

Answer: git cherry-pick is a command that allows you to apply the changes introduced by some
existing commits to your current working HEAD. It's useful when you want to pick specific commits from
one branch and apply them to another branch, rather than merging or rebasing the entire branch.

Usage: git cherry-pick <commit-hash>

13. What is Git reflog?

Answer: Git reflog (reference log) is a mechanism that records when the tip of branches and other
references were updated in the local repository. It provides a history of HEAD and branch references and
allows you to recover from operations that would otherwise lose commits, such as a hard reset. You can
use git reflog to find and restore lost commits.

14. Explain the difference between reset, revert, and checkout in Git.
Answer:

git reset is used to move the current branch to a specific commit, optionally updating the staging
area and working directory. It can discard commits in your private branch or unstage changes.

git revert creates a new commit that undoes the changes from a previous commit. It's safe for
public branches as it doesn't change history.

git checkout is used to switch branches or restore working tree files. It can be used to view old
commits without changing the current branch state.

15. What are Git submodules and when would you use them?
Answer: Git submodules allow you to keep a Git repository as a subdirectory of another Git repository.
This lets you include or embed one repository as a subdirectory within another repository. You might use
submodules when:

You want to incorporate third-party code into your project while keeping their code separate

You want to share a component across multiple projects

You have a large project that you want to split into smaller, more manageable repositories

Practical Git Questions

16. How would you undo the last commit in Git?

Answer: There are several ways to undo the last commit:

To undo the commit but keep the changes staged: git reset --soft HEAD~1

To undo the commit and unstage the changes: git reset HEAD~1

To completely discard the commit and all changes: git reset --hard HEAD~1

To create a new commit that undoes the previous commit: git revert HEAD

17. How do you squash multiple commits into one?

Answer: You can squash multiple commits into one using interactive rebase:

1. git rebase -i HEAD~n (where n is the number of commits to review)

2. In the editor that opens, change "pick" to "squash" or "s" for all commits you want to combine
(except the first one)

3. Save and close the editor

4. Another editor will open to let you edit the combined commit message

5. Save and close to complete the squash

18. How do you remove sensitive data from a Git repository?

Answer: To remove sensitive data from a Git repository:

1. Use git filter-repo (or git filter-branch as a legacy option) to rewrite history, removing the
sensitive files

2. Run git push --force to overwrite the history on the remote repository

3. Request all collaborators to re-clone the repository

4. Remember that the data will still exist in old clones and forks

For password or key removal, immediately change credentials as historical data might remain accessible.

19. How would you find which commit introduced a specific bug?
Answer: You can use git bisect to find which commit introduced a bug:
 1. Start the bisect: git bisect start

2. Mark the current commit as containing the bug: git bisect bad

3. Mark a known good commit that didn't have the bug: git bisect good <commit-hash>

4. Git will check out a commit halfway between these points

5. Test your code and tell Git if this commit is good or bad: git bisect good or git bisect bad

6. Repeat until Git identifies the first bad commit

7. End the bisect process: git bisect reset

20. How do you keep a fork updated with the original repository?
Answer: To keep a fork updated with the original repository:

1. Add the original repository as a remote (conventionally called "upstream"): git remote add
upstream https://github.com/original-owner/original-repository.git

2. Fetch the branches and commits from the upstream repository: git fetch upstream

3. Check out your fork's local default branch: git checkout main

4. Merge the changes from the upstream default branch: git merge upstream/main

5. Push the changes to your fork: git push origin main

Git Workflow Questions

21. What is GitFlow and when would you use it?

Answer: GitFlow is a branching model for Git that uses feature branches and multiple primary branches.
It consists of:

Main branch for official releases

Develop branch as the integration branch

Feature branches for new features

Release branches for version preparation

Hotfix branches for critical bug fixes

GitFlow is beneficial for projects with scheduled releases and long-term support but may be overly
complex for continuous delivery workflows.

22. What is Trunk-Based Development in Git?

Answer: Trunk-Based Development is a version control management practice where developers merge
small, frequent updates to a core "trunk" or main branch. This approach:

Maintains a single branch (the trunk) that's always in a releasable state

 Uses short-lived feature branches (typically less than a day)
Emphasizes continuous integration

Supports continuous delivery practices

It's simpler than GitFlow and facilitates faster development cycles, but requires stronger testing practices.

23. Explain the GitHub Flow workflow.

Answer: GitHub Flow is a lightweight workflow that consists of:

1. Create a branch from the main branch for a new feature or fix
2. Add commits with your changes

3. Open a pull request to initiate discussion

4. Review and discuss the code in the pull request

5. Deploy and test from your branch (optional)

6. Merge into main when approved

This workflow is simple, suitable for continuous delivery, and encourages collaboration through pull
requests.

24. What is a good Git commit message structure?

Answer: A good Git commit message follows this structure:

1. A short, imperative subject line (50 characters or less) that completes the sentence "If applied, this
commit will..."

2. A blank line
3. A detailed explanation of what the change does and why (wrapped at 72 characters)

4. References to issue trackers if applicable

Example:

Fix authentication timeout issue

Increase token expiration time to 24 hours to prevent users from being

logged out during normal usage periods. This addresses the top user
complaint in the feedback system.

Fixes #1234

25. How do you enforce code quality standards with Git?

Answer: You can enforce code quality standards with Git using:
 1. Git hooks (particularly pre-commit hooks) to run linters, tests, and style checkers before commits
2. CI/CD pipelines that run on pull requests to verify code quality

3. Protected branches with required status checks before merging

4. Code reviews via pull requests

5. Git attributes to enforce specific checks for specific file types

6. Branch policies that require approvals before merging

Git Security Questions

26. What are Git signed commits and why are they important?
Answer: Git signed commits are commits that have been cryptographically signed with a GPG, SSH, or
S/MIME key to verify the identity of the committer. They're important because:

They prove that the commit truly came from the verified author

They ensure the commit hasn't been tampered with

They help maintain the integrity of your codebase

They add an extra layer of security for critical repositories

You can sign commits using git commit -S or configure Git to sign all commits automatically.

27. How can you protect sensitive data in Git repositories?

Answer: To protect sensitive data in Git repositories:

1. Use .gitignore files to avoid committing sensitive files

2. Consider using git-crypt or git-secret for encrypting sensitive files

3. Use environment variables instead of hardcoding credentials

4. Implement pre-commit hooks to check for secrets or sensitive patterns

5. Use tools like GitGuardian or Gitleaks to scan for secrets

6. Use Git LFS for large files that might contain sensitive data

7. Implement branch protection rules requiring reviews before merges

28. What is a GitHub Security Advisory?

Answer: A GitHub Security Advisory is a platform feature that allows repository maintainers to privately
discuss, fix, and publish information about security vulnerabilities in their code. It enables:

Creating private vulnerability reports

Discussing and fixing vulnerabilities in private forks

Publishing advisories to alert users
 Automatically suggesting dependency updates to fix vulnerabilities
Issuing CVE (Common Vulnerabilities and Exposures) identifiers

Triggering Dependabot alerts for affected repositories

Performance and Scale Questions

29. How do you improve performance with large Git repositories?

Answer: To improve performance with large Git repositories:

1. Use shallow clones ( git clone --depth 1 ) when full history isn't needed

2. Utilize Git LFS (Large File Storage) for binary and large files
3. Use sparse-checkout to only check out needed directories

4. Implement Git Virtual File System (VFS) for very large repositories
5. Regularly clean up your repository with git gc and git prune

6. Split monolithic repositories into smaller ones where appropriate

7. Use partial clones ( git clone --filter=blob:none ) to exclude large objects

8. Configure Git to use better delta compression with git config --global core.compression 9

30. What is Git LFS and when should you use it?
Answer: Git LFS (Large File Storage) is an extension that replaces large files with text pointers inside Git,
while storing the file contents on a remote server. You should use Git LFS when:

Your repository contains large binary files (images, audio, video, datasets)
Your repository is growing too large due to binary assets

You want to track large files without bloating your Git history
You need better performance when working with repositories containing large files

You want to reduce clone and fetch times for repositories with large assets

Troubleshooting Git Issues

31. How do you recover a deleted branch in Git?

Answer: To recover a deleted branch in Git:

1. Find the SHA hash of the branch's tip using git reflog

2. Create a new branch at that commit: git checkout -b recovered-branch <SHA-hash>

If the branch was already pushed to a remote and you don't have the SHA hash locally:

1. Fetch all data from the remote: git fetch origin

 2. Check if the branch is still on the remote: git branch -a

3. If found, recreate it locally: git checkout -b recovered-branch origin/deleted-branch

32. What would you do if Git reports "fatal: refusing to merge unrelated histories"?
Answer: This error occurs when Git detects that the histories of two branches you're trying to merge
don't share a common ancestor. To resolve this:

1. Use the --allow-unrelated-histories flag to force the merge: git merge --allow-unrelated-
histories branch-name

2. Then resolve any conflicts that arise and commit the merge

This situation commonly occurs when:

Initializing a local repository and then trying to pull from a remote repository

Cloning an empty repository and pushing local commits

Trying to merge two separate repositories

33. How do you fix a detached HEAD state?

Answer: To fix a detached HEAD state:

1. If you want to keep the changes made in the detached HEAD:

Create a new branch where you are: git branch new-branch-name

Switch to that branch: git checkout new-branch-name

2. If you want to discard the changes:

Simply checkout an existing branch: git checkout main

If you've already moved away from the detached HEAD state and want to recover those commits:

1. Use git reflog to find the SHA hash of the lost commit

2. Create a branch at that commit: git branch recovery-branch <SHA-hash>

34. How can you find and remove large files from Git history?
Answer: To find and remove large files from Git history:

1. Find large files: git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %
(objectname) %(objectsize) %(rest)' | sort -k3nr | head -10

2. Remove them using git filter-repo :

pip install git-filter-repo

git filter-repo --path path/to/large/file --invert-paths
 3. Force push to update the remote repository: git push --force origin main

4. Ask collaborators to re-clone or carefully rebase their work

35. What does "Your branch is ahead of 'origin/main' by X commits" mean?

Answer: This message means you have X commits on your local branch that you haven't pushed to the
remote repository yet. It's not an error, but indicates that your local branch has diverged from the remote
branch. To resolve this:

If you want to share your changes: git push origin main

If these are unwanted changes: reset your branch with git reset --hard origin/main

If you need to integrate with new remote changes first: git pull or git pull --rebase

DevOps and CI/CD with Git

36. How do you integrate Git with CI/CD pipelines?

Answer: To integrate Git with CI/CD pipelines:

1. Configure your CI/CD tool (Jenkins, GitHub Actions, GitLab CI, etc.) to monitor your repository for
changes
2. Set up webhooks or polling to trigger pipeline runs on specific events (pushes, pull requests)

3. Define pipeline configurations in code (e.g., GitHub Actions workflows, Jenkinsfile)

4. Use protected branches and status checks to ensure CI passes before merging

5. Implement branch-specific pipelines for different environments

6. Use Git tags or specific branches to trigger deployments

7. Consider implementing GitOps practices where Git becomes the source of truth for your
infrastructure

37. What is GitOps and how does it relate to traditional Git workflows?
Answer: GitOps is an operational framework that applies Git principles to infrastructure and deployment
automation. It:

Uses Git repositories as the single source of truth for infrastructure and applications

Implements changes to infrastructure through pull requests

Automates infrastructure updates based on changes to the Git repository
Uses declarative descriptions of the entire system

Provides automatic drift detection and remediation

While traditional Git workflows focus on application code, GitOps extends these practices to infrastructure
and deployment configuration, treating infrastructure as code.
38. How can you implement feature flags using Git?
Answer: While Git itself doesn't implement feature flags, you can use Git to manage feature flag
configurations:

1. Store feature flag configurations in version-controlled files

2. Use branches to develop and test different flag configurations

3. Implement a CI/CD pipeline that:

Extracts flag configurations from Git

Updates a feature flag service or configuration files

Deploys the updated configuration

4. Use pull requests to review and approve flag changes

5. Consider using Git tags to mark specific feature flag states for releases
6. Maintain a history of feature flag changes for auditing and rollbacks

This approach allows you to separate code deployment from feature activation and manage the feature
lifecycle through Git.

39. What is trunk-based development and how does it support continuous integration?
Answer: Trunk-based development is a Git branching strategy where developers collaborate on a single
branch (usually "main" or "trunk") and:

Make small, frequent commits directly to the trunk

Use short-lived feature branches (typically less than a day)

Continuously integrate all developer changes
Keep the trunk in a deployable state at all times

This approach supports continuous integration by:

Minimizing merge conflicts through frequent integration

Reducing integration debt by keeping branches short-lived

Creating a constant flow of small changes that are easier to test and debug
Enabling faster feedback cycles

Supporting more frequent releases

Reducing the complexity of the branching model

40. How would you implement Git-based disaster recovery for code?
Answer: To implement Git-based disaster recovery for code:

1. Maintain multiple remote repository copies (GitHub/GitLab/Bitbucket plus additional backups)

 2. Implement regular mirroring to secondary remotes: git push --mirror backup-remote

3. Use Git bundles for offline backups: git bundle create repo-backup.bundle --all

4. Store bare clones on secure backup systems

5. Back up all Git hooks and configuration files

6. Document recovery procedures and test them regularly

7. Consider using tools like BFG or git-filter-repo for emergency removal of sensitive data

8. For hosted Git services, implement API-based backup solutions that capture issues, pull requests, and
other metadata

Team Collaboration with Git

41. How can Git support code review processes?

Answer: Git supports code review processes through:

1. Pull/Merge Requests - a way to propose changes that can be reviewed before merging
2. Branch protection rules - requiring reviews before merging

3. Comments on specific lines of code within pull requests

4. Review states (approve, request changes, comment)

5. Required reviewers functionality

6. Commit-by-commit review capability
7. Blame view to identify who changed specific lines

8. Integration with code review tools like Gerrit or Review Board

9. Webhooks for notifying team members about pull requests

10. Automated checks that can run on pull requests to validate code quality

42. What is a good branching strategy for supporting multiple versions of a product?
Answer: A good branching strategy for supporting multiple versions would be:

1. Maintain a separate long-lived branch for each supported version (e.g., release/v1.x ,
release/v2.x )

2. Make all new feature development on the main branch

3. Cherry-pick critical bug fixes to the appropriate release branches

4. Use tags to mark specific releases within each branch (e.g., v1.1.0 , v1.2.0 )

5. Create hotfix branches from release branches for urgent fixes

6. Automate testing for all branches to ensure they remain stable
7. Document the differences between versions and the support policy
 8. Consider a "long-term support" (LTS) designation for specific versions

43. How would you onboard a new developer to your Git workflow?
Answer: To onboard a new developer to a Git workflow:

1. Provide documentation on your branching strategy and workflow

2. Create a repository onboarding guide covering:
How to clone the repository
Branch naming conventions
Commit message guidelines

Code review process

CI/CD pipeline details

3. Set up their Git configuration with team standards

4. Assign a mentor for Git-related questions
5. Start with small, well-defined tasks

6. Conduct pair programming sessions focusing on Git operations

7. Review their first few pull requests carefully and provide detailed feedback

8. Share common Git aliases and tools used by the team

9. Document solutions to common Git issues specific to your environment

44. How do you manage dependencies between Git repositories?

Answer: To manage dependencies between Git repositories:

1. Git Submodules: Include one repository inside another at a specific commit

2. Git Subtrees: Import the code from another repository into a subdirectory

3. Package Managers: Use npm, pip, Maven, etc., to manage dependencies

4. Monorepos: Consider combining related repositories into a single repository

5. Git Hooks: Automate actions when dependencies are updated

6. Dependency Management Tools: Use tools like Dependabot to keep dependencies updated
7. Artifact Repositories: Store built artifacts in a repository like Artifactory

8. Versioned APIs: Define clear interfaces between repositories

9. Meta-repositories: Create a repository that coordinates multiple repositories (like Google's Repo tool)

45. What is a monorepo and what are its advantages and disadvantages?
Answer: A monorepo is a version control strategy where multiple projects or components are stored in a
single repository.
Advantages:

Simplified dependency management

Atomic changes across projects

Unified versioning and releases

Easier code sharing and collaboration

Consistent tooling and standards
Simplified CI/CD configuration

Better visibility across projects

Disadvantages:

Can grow very large, leading to performance issues

Access control is more complex
Requires more sophisticated build systems

Can be challenging to onboard new developers

May require specialized tools for scaling Git

Teams may have less autonomy

Can lead to tighter coupling between components

Git in Different Contexts

46. How do Git practices differ in open source versus enterprise environments?
Answer: Git practices in open source versus enterprise environments differ in several ways:

Open Source:

Fork and pull request model is common

Public code reviews

Emphasis on contributor guidelines

Distributed maintainership
Lighter governance

More focus on public documentation

Often uses GitHub/GitLab/similar platforms' built-in tools

More emphasis on signed commits for trust

Enterprise:

Direct repository access is more common

 Private code reviews
Formal approval processes

Centralized control
Stricter governance

Integration with enterprise tools

Often uses self-hosted or enterprise versions of Git tools

May have compliance and audit requirements

Often integrates with project management tools

47. How would you implement Git for data science projects?
Answer: For data science projects, implement Git with these considerations:

1. Use Git LFS for large data files and models

2. Create .gitignore files specific to data science tools (ignore caches, checkpoints)
3. Version datasets separately from code when appropriate

4. Document environment configurations with requirements.txt or environment.yml

5. Use branches for exploratory analysis and experiments

6. Create templates for Jupyter notebooks to minimize metadata conflicts

7. Consider tools like DVC (Data Version Control) alongside Git

8. Implement pre-commit hooks for notebook cleaning

9. Use clear naming conventions for experiment branches

10. Document model parameters and results in commit messages

48. How does Git support infrastructure as code?

Answer: Git supports infrastructure as code (IaC) by:

1. Providing version control for infrastructure definitions

2. Enabling change tracking for infrastructure configurations

3. Supporting branching for testing infrastructure changes
4. Facilitating code reviews for infrastructure modifications

5. Creating an audit trail of infrastructure changes

6. Enabling rollbacks to previous infrastructure states

7. Supporting GitOps workflows for automated infrastructure deployments

8. Allowing collaboration on infrastructure definitions

9. Integrating with CI/CD pipelines for infrastructure testing and deployment

10. Enabling infrastructure configurations to be treated with the same rigor as application code

49. How does Git support database version control?

Answer: Git supports database version control through:

1. Schema migration scripts stored in Git

2. Database change management tools like Flyway or Liquibase integrated with Git

3. SQL scripts versioned in Git repositories

4. Database state represented as code (schema definitions)
5. Change history tracking for database structures

6. Branching for testing database changes

7. CI/CD pipelines that apply migration scripts from Git

8. Pull requests to review database changes

9. Tagging for database releases

10. Integration with automated database testing

Note that Git is best for the scripts and definitions, not for the actual data, which is typically managed
separately.

50. How can Git be used in regulated environments (healthcare, finance)?

Answer: In regulated environments like healthcare and finance, Git can be used with these
considerations:

1. Implement strict access controls and permissions

2. Use signed commits to verify author identity
3. Enable comprehensive audit logging of all Git operations

4. Implement branch protection rules requiring approvals

5. Use Git hooks to enforce compliance checks

6. Document all procedures and policies for Git usage

7. Integrate with compliance-focused code scanning tools
8. Create detailed release processes with approval gates

9. Implement segregation of duties through repository permissions

10. Maintain evidence of reviews and approvals for auditors

11. Use Git to version regulatory documentation alongside code

12. Implement immutable references (tags) for released versions

13. Configure Git to retain all history permanently (disable force pushes)
14. Use Git for traceability between requirements and implementation
15. Integrate with document management systems when necessary