Skip to content
RED SAGSkills

Git interview questions and answers

Git questions check everyday teamwork skills: branching, merging, fixing mistakes and keeping history clean.

Below are 33 Git questions with the correct answer and a short explanation, grouped from fresher to experienced level. Try each one before you open the answer.

Take the Git MCQ testPractise 66+ Git questions for points

What Git interviews usually check

  • ✓Commits, branches and remotes
  • ✓Merge vs rebase
  • ✓Resolving merge conflicts
  • ✓Undoing changes: reset, revert and restore
  • ✓Pull requests and branching strategies

Git interview questions for freshers easy

1. .meta files in Git

A teammate's commit did not include Unity .meta files, and prefabs now show missing scripts. Why do .meta files matter?

  1. A.They hold compiled code for scripts
  2. B.They are temporary editor caches
  3. C.They store the player's save data
  4. D.They hold the GUIDs that asset references use
Show answer

Answer: D. They hold the GUIDs that asset references use

Unity references assets by GUID stored in each .meta file. Without them, new GUIDs are created and links break. Commit .meta files and use Visible Meta Files with Force Text serialisation.

2. Rebase vs merge

What is the main difference between git merge and git rebase when bringing main into a feature branch?

  1. A.Merge deletes the feature branch after joining it into main; rebase keeps the branch and all its history.
  2. B.Merge adds a merge commit and keeps history; rebase replays your commits on main, rewriting them.
  3. C.Rebase only works on remote branches, while merge only works on local branches.
  4. D.Merge rewrites the hashes of every commit; rebase never changes any existing commit.
Show answer

Answer: B. Merge adds a merge commit and keeps history; rebase replays your commits on main, rewriting them.

A merge joins two histories with a new merge commit and leaves existing commits untouched. A rebase creates new copies of your commits on top of the target branch, so their hashes change and history becomes a straight line. Because rebase rewrites history, you should not rebase commits that others have already pulled.

3. Are Kubernetes Secrets encrypted

A teammate says Kubernetes Secrets are safe to commit to Git because the values are encoded. What is wrong with this?

  1. A.Nothing is wrong; the API server and kubectl store Secret YAML encrypted with AES-256 by default.
  2. B.Secrets can only be stored safely inside Helm charts, never in plain YAML files.
  3. C.The data is only base64 encoded, which anyone can decode, so it must not be committed.
  4. D.Secret values are hashed with SHA-256, so nobody can read them back from the file.
Show answer

Answer: C. The data is only base64 encoded, which anyone can decode, so it must not be committed.

base64 is an encoding, not encryption; echo value | base64 -d reveals it. To protect Secrets you limit access with RBAC, enable encryption at rest for etcd, and keep the values out of Git with tools like Sealed Secrets, SOPS or the External Secrets Operator pulling from a secret manager.

4. Stopping direct pushes to main

Developers sometimes push straight to main, skipping review and CI. What is the standard way to stop this on GitHub or GitLab?

  1. A.Branch protection that requires a reviewed PR and passing checks
  2. B.A note in the README asking people not to push
  3. C.A nightly job that reverts direct commits
  4. D.Deleting main and working only on feature branches
Show answer

Answer: A. Branch protection that requires a reviewed PR and passing checks

Branch protection (or rulesets) can block direct pushes, require pull requests, set a number of approvals and require status checks to pass before merge. The rule is enforced by the server for everyone it covers. Notes and clean-up jobs do not prevent the push.

5. Finding which commit broke a test

A test passed at tag v1.8 and fails now, 200 commits later. Which Git tool finds the commit that broke it with the fewest checks?

  1. A.git blame
  2. B.git bisect
  3. C.git log --oneline
  4. D.git reflog
Show answer

Answer: B. git bisect

git bisect does a binary search between a good and a bad commit, so about 8 checks cover 200 commits (2^8 = 256). git bisect run can run the test at each step for you. git blame shows who last changed each line, not when a test began failing.

6. What squash merge does

A pull request has 14 small commits like "wip" and "fix typo". It is merged with Squash and merge. What lands on main?

  1. A.All 14 commits plus a merge commit
  2. B.The 14 commits, rebased on top of main
  3. C.Only the last of the 14 commits
  4. D.One new commit with all the PR changes
Show answer

Answer: D. One new commit with all the PR changes

Squash merge combines the PR changes into a single commit on main, which keeps history tidy and makes one-commit reverts easy. The individual commits stay visible in the PR. The trade-off is losing the detailed step-by-step history on main.

