Git interviews test whether you understand the underlying object model, not just which commands to type — why a rebase rewrites history and a merge doesn't, what actually happens during a merge conflict, why git pull is really two commands wearing a trenchcoat. This covers all 100 questions, organized by topic, with commands, a diagram, and a mock test at the end.

Git Fundamentals

Q1. What is Git and why is it used?

Git is a distributed version control system that tracks changes to files over time, letting multiple people work on the same codebase concurrently, branch off to work in isolation, and merge changes back together — used because it's the industry-standard way to manage source code history, enable collaboration, and recover from mistakes (nothing is truly lost as long as it's committed somewhere).

Q2. How does Git differ from other version control systems (VCS)?

Q3. What is the difference between Git and GitHub?

Git works completely independently of GitHub — you can use Git with no GitHub account at all (a local repo, or hosted on GitLab, Bitbucket, or your own server). GitHub is one of several popular hosting services built on top of Git, adding collaboration features Git itself doesn't provide.

Q4. What is a repository in Git?

A repository (repo) is the full set of files, folders, and their complete commit history, tracked by Git in a hidden .git directory at the project's root — that .git folder IS the repository; deleting it removes all Git tracking while leaving the working files themselves intact.

Q5. Explain the concept of a commit in Git.

git add file.txt
git commit -m "Add feature X"

A commit is a permanent, addressable snapshot of the entire tracked project at a point in time, along with metadata (author, timestamp, message, and a pointer to its parent commit(s)) — commits form a chain (or graph, once branching enters the picture) that constitutes the project's history.

Q6. What is the difference between a working directory, staging area, and repository in Git?

The working directory is where you actually edit files; git add moves selected changes into the staging area (a preview of exactly what the next commit will contain); git commit takes everything staged and permanently records it into the repository's history. This three-stage model is what lets you commit only part of your current changes, not everything you've touched.

Q7. Define branching in Git and its importance.

git branch feature-x
git checkout feature-x
# or in one step:
git checkout -b feature-x

A branch is an independent, movable pointer to a commit — creating one lets you develop a feature or fix in isolation without affecting the main line of history, and merge it back only once it's ready. This is what makes parallel, non-blocking collaborative development practical.

Q8. What is a HEAD in Git?

HEAD is a pointer to whatever commit you currently have checked out — normally it points to a branch (which itself points to a commit), so HEAD moves along automatically as you commit on that branch; checking out a specific commit directly (rather than a branch) puts you in a "detached HEAD" state.

Q9. What does the 'clone' operation in Git do?

git clone https://github.com/user/repo.git

git clone copies an entire remote repository — every commit, branch, and tag in its full history — down to a new local directory, and automatically sets up that remote as origin, ready to push/pull against.

Q10. How does Git store information?

Git stores content as a graph of four object types, all content-addressed by SHA-1 (or SHA-256 in newer repos) hash: blobs (raw file content), trees (directory listings, mapping names to blob/tree hashes), commits (a snapshot pointer plus metadata and a parent link), and tags (a named pointer to a specific commit). Crucially, Git doesn't store per-file diffs — every commit points to a full snapshot of the entire tree, with unchanged files simply reusing the same blob hash they already had.

Basic Git Commands

Q11. How do you initialize a new Git repository?

git init
# creates a .git folder in the current directory, tracking it from now on

Q12. Explain the purpose of the git status command.

git status
# Shows: staged changes, unstaged changes, and untracked files — the current state of the working tree

Q13. What does the git add command do?

git add file.txt        # stage one specific file
git add .                # stage everything changed in the current directory
git add -p               # interactively choose which HUNKS to stage, not just whole files

Q14. How do you create a commit in Git?

git commit -m "Fix login bug"
git commit -am "Fix login bug"   # stages all tracked-file changes AND commits in one step

Q15. What information is contained in a commit object in Git?

Q16. How does git push differ from git fetch?

Q17. Explain the purpose of the git pull command.

git pull
# equivalent to:
git fetch
git merge origin/main   # (or rebase, if pull.rebase is configured)

