Top 30 GIT Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   Which conventional commit best documents a fix for a date sorter that incorrectly assumed US locale formats?

   • afix: resolve date sorting bug
   • bfix(date-parser): date sorting was fixed for non-US formats with no additional body
   • cfix(date-parser): handle locale-aware date sorting with body noting the previous hardcoded US locale assumption
   • dfeat(date-parser): add locale-aware date sorting with body describing browser locale detection
   Show the answer

   Answer: c · fix(date-parser): handle locale-aware date sorting with body noting the previous hardcoded US locale assumption

   Option C correctly uses the fix type and date-parser scope, an imperative subject, and a body that explains the root cause to prevent future regressions. Option D is a tempting distractor because the change does add locale logic, but feat signals a minor SemVer bump and misrepresents a bug patch.

   Read the full bite: Write a conventional commit for a non-US date sorting bug

2. Question 2 of 30

   Which of the following is the primary security benefit of adopting a pull-based GitOps deployment model?

   • aIt prevents the exposure of production cluster credentials to external CI/CD pipelines or systems.
   • bIt eliminates the need for any external CI/CD system to interact with the production cluster.
   • cIt allows for easier rollback of changes by simply reverting a commit in the Git repository.
   • dIt ensures that all infrastructure changes are thoroughly reviewed via pull requests before deployment.
   Show the answer

   Answer: a · It prevents the exposure of production cluster credentials to external CI/CD pipelines or systems.

   The card states that the pull-based model is more secure as it "avoids exposing cluster credentials externally," contrasting it with the push-based model that "requires giving your CI system powerful, high-risk credentials." Option D describes a general benefit of using Git for configuration, not a specific security advantage of the pull-based model.

   Read the full bite: GitOps: Your Git Repo is the Single Source of Truth

3. Question 3 of 30

   How does rebasing a feature branch onto main before a PR typically affect CI behavior compared to merging main into that branch?

   • aRebase keeps the original commit SHAs intact, so existing CI build results remain valid and only one new build runs.
   • bRebase generates new commit SHAs, causing CI to treat rebased commits as new pushes and queue multiple builds.
   • cRebase is safer than merge because it avoids merge commits, while merge pollutes history and causes redundant CI builds.
   • dMerge rewrites commit SHAs to create a linear history, invalidating previous CI results and triggering several new builds.
   Show the answer

   Answer: b · Rebase generates new commit SHAs, causing CI to treat rebased commits as new pushes and queue multiple builds.

   Rebase replays commits onto the target branch, which creates fresh SHAs that CI systems treat as brand-new pushes, burning compute minutes and orphaning prior build results, whereas merge preserves the original SHAs and triggers a single integration build. Option C is tempting because many beginners believe rebase is inherently cleaner or safer, but it actually requires force-push and breaks the one-to-one link between a commit and its CI result.

   Read the full bite: Difference between git merge and git rebase before a pull request

4. Question 4 of 30

   Why should a team not rely solely on a pre-push hook to guarantee that all tests pass before merging?

   • aIt is local-only, not cloned with the repository, can be skipped with --no-verify, and does not run for web or API commits.
   • bThe --no-verify flag only skips commit hooks, meaning pre-push checks cannot be bypassed by developers.
   • cIt must be committed to version control before Git will automatically execute it for everyone who clones the repository.
   • dIt runs on the remote server after the push completes, so it cannot prevent broken code from entering the repository.
   Show the answer

   Answer: a · It is local-only, not cloned with the repository, can be skipped with --no-verify, and does not run for web or API commits.

   Pre-push hooks reside in .git/hooks and are not copied on clone, can be bypassed with --no-verify, and do not run for web or API commits, so they cannot replace server-side enforcement. Option B is a tempting misconception: --no-verify skips pre-push hooks as well as commit hooks.

   Read the full bite: Describe using a pre-push Git hook for checks and its CI limitations.