7. Why post the plan on a PR

Your team posts terraform plan output on every pull request. What is the main benefit?

  1. A.It removes the need for a remote backend
  2. B.Reviewers see the real infra changes before anything is applied
  3. C.The plan applies the change early to save time later
  4. D.It keeps the state file inside the pull request
Show answer

Answer: B. Reviewers see the real infra changes before anything is applied

Code diffs do not show side effects like a forced replacement or a deleted database, but the plan does. Reviewing the plan on the PR catches those before merge. Tools like Atlantis, HCP Terraform or a CI job automate this.

8. kubectl apply vs kubectl create

Your team keeps all manifests in Git and changes them often. Why do teams usually use `kubectl apply -f` instead of `kubectl create -f`?

  1. A.apply skips validation, so it is faster on large files
  2. B.create cannot read YAML, only JSON
  3. C.apply deletes and recreates every object for a clean state
  4. D.apply creates or updates objects to match the file each time
Show answer

Answer: D. apply creates or updates objects to match the file each time

kubectl create fails if the object already exists, so it suits one-time creation. kubectl apply is declarative: it creates missing objects and patches existing ones to match the file, which fits a Git-driven workflow. It does not delete and recreate objects.

9. Database password in a Git repo

A developer commits a production database password into a private Git repository. What is the right way to store it instead?

  1. A.In a secrets manager such as Key Vault or AWS Secrets Manager
  2. B.In a code comment, since the repository is private
  3. C.Base64-encoded in a config file in the repository
  4. D.In the README so the whole team can find it
Show answer

Answer: A. In a secrets manager such as Key Vault or AWS Secrets Manager

Secrets in Git spread to every clone, fork and backup, and stay in history even after deletion. A secrets manager keeps them encrypted, controls who can read them and logs access. Base64 is encoding, not encryption, and offers no protection.

10. What a .dvc file holds

After "dvc add data/train.csv", what is committed to Git?

  1. A.The full CSV file, compressed with gzip first
  2. B.A symbolic link into the user’s home folder
  3. C.Nothing at all, since DVC never touches Git
  4. D.A small .dvc file with the data’s hash and path
Show answer

Answer: D. A small .dvc file with the data’s hash and path

DVC stores large data in its cache and remote storage, and Git tracks a small metafile containing the content hash. Checking out an old commit and running dvc checkout or dvc pull restores the matching data version.

11. Where test code lives

What is the recommended way to manage automated test code?

  1. A.Keep it on one tester's laptop
  2. B.Keep it in version control, reviewed through pull requests, ideally close to the app code
  3. C.Email zip files to the team weekly
  4. D.Store it only in the CI server settings
Show answer

Answer: B. Keep it in version control, reviewed through pull requests, ideally close to the app code

Test code is real code. Keeping it in Git with code reviews gives history, collaboration and the ability to run tests that match each app version. Many teams keep tests in the same repository as the app.

Git intermediate interview questions medium

12. Should an app commit pubspec.lock

Your team builds a Flutter app (not a reusable package). Should pubspec.lock be committed to Git?

  1. A.Yes, so every developer and CI build uses the same resolved versions
  2. B.No, it is regenerated on every build and must be ignored
  3. C.No, because committing it blocks flutter pub upgrade
  4. D.Only on the release branch, never on main
Show answer

Answer: A. Yes, so every developer and CI build uses the same resolved versions

For applications, the lock file pins the exact versions that were tested, which makes builds reproducible across machines and CI. Packages published to pub.dev usually do not commit it, because their users resolve their own versions. You can still upgrade deliberately with flutter pub upgrade.

13. Where to fix a production bug first

You support release/5.2 in production while main has moved on to 5.3 work. A bug is found in 5.2. With a "fix on main, then pick" policy, what is the order?

  1. A.Fix on release/5.2 only, since main is not live
  2. B.Merge the fix to main, then cherry-pick it to release/5.2
  3. C.Fix on release/5.2, then merge release/5.2 into main
  4. D.Create release/5.2.1 from main and ship that
Show answer

Answer: B. Merge the fix to main, then cherry-pick it to release/5.2

Fixing main first makes sure the bug cannot come back in the next release, then the fix is picked back to the supported branch and released as 5.2.1. Fixing only the release branch risks the fix being forgotten. Shipping from main would release unfinished 5.3 work.

14. API key found in Git history