git pull is really git fetch immediately followed by a merge (or rebase) of the fetched remote branch into your current one — understanding it as those two separate steps is exactly what makes conflict resolution and pull.rebase configuration make sense.

Q18. Describe the use of git branch command.

git branch                  # list local branches
git branch feature-x        # create a new branch (doesn't switch to it)
git branch -d feature-x     # delete a branch (safe — refuses if unmerged)
git branch -D feature-x     # force-delete, even if unmerged

Q19. How do you switch branches using git checkout?

git checkout feature-x
# Modern equivalent (Git 2.23+), clearer intent:
git switch feature-x

Q20. What is the purpose of git merge?

git checkout main
git merge feature-x   # brings feature-x's commits into main

git merge integrates another branch's changes into the current branch — if the current branch hasn't diverged, it's a fast-forward (just moving the pointer); if both branches have new commits, Git creates a merge commit with two parents, preserving both branches' full history exactly as it happened.

Git Branching and Merging

Q21. Explain the Git workflow you use most frequently.

The feature branch workflow is the most common baseline: create a branch off main for each piece of work, commit incrementally, open a pull request for review, and merge once approved and CI passes — simple, scales well for teams of most sizes, and pairs naturally with any of the more structured workflows (Gitflow, trunk-based) covered later.

Q22. Can you describe the process of creating a new branch and merging it back into the main branch?

git checkout -b feature-x
# ... make commits ...
git checkout main
git pull                    # make sure main is up to date first
git merge feature-x
git push

Q23. What is a merge conflict in Git and how do you resolve it?

<<<<<<< HEAD
const greeting = "Hello";
=======
const greeting = "Hi there";
>>>>>>> feature-x

A conflict happens when the same lines were changed differently on both branches being merged, and Git can't automatically decide which version is correct — it marks the conflicting region in the file (as above), and you manually edit it to the intended result, then git add the resolved file and git commit to complete the merge.

Q24. What is a fast-forward merge in Git?

If the target branch (e.g. main) hasn't advanced at all since the feature branch split off from it, merging just moves main's pointer forward to the feature branch's latest commit — no new merge commit is created at all, since there's genuinely nothing to reconcile between two histories.

Q25. Define a three-way merge.