5. Question 5 of 30

   Which statement best describes a core operational principle of a Distributed Version Control System (DVCS)?

   • aCollaboration relies on developers directly sharing their local changes with each other's machines without a central hub.
   • bEach developer works with a complete, independent copy of the entire project history on their local machine.
   • cDevelopers only download the most recent version of specific files they intend to modify, saving local storage.
   • dAll changes made by a developer are immediately reflected on a central server upon commit.
   Show the answer

   Answer: b · Each developer works with a complete, independent copy of the entire project history on their local machine.

   A DVCS provides every developer with a full, independent copy of the entire repository and its history, allowing most operations to occur locally. Option D describes a centralized system, where commits are immediately synchronized with a single server.

   Read the full bite: Distributed Version Control (DVCS): Everyone Gets a Copy

6. Question 6 of 30

   What does a Git commit fundamentally represent?

   • aA record of only the differences between the current state and the previous commit.
   • bA temporary collection of changes staged for potential future saving.
   • cA complete snapshot of all tracked files in the project at a specific point in time.
   • dThe descriptive message, author, and timestamp associated with a set of modifications.
   Show the answer

   Answer: c · A complete snapshot of all tracked files in the project at a specific point in time.

   A Git commit is described as a 'permanent snapshot of your entire project,' containing the complete state of all tracked files. Option A is a common misconception, as Git stores full snapshots, not just diffs. Options C and D describe aspects of the commit process or metadata, not the core content of the commit itself.

   Read the full bite: Git Commit: A Snapshot, Not a Diff

7. Question 7 of 30

   When integrating a 50-commit stale branch that others may have pulled, which strategy best preserves shared history while validating pipeline stability?

   • aRebase onto main and force-push to maintain linear history, assuming collaborators can reset their local copies
   • bOpen a normal pull request with the conflicted branch so reviewers can assess the conflicts before you resolve them
   • cMerge main into the feature branch locally, resolve conflicts, run full tests, and open a draft PR before merging
   • dSquash the 50 commits and push directly to main after local conflict resolution, letting post-merge CI validate the result
   Show the answer

   Answer: c · Merge main into the feature branch locally, resolve conflicts, run full tests, and open a draft PR before merging

   Merging main into the feature branch preserves commit hashes and shared history, while a draft PR exercises the full CI pipeline without spamming reviewers or triggering merge queues prematurely. Rebasing and force-pushing is dangerous because it rewrites public history and breaks every collaborator's local environment.

   Read the full bite: How do you safely merge a 50-commit stale branch with conflicts?

8. Question 8 of 30

   You've committed a file to your Git repository. Later, you decide this file should not be tracked. What is the correct way to stop Git from tracking it using .gitignore?

   • aGit will ignore future changes to the file if its pattern is in .gitignore, but keep the existing version in history.
   • bAdd the file's pattern to .gitignore, and Git will automatically untrack it.
   • cUse git rm --cached <file> and then add the file's pattern to .gitignore.
   • dDelete the file from your local directory, then add its pattern to .gitignore.
   Show the answer

   Answer: c · Use git rm --cached <file> and then add the file's pattern to .gitignore.

   The card states that .gitignore only works on untracked files. To stop tracking a file already committed, you must first remove it from the index using git rm --cached <file>, then add its pattern to .gitignore to prevent it from being tracked again. Simply adding it to .gitignore (option B) will not affect files already under version control.

   Read the full bite: .gitignore: Telling Git What to Ignore

9. Question 9 of 30

   After force-pushing a Git history rewritten with git-filter-repo to remove leaked credentials, why must teammates delete their local clones and re-clone rather than pull?

   • aA pull-and-push from their stale local branch would recontaminate the remote with the old commits containing the secret
   • bTheir local reflog retains the old commits, which could resurface the secret during a later merge
   • cgit-filter-repo changes commit timestamps so git pull produces irreconcilable merge conflicts
   • dBranch protection rules invalidate existing tracking branches until manually re-enabled on each clone
   Show the answer

   Answer: a · A pull-and-push from their stale local branch would recontaminate the remote with the old commits containing the secret

   The card explicitly warns that a teammate who pulls and then pushes from a stale local clone will reintroduce the old commits containing the secret back to the remote. While reflogs retain local history, the critical blast radius is recontamination of the shared repository, not a local merge issue.

   Read the full bite: How do you fully remove leaked credentials from Git history?