You find a live payment gateway API key in a commit from three months ago in a private repo. What should you do first?

  1. A.Rewrite Git history to remove the commit
  2. B.Revoke and rotate the key, then review its usage logs
  3. C.Make the repository private to everyone but admins
  4. D.Add the file to .gitignore going forward
Show answer

Answer: B. Revoke and rotate the key, then review its usage logs

Assume a secret in history is compromised: it may be in clones, forks, CI caches and backups. Rotating it removes the danger right away, and checking usage logs shows whether it was abused. Rewriting history is useful clean-up after that, not a fix on its own.

15. Who must review pipeline changes

Any developer can change .github/workflows/deploy.yml in a PR, and a teammate on the same squad can approve it. How do you make the platform team review those changes?

  1. A.Rename the workflows folder so it is harder to find
  2. B.Move the deploy workflow steps into the README file
  3. C.Add CODEOWNERS for the workflows folder and require their review
  4. D.Ask developers politely not to edit the workflow files
Show answer

Answer: C. Add CODEOWNERS for the workflows folder and require their review

CODEOWNERS maps paths to required reviewers, and branch protection can require their approval. Putting the platform or security team on .github/workflows/ means pipeline changes, which can expose secrets, need their sign-off. The same idea works for Dockerfiles and Terraform.

16. Installing a list of packages

You need git, curl and htop on every host. Which is the better way to write the task?

  1. A.One shell task running apt-get install three times
  2. B.One apt task with name: [git, curl, htop]
  3. C.Three plays, one per package
  4. D.A loop calling the command module with apt-get
Show answer

Answer: B. One apt task with name: [git, curl, htop]

Package modules like apt and dnf accept a list in name, which installs everything in one transaction and is faster than a loop. For other modules, loop: with {{ item }} repeats a task. Using shell or command with apt-get loses idempotency and clear change reporting.

17. DVC or Git LFS

Your team needs data versioning with S3 storage and reproducible multi-stage pipelines. Why might they pick DVC over Git LFS?

  1. A.Git LFS cannot store any file larger than 1 MB
  2. B.DVC adds pipeline stages and many storage remotes
  3. C.DVC stores the data itself inside the Git history
  4. D.Git LFS cannot be used with GitHub repositories
Show answer

Answer: B. DVC adds pipeline stages and many storage remotes

Git LFS replaces large files with pointers and stores them on an LFS server. DVC also versions data by pointers but adds pipelines, params, metrics and remotes such as S3, GCS or Azure, which suits ML workflows.

18. Commit hash with uncommitted edits

A run logs the git commit hash, but the engineer had uncommitted changes when training. What should the tracking setup also do?

  1. A.Nothing; the commit hash is always enough
  2. B.Record that the tree was dirty, or block such runs
  3. C.Delete the uncommitted changes after training
  4. D.Log the hash of the previous commit instead
Show answer

Answer: B. Record that the tree was dirty, or block such runs

A commit hash describes committed code only. If local edits exist, the run cannot be rebuilt from that hash. Logging a dirty flag and a diff, or requiring a clean tree for official runs, protects reproducibility.

19. Loading DAGs from a Git repo

In Airflow 3, a team wants DAG code read straight from a Git repository, with each run tied to the code version it used. Which feature supports this?

  1. A.A GitDagBundle configured as a DAG bundle
  2. B.Storing DAG files in Airflow Variables
  3. C.Copying files into the logs folder by cron
  4. D.An XCom that holds the DAG source
Show answer

Answer: A. A GitDagBundle configured as a DAG bundle

Airflow 3 introduced DAG bundles, sources of DAG code such as a local folder or a Git repo. Versioned bundles like Git let Airflow record which code version each DAG run used, which feeds DAG versioning in the UI.

20. Using a cloud device farm

What is a main reason to use a cloud device farm such as BrowserStack or Firebase Test Lab?

  1. A.It removes the need for any local testing
  2. B.Tests run with no network delay at all
  3. C.It can replace all exploratory testing
  4. D.Access many real devices without buying them
Show answer

Answer: D. Access many real devices without buying them

Device farms give remote access to hundreds of real devices and OS versions, run automated tests in parallel and record videos and logs. They cost money and add some latency, so teams usually keep a few local devices too.

21. Showing results in CI

Your team wants failed tests listed on the pull request page with history over time. What should the framework produce?

  1. A.A plain console log only
  2. B.A screenshot of the terminal
  3. C.A machine-readable report such as JUnit XML, consumed by the CI test report or a dashboard like Allure
  4. D.An email to the tester after each run
Show answer