When both branches have diverged (each has commits the other doesn't), Git performs a three-way merge — comparing the two branch tips against their common ancestor commit to determine what changed on each side, then combining both sets of changes into a new merge commit with two parents.

Q26. How do you rebase a branch in Git?

git checkout feature-x
git rebase main
# replays feature-x's commits one by one on top of main's current tip

Rebase takes your branch's commits and re-applies them one by one on top of a new base (usually the latest main), producing a linear history as if you'd branched off the newer commit from the start — unlike merge, this rewrites commit hashes, which is exactly why you should never rebase commits that have already been pushed and might be in use elsewhere.

Q27. Explain the pros and cons of rebasing vs. merging.

Q28. What is the purpose of git tag?

git tag v1.0.0
git tag -a v1.0.0 -m "Release 1.0.0"   # annotated tag — stores author/date/message
git push origin v1.0.0

A tag is a fixed, named pointer to a specific commit — unlike a branch, it doesn't move as new commits are added, making it the right tool for marking release points (v1.0.0) that should always refer to exactly the same snapshot forever.

Q29. How do you revert a commit that has already been pushed to the remote repository?

git revert abc1234
git push
# creates a NEW commit that undoes abc1234's changes — original history stays intact

git revert is the safe way to undo a pushed commit — it creates a new commit reversing the changes rather than rewriting history (which git reset would do), so it's safe to push even if other people have already pulled the commit you're undoing.

Q30. What is the significance of the master branch in Git?

master (increasingly renamed main by convention across the industry) was historically Git's default branch name, typically representing the stable/production-ready line of development — there's nothing technically special about the name itself in Git; it's purely convention, which is exactly why renaming it to main has been a straightforward, widely-adopted change.

Git Workflows and Patterns

Q31. What is a distributed version control system and how does Git function as one?

In a distributed VCS, every clone is a complete, independent repository with the full commit history — not just a working copy of files pulled from a central server. This is what lets you commit, branch, and browse history entirely offline, and means there's no single point of failure: any clone can, in principle, become the new "source of truth" if needed.

Q32. Describe the Git feature branch workflow.

Covered above — one branch per feature/fix, off main, merged back via pull request once reviewed and tested. It's the most widely adopted baseline workflow because it's simple and scales reasonably well without extra process overhead.

Q33. Explain the Gitflow workflow.

Gitflow is a more structured, heavier workflow with dedicated long-lived branches for each purpose — well-suited to projects with scheduled, versioned releases, but often considered too much ceremony for teams practicing continuous deployment, where trunk-based development is a lighter-weight fit.

Q34. What is a Forking workflow in Git?

Each contributor works from their own personal server-side fork (a full copy) of the repository rather than a shared branch on the same repo, and contributes back via pull requests from their fork — the standard model for open-source projects, where maintainers don't want to grant every contributor direct write access to the canonical repository.

Q35. Discuss the Centralized workflow in Git.

Everyone works directly on a single shared branch (often just main) with no feature branches at all — simplest to reason about, but conflict-prone and hard to review incrementally at any team size beyond a handful of contributors; mostly seen on very small teams or projects with minimal parallel work.

Git Repository Management

Q36. Explain what a remote repository is in Git.

git remote -v
# origin  https://github.com/user/repo.git (fetch)
# origin  https://github.com/user/repo.git (push)

A remote is a named reference to another copy of the repository, typically hosted elsewhere (GitHub, a company server) — origin is just the conventional default name for the remote a repo was cloned from, not a special reserved keyword.

Q37. Describe how you would change a Git remote URL.

git remote set-url origin https://github.com/newowner/repo.git

Q38. How do you synchronize your local repository with a remote repository?

git fetch origin       # download remote changes without merging
git pull origin main   # download AND merge/rebase into your current branch
git push origin main   # upload your local commits

Q39. How do you clean up unused branches in your local and remote repository?

git branch -d old-feature              # delete local branch (safe)
git push origin --delete old-feature    # delete the remote branch
git fetch --prune                        # remove local references to remote branches that no longer exist

Q40. Describe the steps to resolve a merge conflict in Git.

• Run the merge/rebase — Git pauses and lists the conflicting files
• Open each conflicting file, find the <<<<<<< / ======= / >>>>>>> markers, and edit to the intended final content
• git add each resolved file
• git commit (for a merge) or git rebase --continue (for a rebase)

Git Stashing and Cleaning

Q41. What is git stash used for?

git stash                    # save uncommitted changes, revert working directory to clean
git stash pop                # reapply the most recent stash, and remove it from the stash list

Stash temporarily shelves uncommitted changes so you can switch to a clean working directory (to check out another branch, pull updates, or handle something urgent) without committing half-finished work — then restore those changes exactly where you left off.

Q42. How do you view stashed changes in Git?

git stash list
git stash show -p stash@{0}   # see the actual diff of a specific stash

Q43. Can you apply a stash without removing it from the stash list?

git stash apply   # reapplies the latest stash but KEEPS it in the stash list
// (pop removes it after applying; apply doesn't)

Q44. What does the git clean command do?

git clean -n     # dry run — shows what WOULD be deleted
git clean -f      # actually delete untracked files
git clean -fd     # also delete untracked directories

git clean removes untracked files (never committed, so not part of history) from the working directory — always run the dry-run -n flag first, since a real git clean -f is permanent and can't be undone with any Git command.

Q45. How do you remove a file from the working directory without deleting it from the repository?

git rm --cached secrets.env
# removes it from tracking/future commits, but leaves the actual file on disk

Git Logging and History

Q46. How do you view the commit history in Git?

git log
git log --oneline --graph --all   # a compact, visual view of every branch's history

Q47. Explain how to find a commit by a specific author in Git.

git log --author="Ada Lovelace"

Q48. How do you view the changes introduced in a commit?

git show abc1234

Q49. Can you list the files changed in a specific commit?

git show --stat abc1234
git diff-tree --no-commit-id --name-only -r abc1234

Q50. What does the git blame command do?

git blame file.js
# shows which commit (and author) last modified each line of the file

git blame annotates every line of a file with the commit that last changed it — useful for tracing when and why a specific piece of code was introduced, often the first step before deciding whether a change is a bug fix, a deliberate design choice, or something safe to revert.

Git Tagging and Releases

Q51. What are Git tags and how are they different from branches?

Q52. How do you create, delete, and push tags?

git tag v1.0.0                       # lightweight tag
git tag -a v1.0.0 -m "Release notes"  # annotated tag
git tag -d v1.0.0                     # delete a local tag
git push origin v1.0.0                # push one tag
git push origin --tags                # push all tags
git push origin :refs/tags/v1.0.0      # delete a tag on the remote

Q53. What is semantic versioning in the context of Git tagging?

Semantic versioning (MAJOR.MINOR.PATCH, e.g. v2.3.1) encodes meaning into the version number itself — MAJOR for breaking changes, MINOR for new backward-compatible features, PATCH for backward-compatible bug fixes — tags following this convention let consumers immediately understand the nature of a release without reading full changelogs.

Q54. How would you checkout to a specific tag?

git checkout v1.0.0
// puts you in a detached HEAD state, since tags aren't branches — you're not on a movable line of development

Q55. Describe how to create a release from a tag.

Push the tag, then (on a platform like GitHub) create a Release object pointing at it — attaching release notes, build artifacts, and marking it as a pre-release or the latest, giving consumers a discoverable, documented download point tied to that exact tagged commit.

Advanced Git Operations

Q56. What is a git submodule and when would you use one?

git submodule add https://github.com/org/shared-lib.git libs/shared
git submodule update --init --recursive

A submodule embeds another Git repository inside your own at a fixed commit — useful for including a shared library's actual source (not a package registry) as a dependency, pinned to a specific version rather than always tracking its latest commit. Submodules have a real usability cost (easy for a clone to forget --recursive, easy to forget to update the pinned commit) that's led many teams toward simpler alternatives (a real package manager, or a monorepo) where feasible.

Q57. Explain the purpose of a git hook.

# .git/hooks/pre-commit
#!/bin/sh
npm run lint || exit 1

A hook is a script Git runs automatically at specific points in its workflow (before a commit, before a push, after a merge) — useful for enforcing checks (linting, running tests, blocking a commit with a secret in it) locally, before code even leaves your machine. Hooks live in .git/hooks and aren't tracked/shared by default, which is why tools like Husky exist to make committing hook scripts alongside the repo itself practical.

Q58. How do you perform a squash commit in Git?

git rebase -i HEAD~3
# in the editor, change 'pick' to 'squash' (or 's') for the commits to combine

Squashing combines several commits into one — commonly done before merging a feature branch, so a messy sequence of "WIP," "fix typo," "actually fix it" commits collapses into one clean, meaningful commit in the target branch's history.

Q59. What is a git bisect and how do you use it?

git bisect start
git bisect bad                # the current commit is known broken
git bisect good v1.0.0        # this earlier commit is known good
# Git checks out a commit halfway between — you test it and mark good/bad, repeating
git bisect reset               # done — return to your original HEAD

Bisect performs a binary search through commit history to find exactly which commit introduced a bug — dramatically faster than manually checking out and testing commits one by one, especially across a long history where the regression could have landed anywhere.

Q60. How do you manually resolve a conflict during a git merge?

Covered above under Branching and Merging — open each file Git flags as conflicted, edit out the <<<<<<< / ======= / >>>>>>> markers to the correct final content, then git add and commit (or continue the rebase) to finish.

Git Configuration and Customization

Q61. How do you set your username and email in Git?

git config --global user.name "Ada Lovelace"
git config --global user.email "ada@example.com"

Q62. What is the scope of Git configuration files?

More specific scopes override less specific ones — a repo-local setting wins over a global one, which wins over a system-wide one.

Q63. How can you create aliases for Git commands?

git config --global alias.co checkout
git config --global alias.st status
git config --global alias.lg "log --oneline --graph --all"

git co main   # now works, equivalent to git checkout main

Q64. What is the purpose of a .gitignore file?

node_modules/
.env
*.log
dist/

.gitignore lists patterns for files/folders Git should never track — build output, dependencies, local secrets, editor-specific files — keeping the repository clean of generated artifacts and preventing accidental commits of things like environment files that shouldn't ever be in version control.

Q65. How would you ignore files globally?

git config --global core.excludesfile ~/.gitignore_global
# then add patterns to that file — applies to EVERY repo on your machine, e.g. .DS_Store, .idea/

Git Security

Q66. How do you ensure your commits are signed with your GPG key?

git config --global user.signingkey ABCD1234
git config --global commit.gpgsign true
git commit -S -m "Signed commit"

A signed commit is cryptographically signed with your GPG (or SSH) key, letting anyone verify it genuinely came from you and wasn't tampered with — GitHub/GitLab display a "Verified" badge on signed commits, which matters especially for open-source projects where anyone could otherwise set any name/email in their local git config.

Q67. What are some common security practices for Git repositories?

• Never commit secrets (API keys, passwords, private keys) — use .gitignore and a secrets manager instead
• Enable branch protection rules (required reviews, required passing CI) on protected branches like main
• Require signed commits for sensitive/high-trust repositories
• Regularly audit repository access and revoke it for departed team members promptly

Q68. How do you encrypt sensitive data in a Git repository?

# git-crypt or git-secret transparently encrypt specific files, decrypted only for authorized keys
git-crypt init
echo 'secrets.env filter=git-crypt diff=git-crypt' >> .gitattributes

Tools like git-crypt or git-secret encrypt specified files transparently — they're stored encrypted in the actual repository history, and automatically decrypted on checkout only for collaborators who hold the right key, which is genuinely different (and safer) than just remembering not to commit a plaintext secret.

Q69. What are some strategies for credential storage in Git?

git config --global credential.helper cache      # cache in memory temporarily
git config --global credential.helper store       # store on disk (plaintext!) 
git config --global credential.helper osxkeychain # use the OS's secure keychain

Q70. How would you revoke access to a Git repository?

On a hosting platform (GitHub/GitLab), remove the user's collaborator access directly through the repo/organization settings — that alone doesn't invalidate any clones they've already made or credentials/tokens they've already used, so for genuinely sensitive access, also rotate any relevant secrets/deploy keys and consider whether a leaked repo clone requires a broader incident response.

Troubleshooting and Recovery

Q71. How do you find and restore a deleted file in a Git repository?

git log --all --full-history -- path/to/deleted-file.js
git checkout <commit-before-deletion> -- path/to/deleted-file.js

Q72. What steps would you take if you accidentally committed sensitive data?

• Rotate/revoke the exposed credential immediately — this matters far more than cleaning history, since it may already have been cloned/cached/indexed elsewhere
• Remove it from history with git filter-repo (the modern, recommended tool) or the older BFG Repo-Cleaner
• Force-push the rewritten history and have every collaborator re-clone or carefully re-sync, since the commit hashes all change
• Treat it as a real security incident if the secret had any actual production access, not just a Git hygiene issue

Q73. How do you handle detached HEAD state in Git?

# You're on a detached HEAD (checked out a commit/tag directly, not a branch)
git checkout -b new-branch-name
# creates a real branch pointing at your current commit, so new commits aren't orphaned

Detached HEAD isn't dangerous by itself — you can look around freely — but any new commits made there have no branch pointing at them, so they're at real risk of being garbage-collected once you check out something else. If you want to keep work done in this state, create a branch from it before switching away.

Q74. Explain how to recover a dropped stash in Git.

git fsck --unreachable | grep commit
git stash apply <the-recovered-hash>

A dropped stash's commit object usually isn't immediately garbage-collected — git fsck --unreachable lists dangling commits, and the stash's contents are typically still findable among them (its message often literally says "WIP on <branch>"), recoverable via git stash apply on that hash.

Q75. How do you amend the message of the last commit?

git commit --amend -m "Corrected commit message"
// only do this on commits that HAVEN'T been pushed/shared yet — it rewrites the commit hash

Git Collaboration

Q76. What is a pull request and how does it work?

A pull request (PR) — a platform feature, not a native Git concept — proposes merging one branch into another, providing a place for code review comments, CI check results, and discussion before the merge actually happens. Git itself has no concept of a PR; it's entirely implemented by GitHub/GitLab/Bitbucket on top of plain Git branches.

Q77. How do you update a pull request?

git checkout feature-x
# make more commits addressing review feedback
git push
# the existing PR automatically updates to show the new commits

Q78. What is a code review process in Git?

Reviewers examine a pull request's diff, leave inline comments, and approve or request changes before it's allowed to merge — often gated by branch protection rules requiring at least one (or more) approvals and passing CI checks before the merge button is even enabled.

Q79. How do you handle a pull request conflict?

git checkout feature-x
git fetch origin
git merge origin/main   # or: git rebase origin/main
# resolve conflicts locally, then push again

Q80. What is the difference between git pull and git fetch followed by git merge?

They're functionally identical by default — git pull literally runs fetch then merge internally. The difference is purely about visibility and control: doing them as two explicit steps lets you inspect exactly what was fetched (git log origin/main) before deciding how to integrate it, rather than committing to an immediate merge.

Git Performance and Scalability

Q81. How do you handle large files in Git?

Plain Git handles large binary files poorly — every version of a large file bloats the repository's history permanently, since Git stores full snapshots. Git LFS (covered next) is the standard solution, storing large file content outside the main repository history and tracking only lightweight pointers inside Git itself.

Q82. What are some ways to improve the performance of a large Git repository?

• Git LFS for large binary assets
• Shallow or partial clones for CI/CD agents that don't need full history
• git gc to compact loose objects and prune unreachable ones
• Sparse-checkout, for a monorepo where a given consumer only needs a subset of the tree

Q83. What is a shallow clone in Git and when would you use it?

git clone --depth 1 https://github.com/user/repo.git

A shallow clone only fetches the most recent commit(s), not the full history — dramatically faster for CI/CD pipelines that just need the current code to build/test and have no need for the repository's entire history, at the cost of not being able to run most history-dependent Git operations (log, bisect) meaningfully.

Q84. How do you reduce the repository size in Git?

git gc --aggressive
git filter-repo --path large-file.zip --invert-paths   # permanently remove it from ALL history

git gc compacts and cleans up loose objects without changing history; actually shrinking a repo that has large files baked permanently into old commits requires rewriting history entirely (git filter-repo) — a disruptive, one-way operation everyone with a clone needs to coordinate around.

Q85. Explain how Git LFS (Large File Storage) is used.

git lfs install
git lfs track "*.psd"
git add .gitattributes
git add design.psd
git commit -m "Add design file"

Git LFS replaces large tracked files with small text pointers inside the actual Git history, while the real file content lives in separate LFS storage, fetched on demand — this keeps the core repository small and fast to clone even as large binary assets (design files, videos, datasets) are added over time.

Git in Continuous Integration/Continuous Deployment (CI/CD)

Q86. How does Git integrate with CI/CD pipelines?

A CI/CD platform (GitHub Actions, Jenkins, GitLab CI, Azure Pipelines) watches a Git repository for pushes/PRs and automatically triggers a pipeline in response — checking out the relevant commit, running build/test/deploy steps, and reporting the result back as a status check on the commit or PR.

Q87. Describe the process of automating deployments using Git.

# GitHub Actions example
on:
  push:
    branches: [main]
jobs:
  deploy:
    steps:
      - run: npm run build
      - run: npm run deploy

A push to a specific branch (main, or a release tag) triggers an automated pipeline that builds and deploys — the practical realization of continuous deployment, where merging to the right branch is itself the trigger for shipping to production, no separate manual deploy step.

Q88. How would you configure branch protection rules for a repository in the context of CI/CD?

• Require pull request review(s) before merging
• Require specific CI status checks to pass before the merge button is even enabled
• Require branches to be up to date with the base branch before merging
• Restrict who can push directly to the protected branch, forcing everything through a reviewed PR

Q89. What role do Git hooks play in automation?

Client-side hooks (pre-commit, pre-push) enforce checks locally before code even reaches the remote; server-side hooks on a self-hosted Git server can trigger deployments or notifications directly on push — though most modern teams handle the deployment-automation side through a CI/CD platform's own webhook-based triggers rather than raw server-side Git hooks.

Q90. How can Git help in the rollback process of a failed deployment?

git revert <bad-commit>
git push   # triggers the CI/CD pipeline again, deploying the reverted state

Since Git preserves every prior state as a full snapshot, rolling back means either reverting the offending commit(s) and letting the pipeline redeploy, or redeploying a known-good previous tag/commit directly — the entire deployment history being just Git history is what makes "deploy exactly what was running an hour ago" a solved, mechanical problem rather than a scramble.

Git with IDEs and Tools

Q91. How do you integrate Git with your preferred IDE?

Most modern IDEs (VS Code, JetBrains Rider/IntelliJ, Visual Studio) have Git support built in — visual diffs, staging/committing through the UI, branch switching, and inline blame annotations — layered directly over the same underlying git commands, not a separate implementation.

Q92. Discuss the pros and cons of using a GUI tool for Git versus the command line.

Q93. What plugins are commonly used with Git in development environments?

Q94. How do you resolve merge conflicts using a visual tool?

A visual merge tool (VS Code's built-in conflict editor, Beyond Compare, KDiff3) shows both conflicting versions side by side with clickable "accept current/incoming/both" actions — faster and less error-prone than manually editing raw conflict markers for anything beyond a trivial one-line conflict.

Q95. What is the purpose of a Git bridge for version control systems?

A Git bridge (like git-svn) lets Git interoperate with a repository actually hosted on a different VCS (SVN) — you work locally with normal Git commands, and the bridge translates your commits to/from the other system, useful during a gradual migration or when part of an organization still depends on the legacy system.

Advanced Git Topics

Q96. How do you handle large binary files in Git without using Git LFS?

Without LFS, the practical options are limited: keep binaries genuinely small and infrequently changed, store them in external storage (a CDN, blob storage) and reference them by URL instead of committing them directly, or accept the repository growth as a known trade-off — plain Git has no other built-in mechanism for handling large binaries efficiently.

Q97. What is the purpose of the git rebase -i command?

git rebase -i HEAD~4
# opens an editor listing the last 4 commits — pick/squash/reword/drop each one

Interactive rebase lets you rewrite recent history in detail before it's shared — squashing commits together, rewording messages, reordering, or dropping commits entirely. It's the Swiss-army-knife command for cleaning up a branch's history before opening a pull request.

Q98. How would you set up a continuous backup process for Git repositories?

Push to more than one remote (a secondary mirror, in addition to the primary host) via git push --all on multiple remotes, or use a scheduled job cloning/pulling into a backup location — for a hosted platform, most also offer their own automated backup/export features, but relying solely on the platform without an independent copy is a real single-point-of-failure risk.

Q99. Explain the impact of case sensitivity in Git and how to manage it across different operating systems.

Git itself is case-sensitive by default, but Windows and (by default) macOS filesystems are case-insensitive — this mismatch can cause real problems: renaming File.txt to file.txt might not register as a change on a case-insensitive filesystem, or two files differing only by case can coexist in the repo but collide when checked out on Windows/macOS. core.ignorecase can be configured to align Git's behavior with the underlying filesystem, but the safest fix is simply avoiding filenames that differ only by case in the first place.

Q100. How do you maintain multiple versions of a product using Git branches for each version?

git checkout -b release/v1.x
git checkout -b release/v2.x
# each maintained independently — bug fixes cherry-picked between them as needed
git cherry-pick abc1234   # apply one specific commit from another branch

Long-lived release branches (release/v1.x, release/v2.x) each track one supported version, with critical fixes cherry-picked between them where a bug affects more than one supported version simultaneously — the standard pattern for maintaining multiple production-supported major versions of a product at once.

Test yourself

A quick mock test covering the ground above — the rapid-fire round that often opens a Git interview before the deeper follow-ups.