10. Question 10 of 30

    What is the primary reason Git's branching model is considered superior to older version control systems?

    • aIt ensures that all code changes are immediately synchronized across all developer machines.
    • bIt allows for rapid creation of isolated development lines without duplicating the entire codebase.
    • cIt eliminates the need for manual merging of code changes.
    • dIt provides a built-in mechanism for automatic code review before merging.
    Show the answer

    Answer: b · It allows for rapid creation of isolated development lines without duplicating the entire codebase.

    The card states that Git branches are lightweight pointers, not full copies, making their creation and switching nearly instant. This contrasts with older VCS that often required heavy, full copies, which discouraged frequent branching. Option B directly captures this core advantage.

    Read the full bite: Git Branch: A Lightweight Pointer, Not a Full Copy

11. Question 11 of 30

    What is the primary role of a Pull Request in a team's software development workflow?

    • aTo directly trigger the deployment of new features to production environments after a successful build.
    • bTo automatically merge a developer's feature branch into the main branch upon completion.
    • cTo provide a formal mechanism for discussing, reviewing, and approving code changes before integration.
    • dTo track the individual contributions and commit history of each developer in the project.
    Show the answer

    Answer: c · To provide a formal mechanism for discussing, reviewing, and approving code changes before integration.

    The card emphasizes that a Pull Request is a "structured conversation about a proposed code change" and exists "to create a formal, collaborative process for proposing, discussing, and reviewing code changes." While merging is the ultimate goal, the core purpose is the review and discussion. Option B is a tempting distractor because merging is the outcome, but it misses the crucial review and approval steps.

    Read the full bite: Pull Requests: A Structured Conversation About Code

12. Question 12 of 30

    In a CI/CD context, why does merging an upstream dependency change naturally trigger the parent pipeline with git subtree but not with git submodules?

    • aSubtree maintains the dependency as a separate repository pointer, allowing the parent CI to detect upstream changes via remote polling.
    • bSubtree creates a new commit in the parent repository when merging the dependency, while submodules only update a pointer requiring a separate superproject commit.
    • cSubtree pins the parent to a specific dependency commit, forcing a rebuild, whereas submodules track the latest upstream branch lazily.
    • dSubmodules require recursive cloning that CI agents skip by default, preventing the trigger from propagating to the parent.
    Show the answer

    Answer: b · Subtree creates a new commit in the parent repository when merging the dependency, while submodules only update a pointer requiring a separate superproject commit.

    Subtree creates an actual commit in the parent repository when a dependency is merged, which CI systems detect as a repository change, whereas submodules only update a pointer file and require an explicit superproject commit to register. Distractor C describes a real submodule checkout failure mode but confuses clone-time behavior with pipeline trigger semantics.

    Read the full bite: Compare git submodules and git subtree for CI/CD

13. Question 13 of 30

    When integrating a feature branch into the main branch using git merge, what is the most significant characteristic of the resulting history?

    • aThe feature branch is automatically deleted after its changes are incorporated into the main branch.
    • bAll changes from the feature branch are consolidated into a single commit, simplifying the project history.
    • cA new commit is generated on the target branch, explicitly recording the point where two distinct development lines converged.
    • dThe feature branch's commits are re-applied sequentially onto the main branch, creating a perfectly linear history.
    Show the answer

    Answer: c · A new commit is generated on the target branch, explicitly recording the point where two distinct development lines converged.

    The card explains that git merge creates a "new, single commit that formally joins these two timelines" and acts as "a knot, holding the two threads together by having two parents." This merge commit explicitly records the convergence of distinct development lines. Option D describes git rebase, which rewrites history to create a linear sequence of commits, unlike git merge which preserves the parallel history.

    Read the full bite: Git Merge: Combining Development Histories

14. Question 14 of 30

    How does DVC enable versioning of large data files and models within a Git-managed project?

    • aIt replaces Git's versioning system for all files exceeding a certain size threshold.
    • bIt integrates with Git to automatically split large files into smaller, Git-compatible segments.
    • cIt compresses large files and stores them directly in the Git repository, making them manageable.
    • dIt creates small text files in Git that act as pointers to the actual large files stored externally.
    Show the answer

    Answer: d · It creates small text files in Git that act as pointers to the actual large files stored externally.

    DVC's core mechanism involves creating small pointer files (e.g., .dvc files) within the Git repository. These pointer files contain metadata that references the actual large data files or models, which are stored in external storage like cloud services or a local cache. This allows Git to manage lightweight pointers while DVC handles the large binaries. Option C is incorrect because DVC's purpose is to avoid storing large files directly in Git, which is inefficient for binaries.

    Read the full bite: DVC: Git for Data and ML Models