Answer: C. A machine-readable report such as JUnit XML, consumed by the CI test report or a dashboard like Allure

JUnit XML is the common format that CI systems parse to show failures, durations and trends. Rich reporters like Allure or the Playwright HTML report add steps, attachments and history.

22. Clashing in code reviews

Two developers keep leaving sharp comments on each other's pull requests, and reviews now take days. What is the best first step?

  1. A.Talk with both to find the real issue and agree review norms
  2. B.Ban both from reviewing each other's code permanently
  3. C.Let the senior one decide every dispute by rank
  4. D.Ignore it, as conflict in reviews is always healthy
Show answer

Answer: A. Talk with both to find the real issue and agree review norms

Repeated friction usually has a cause, such as unclear coding standards, workload or a personal issue. Hearing both and agreeing shared norms, like a style guide and respectful wording, turns a personal clash into a solvable process problem.

Git interview questions for experienced candidates hard

23. Edit distance on two large files

You compare two 100,000-line files using the full O(m × n) edit distance table on lines. Why do tools like git diff not do this?

  1. A.It needs about 10^10 cells; diff tools use Myers’ O(N × D) method
  2. B.Edit distance cannot compare lines, only characters
  3. C.The result would always be zero for text files
  4. D.Git stores files as trees, so no diff is needed
Show answer

Answer: A. It needs about 10^10 cells; diff tools use Myers’ O(N × D) method

100,000 × 100,000 is 10^10 cells, too much time and memory. Myers’ algorithm costs O(N × D), where D is the number of differences, so it is fast when files are similar, which is the usual case. Git also offers patience and histogram diff for more readable results.

24. Holding a rebasing token in a pool

A vault records each user's deposit of a rebasing token as a fixed number. The token's supply later rebases down 10%. What happens?

  1. A.The vault's records adjust automatically
  2. B.The rebase skips any balances held by contracts
  3. C.The vault holds less than it records; late users lose
  4. D.Users each get 10% more than they deposited
Show answer

Answer: C. The vault holds less than it records; late users lose

Rebasing tokens change balances in every wallet, including contract balances, without transfers. Fixed per-user records drift from reality. Tracking shares of the vault's actual balance, or using a non-rebasing wrapper, keeps accounting correct.

25. Secrets in a GitOps repo

Your team uses Argo CD and wants everything in Git, including database credentials. Which approach keeps GitOps without storing plaintext secrets in Git?

  1. A.Commit ExternalSecret references synced from a secret manager, or encrypted values with Sealed Secrets or SOPS.
  2. B.Commit plain Kubernetes Secret YAML to a private repo, since only the team can read a private repo.
  3. C.Base64 encode every value twice before committing, so nobody browsing the repo can read them.
  4. D.Keep secrets only as Argo CD UI parameter overrides, which are never saved anywhere outside the UI.
Show answer

Answer: A. Commit ExternalSecret references synced from a secret manager, or encrypted values with Sealed Secrets or SOPS.

GitOps wants the desired state in Git, but secret values do not need to be there in plaintext. ExternalSecret manifests describe where to fetch a secret, and the operator creates the Kubernetes Secret in-cluster, which also eases rotation. Sealed Secrets and SOPS store encrypted data that only the cluster or holders of the key can decrypt. Private repos still leak via clones, forks and CI logs.

26. Main breaks with two green PRs

PR A renames a function and PR B adds a new call to the old name. Each passes CI on its own branch, both are merged, and main fails to build. What prevents this?

  1. A.Requiring two reviewers on every pull request
  2. B.Running the full test suite nightly on main
  3. C.A merge queue that tests each PR on top of the latest main
  4. D.Squash merging every PR into one commit
Show answer

Answer: C. A merge queue that tests each PR on top of the latest main

Each PR was tested against an older main, so their combination was never built. A merge queue (GitHub merge queue, GitLab merge trains) builds each PR together with the PRs ahead of it and merges only if that combined result passes. Nightly runs find the break hours later.

27. Recovering after a bad force push

You ran `git reset --hard HEAD~3` on your feature branch by mistake and then force-pushed. The 3 commits are gone from the remote branch. How can you get them back from your own machine?

  1. A.Run git revert HEAD~3 to restore the deleted commits
  2. B.Find the old commit in git reflog, reset to it, and push again
  3. C.Run git fetch, as the remote keeps every forced commit
  4. D.They are lost; Git deletes them at the force push
Show answer

Answer: B. Find the old commit in git reflog, reset to it, and push again