15. Question 15 of 30

    What is the primary reason to avoid rebasing a branch that other developers have already pulled?

    • aIt will make the project history less linear and harder to follow.
    • bIt prevents the final merge into the main branch from being a simple fast-forward.
    • cIt rewrites history, forcing teammates into complex manual repository fixes due to conflicting histories.
    • dIt will create numerous merge conflicts that are difficult to resolve.
    Show the answer

    Answer: c · It rewrites history, forcing teammates into complex manual repository fixes due to conflicting histories.

    The card explicitly states that rebasing a shared branch rewrites its history, causing conflicts with teammates' local histories and forcing them into complex manual fixes. This is the 'absolute rule' for when not to use it. Distractor B is incorrect because rebase aims to create a more linear history.

    Read the full bite: Git Rebase: Rewriting History for a Cleaner Timeline

16. Question 16 of 30

    Which property of annotated tags makes them the correct choice for production release markers?

    • aThey automatically advance to the latest commit when the branch is merged forward.
    • bThey are simple refs that do not consume extra storage in the Git database.
    • cThey point directly to a commit without needing an intermediate object.
    • dThey include tagger identity, timestamps, and optional GPG signatures for verification.
    Show the answer

    Answer: d · They include tagger identity, timestamps, and optional GPG signatures for verification.

    Annotated tags are full objects containing tagger identity, timestamps, and optional GPG signatures, providing the audit trail required for production releases. Option B incorrectly assigns the properties of lightweight tags to annotated tags; lightweight tags are merely simple refs that lack metadata and auditability.

    Read the full bite: Git Tags: Immutable Milestones for Release History

17. Question 17 of 30

    Which principle is fundamental to the GitHub Flow workflow, enabling its use for continuous delivery?

    • aThe 'main' branch is consistently maintained in a deployable and stable condition.
    • bReleases are managed through separate, long-lived 'release' branches.
    • cDevelopers must obtain approval from a release manager before creating any new branches.
    • dAll new features are developed on a dedicated 'develop' branch before being merged into 'main'.
    Show the answer

    Answer: a · The 'main' branch is consistently maintained in a deployable and stable condition.

    The core tenet of GitHub Flow is that the 'main' branch is always stable and deployable, allowing for continuous delivery. Option D describes a characteristic of other workflows like Git Flow, not GitHub Flow, which uses short-lived feature branches directly from 'main'.

    Read the full bite: GitHub Flow: A Simple, Branch-Based Workflow

18. Question 18 of 30

    For which project characteristic is GitFlow explicitly recommended?

    • aRapid prototyping efforts where unversioned features are frequently merged
    • bTeams prioritizing a single, always-deployable main branch for all development
    • cProjects requiring continuous deployment to production multiple times daily
    • dSoftware products that are distributed as distinct, versioned releases
    Show the answer

    Answer: d · Software products that are distributed as distinct, versioned releases

    GitFlow is designed for projects that produce distinct, versioned releases, such as libraries or desktop applications, to manage the lifecycle of specific versions. It is explicitly advised against for continuously delivered software due to its inherent overhead.

    Read the full bite: GitFlow: A Branching Model for Versioned Releases

19. Question 19 of 30

    When is git cherry-pick the most appropriate Git command to use?

    • aTo reorder and consolidate multiple commits on a local branch before pushing them.
    • bTo permanently remove a commit from a branch's history after it has been pushed.
    • cTo combine all new features from a completed feature branch into the main development line.
    • dTo apply a specific bug fix from a development branch to a stable release branch without including other changes.
    Show the answer

    Answer: d · To apply a specific bug fix from a development branch to a stable release branch without including other changes.

    The card states that cherry-pick is for "backporting a bug fix without merging an entire feature branch" and for applying "a single bug fix... without all the other new, unstable features." Option C describes a standard git merge operation, not cherry-pick.

    Read the full bite: Git Cherry-Pick: Copy a Commit to Another Branch

20. Question 20 of 30

    To ensure Git LFS manages large files that were already committed to a repository's history, what is the necessary action?

    • aManually remove the large files from the repository's history and then add them back after configuring LFS.
    • bUse git lfs migrate to convert the existing large files in the repository's history.
    • cUpdate the .gitattributes file to include the large file types and push the changes.
    • dRun git lfs track for the file types and then re-commit the files.
    Show the answer

    Answer: b · Use git lfs migrate to convert the existing large files in the repository's history.

    The card explicitly states that 'git lfs track does not apply retroactively' and that users 'must use git lfs migrate to convert large files already committed to the repository's history'. Other options either only affect new files or are not the specific LFS tool for this task.

    Read the full bite: Git LFS: Versioning Large Files Without Bloating Your Repo

21. Question 21 of 30

    A team wants to adopt Trunk-Based Development to increase release frequency. What is the most critical practice that allows them to safely merge and deploy incomplete features?

    • aRequiring comprehensive peer review on all pull requests before merging.
    • bEnforcing small, atomic commits that pass all automated tests.
    • cUsing feature toggles to decouple code deployment from feature release.
    • dMaintaining a separate, long-lived 'develop' branch for integration.
    Show the answer

    Answer: c · Using feature toggles to decouple code deployment from feature release.

    Feature toggles are the key safety net in Trunk-Based Development, allowing incomplete code to be merged and deployed but kept disabled for users. While small commits and testing (B) are essential, they don't solve the problem of an unfinished feature being live.

    Read the full bite: Trunk-Based Development vs. GitFlow for High-Frequency Releases

22. Question 22 of 30

    In Trunk-Based Development, what is the key practice that enables frequent, low-risk deployments to production while maintaining a continuously releasable main branch?

    • aEnforcing that all new features are developed on long-lived, isolated feature branches.
    • bRequiring all developers to commit directly to the main branch without using any feature branches.
    • cRelying solely on comprehensive end-to-end testing before any code is merged to main.
    • dUtilizing feature flags to deploy incomplete or risky code to production in a disabled state.
    Show the answer

    Answer: d · Utilizing feature flags to deploy incomplete or risky code to production in a disabled state.

    The card highlights feature flags as the 'enabling technology' that makes TBD safe by decoupling code deployment from feature release, allowing incomplete features to be merged and deployed but kept disabled. While robust testing is crucial, feature flags specifically address the ability to deploy unfinished or risky code safely and frequently.

    Read the full bite: Trunk-Based Development vs. GitFlow for High-Frequency Releases

23. Question 23 of 30

    On a git-based PaaS like Heroku, what is the role of the Procfile versus requirements.txt?

    • aThe Procfile stores secret config values for the running app
    • bBoth files list dependencies and one is just a backup of the other
    • crequirements.txt declares the start command; the Procfile lists Python packages
    • dThe Procfile declares the process start command; requirements.txt lists the dependencies to install
    Show the answer

    Answer: d · The Procfile declares the process start command; requirements.txt lists the dependencies to install

    requirements.txt tells the buildpack which packages to install, while the Procfile declares how to start each process, such as the web command. Secrets belong in config vars, not the Procfile.

    Read the full bite: Deploying to Heroku via Git

24. Question 24 of 30

    What is the primary reason to use specific filters (e.g., branches, paths) with Git-based CI triggers?

    • aTo reduce the number of workflow runs, focusing only on relevant changes or branches.
    • bTo define the exact order in which multiple CI jobs within a single workflow should execute.
    • cTo enable manual approval steps for critical deployments to production environments.
    • dTo ensure every code change, regardless of branch or file, always runs a full CI pipeline.
    Show the answer

    Answer: a · To reduce the number of workflow runs, focusing only on relevant changes or branches.

    Specific filters prevent the "footgun" of broad triggers, which lead to costly and redundant workflow runs. They ensure workflows execute only for relevant changes, unlike option D which describes the inefficient use of broad triggers.

    Read the full bite: Git-Based CI Triggers: Automating on Events

25. Question 25 of 30

    Which approach best keeps database credentials out of Git while supporting local development?

    • aEncode the credentials with base64 and store them in a committed config file
    • bCommit a template file and manually replace values before each deployment
    • cStore credentials in a committed file and delete it in a later commit if exposed
    • dUse a .env file listed in .gitignore and read via environment variables
    Show the answer

    Answer: d · Use a .env file listed in .gitignore and read via environment variables

    A gitignored .env file keeps secrets out of the repository while the app reads them at runtime via environment variables. Deleting a committed file later is insufficient because Git history is immutable and distributed, so the secret remains in every clone and fork.

    Read the full bite: Why avoid committing secrets to Git, and secure local alternatives?