The reflog records where HEAD and branches pointed, so the old tip is still listed, for example as HEAD@{1}. git reset --hard to that commit, then force-push again (prefer --force-with-lease). Unreachable commits stay until garbage collection, usually weeks later.

28. Self-hosted runners on a public repo

An open-source project uses a self-hosted runner inside the company network for faster builds, and runs CI on pull requests from forks. What is the risk?

  1. A.Anyone can open a PR that runs code inside your network
  2. B.Forks cannot trigger workflows on self-hosted runners
  3. C.The runner leaks its CPU model in the logs
  4. D.Public repos cannot use self-hosted runners at all
Show answer

Answer: A. Anyone can open a PR that runs code inside your network

A pull request can change the workflow or test code, so an outsider gets to run anything on that machine, reach internal systems and leave malware behind for later jobs. GitHub advises against self-hosted runners for public repos. Use hosted or isolated ephemeral runners, and require approval for outside contributors.

29. Workflows approving pull requests

A repo requires one approval to merge to main. A workflow using GITHUB_TOKEN can create a PR with changes and then approve it. What setting stops automation from satisfying the review rule?

  1. A.Give GITHUB_TOKEN write-all permissions in the repo
  2. B.Require every PR title to start with the word "fix:"
  3. C.Run the workflow only on weekends when few people work
  4. D.Stop GitHub Actions from creating and approving PRs
Show answer

Answer: D. Stop GitHub Actions from creating and approving PRs

If a workflow can approve PRs, anyone who can change or trigger that workflow can get code onto main without a human review. GitHub has an org and repo setting to stop Actions from creating or approving PRs. Also limit token permissions and require review from code owners.

30. Releasing a shared internal module

Twenty stacks use your internal network module from a Git repo. You need to make a breaking change. What is the safest release practice?

  1. A.Copy the module into each of the twenty repos
  2. B.Push to main so every stack gets the change on its next plan
  3. C.Change the module and run apply on all twenty stacks at once
  4. D.Tag a new major version; stacks move via ?ref= when ready
Show answer

Answer: D. Tag a new major version; stacks move via ?ref= when ready

Pinning module sources to tags, such as git::https://...?ref=v3.0.0, lets consumers upgrade one at a time and read the plan for each. Semantic versions tell them when a change is breaking. Tracking main means one merge can change twenty plans at once.

31. Test environments nobody deletes

Engineers spin up test stacks for pull requests, and many are never removed. What is the most robust way to control this cost?

  1. A.Send every engineer a monthly reminder email
  2. B.Allow only one engineer to create test stacks
  3. C.Give test stacks the largest instances available
  4. D.Auto-delete stacks via expiry tags or pipeline teardown
Show answer

Answer: D. Auto-delete stacks via expiry tags or pipeline teardown

Automation beats reminders: create ephemeral environments from the pipeline, destroy them when the pull request closes, and run a scheduled cleaner that deletes anything past an expiry tag. Use budgets on sandbox accounts as a backstop.

32. Running only affected tests

To speed up pull requests, you run only tests mapped to changed files (test impact analysis). What safeguard is most important?

  1. A.None; the mapping is always correct
  2. B.Run impacted tests only on Fridays
  3. C.Delete tests that are rarely selected
  4. D.Still run the full suite on main or on a schedule, and always run everything when shared code, config or dependencies change
Show answer

Answer: D. Still run the full suite on main or on a schedule, and always run everything when shared code, config or dependencies change

Dependency maps miss indirect effects such as configuration, data and runtime behaviour. A full run as a safety net catches what selection missed, while pull requests still get fast feedback.

33. Running only the affected tests

A monorepo's full suite takes 90 minutes. The team wants pull requests to run only tests affected by the change. What is the main risk to manage?

  1. A.Running fewer tests always lowers code coverage numbers in reports
  2. B.Affected-test selection works only for UI tests, never for unit tests
  3. C.Developers will write fewer tests once the whole suite runs faster
  4. D.Missed links, such as config or data files, so full runs are still needed
Show answer

Answer: D. Missed links, such as config or data files, so full runs are still needed

Test impact analysis maps code to tests using dependency graphs or coverage data, but changes to config, data files, environment or dynamic code paths can be missed. Teams pair it with full runs on merge or nightly as a safety net.

Ready to test yourself?

Take a 15-question Git MCQ test with a score at the end, or practise the full Git question bank and earn points on the leaderboard.

Start the Git testTake a mock interview