26. Question 26 of 30

    Which two automated layers provide the strongest defense against committing API keys to Git?

    • aRequiring signed commits and enforcing branch protection with mandatory pull request approvals
    • bManual code review of every diff and a developer checklist before pushing code
    • cRemoving the leaked secret file and running simple string matching during the CI pipeline
    • dClient-side pre-commit scanning that blocks local commits and server-side or CI pipeline scanning that rejects pushes or fails builds
    Show the answer

    Answer: d · Client-side pre-commit scanning that blocks local commits and server-side or CI pipeline scanning that rejects pushes or fails builds

    Option D is correct because it layers client-side pre-commit hooks that catch secrets before they leave the developer machine with server-side or CI scanning that acts as a second automated gate. Option C is tempting because it mentions CI scanning, but deleting the file does not remove the secret from Git history and simple string matching produces high false positives while missing novel secret formats.

    Read the full bite: Committed an API key to Git. Describe two automated CI/CD prevention methods.

27. Question 27 of 30

    Which approach best reduces recurring merge conflicts on a single large shared storyboard?

    • aCommit the storyboard less often so conflicts batch up
    • bSplit it into small per-feature storyboards or xibs and assign screen ownership
    • cTrain everyone to hand-edit the conflicted storyboard XML carefully
    • dDisable Auto Layout to make the XML shorter
    Show the answer

    Answer: b · Split it into small per-feature storyboards or xibs and assign screen ownership

    Smaller, isolated files plus clear ownership shrink the chance two people edit the same file. Hand-editing storyboard XML is error-prone, and committing less often increases divergence.

    Read the full bite: Minimizing Storyboard merge conflicts

28. Question 28 of 30

    Why can committing generated files like local dependency folders cause CI cache misses even when the lockfile has not changed?

    • aThey remain in Git history, so the clone is larger and the cache key hash includes every historical version.
    • bThey dirty the working tree, changing the repository state that CI hashes to compute cache keys.
    • cThey overwrite the lockfile during checkout, so the runner cannot verify dependency versions.
    • dThe CI platform disables caching automatically when it detects build artifacts in the repository.
    Show the answer

    Answer: b · They dirty the working tree, changing the repository state that CI hashes to compute cache keys.

    CI systems often hash the working tree or lockfile to key caches; unignored generated files alter that state and cause misses. Distractor A confuses history bloat—which slows clones—with cache key computation, which is based on current files, not every historical version.

    Read the full bite: Explain .gitignore and its impact on faster, reliable, secure CI builds

29. Question 29 of 30

    Which task is generally considered unsuitable for a Git pre-commit hook?

    • aRunning a linter to identify style violations or potential bugs.
    • bVerifying that no sensitive API keys are accidentally staged for commit.
    • cExecuting a comprehensive suite of integration tests for the entire application.
    • dAutomatically reformatting code to a consistent style.
    Show the answer

    Answer: c · Executing a comprehensive suite of integration tests for the entire application.

    Pre-commit hooks are intended for fast, local checks to provide immediate feedback. Long-running tasks like a full integration test suite would significantly slow down the commit process, making it frustrating for developers. The other options are all examples of quick, automated checks suitable for a pre-commit hook.

    Read the full bite: Pre-commit Hooks: Your Code's Quality Gatekeeper

30. Question 30 of 30

    In which situation would Semantic Release be least appropriate for a software project?

    • aThe team struggles to consistently follow a strict commit message convention.
    • bThe project uses a monorepo structure with interdependent packages.
    • cThe CI/CD pipeline already automates testing and code deployment.
    • dThe project is a public library that needs frequent updates.
    Show the answer

    Answer: a · The team struggles to consistently follow a strict commit message convention.

    The card explicitly states, "Don't use it if your team cannot commit to a strict, formalized commit message convention, as the entire system relies on this discipline." Option D describes an ideal use case for Semantic Release, making it a tempting distractor.

    Read the full bite: Semantic Release: Automate Versioning with Commit Messages