Git and Version Control Questions

Comprehensive knowledge of Git and general version control concepts, including distributed repository fundamentals, local versus remote repositories, the staging area, commit history, and common Git commands for cloning, committing, branching, merging, pushing, and pulling. Practical skills in branching and code flow strategies such as feature branching, trunk based development, Git Flow, and GitHub Flow, including when and why teams choose each strategy, their trade offs for release cadence and team size, and how they affect continuous integration and continuous delivery pipelines. Proficiency with merge strategies and conflict resolution, rebasing versus merging, pull request and code review workflows, integrating version control with automated pipelines and code quality checks, and troubleshooting common Git issues and merge conflicts.

EasyTechnical

90 practiced

Describe the difference between creating a new branch locally and creating/pushing a remote tracking branch. Provide the sequence of commands you would use to create a feature branch, set its upstream to origin, and open a pull request (mention the typical steps on GitHub/GitLab).

Sample Answer

**Difference (brief)**

- A local branch exists only in your repo/working copy. - A remote-tracking branch (and remote branch on origin) is stored on the remote; setting an upstream makes your local branch track origin/<branch>, enabling `git pull`/`git push` defaults and CI triggers in GitHub/GitLab.

**Commands to create, push, set upstream**

bash

# create and switch to feature branch locally
git checkout -b feature/my-change

# work, stage, commit
git add .
git commit -m "Add feature X"

# push to origin and set upstream (creates remote branch)
git push -u origin feature/my-change

**Typical PR/MR steps (GitHub/GitLab)**

- Go to repo on GitHub/GitLab → you’ll often see a banner to create a PR/MR for the pushed branch, or: - Click “Compare & pull request” (GitHub) / “Create merge request” (GitLab) - Fill title/description, link CI ticket if needed, select target branch (e.g., main) - Add reviewers, labels, pipeline/run checks - Create PR/MR; address review comments, update branch with `git pull --rebase` or `git push` - Merge when CI passes and approvals complete

**Notes for DevOps** Ensure CI pipeline triggers on push and protected-branch rules are respected (required checks, signed commits, required reviewers).

MediumTechnical

152 practiced

Explain how to use git blame and git annotate to investigate when a line of code was last changed and by whom. Then discuss limitations of blame (e.g., when history is rewritten via rebase/squash) and strategies to maintain traceability in projects that frequently squash or rebase before merge.

Sample Answer

**Brief usage**

- git blame shows who last changed each line and when; git annotate is an older alias.- Example commands:

bash

# blame file with commit, author, time and line numbers
git blame -L 120,140 --porcelain src/deploy.sh
# open blame in pager showing context
git blame -C -M src/deploy.sh

Explaination: blame attributes each line to a commit; -L limits lines; -C and -M follow copies/renames.

**Limitations**

- If history is rewritten (rebase, squash, force-push), commit SHAs change so blame points to the rewritten commits — you lose the original commit identity and timestamp.- Squash merges collapse many commits into one, making blame attribute many lines to the squashed commit instead of the original authors.- Blame can be confused by file moves or large refactors despite -M/-C heuristics.

**Strategies to preserve traceability in repos that squash/rebase**

- Maintain an ignore-revs file for systematic formatting/auto-fix commits and use git blame --ignore-revs-file=.git-blame-ignore-revs so noisy commits don’t obscure real authors.- Add original-author metadata into commit message when squashing (e.g., “Co-authored-by:” lines) so blame still surfaces contributors via git log.- CI records: have CI capture pre-merge commit SHAs and store mapping (PR -> list of original SHAs) in build metadata or artifact provenance.- Use GitHub/GitLab APIs: link PR numbers to commits; include PR/issue IDs in commit messages.- Prefer merge commits (or autosquash with preserved co-author lines) for important history when traceability matters.

These practices let a DevOps engineer correlate deployments and incidents back to original changes even when the team rebases or squashes frequently.

MediumTechnical

78 practiced

Explain how git bisect works and demonstrate, with commands, how to use it to find the commit that introduced a regression in a test suite. Include how you would automate bisecting in CI if the test can be run non-interactively.

Sample Answer

**Brief approach**Explain behavior-first: mark a known bad commit and a known good commit, let git bisect perform binary search by checking out commits between them. For CI automation use `git bisect run` with a non‑interactive test script that exits 0 on success and non‑zero on failure.

**Manual bisect commands**- Start and mark commits:

bash

# start bisect
git bisect start
# mark current (or specific) commit as bad (failing tests)
git bisect bad HEAD
# mark a commit known-good (tests pass)
git bisect good v1.2.0

- Git will checkout a midpoint; run tests, then mark:

bash

# if tests fail
git bisect bad
# if tests pass
git bisect good

- When finished:

bash

git bisect reset

**Automated (CI) non-interactive bisect**Create a small script that runs the test-suite and returns exit code 0 for pass, 1 for fail. Example:

bash

#!/usr/bin/env bash
# bisect-test.sh
set -e
# install deps, build, run tests non-interactively
./ci/install_deps.sh
./ci/run_tests.sh
# run_tests should exit 0 on success, non-zero on failure

Then use:

bash

git bisect start --term-old=good --term-new=bad
git bisect bad HEAD
git bisect good v1.2.0
git bisect run ./bisect-test.sh
# when done, git prints the first-bad commit; reset workspace
git bisect reset

**CI pipeline snippet (example: Jenkins / shell step)**

bash

git fetch --all
git checkout master
git bisect start
git bisect bad origin/master
git bisect good origin/release-1.2
git bisect run ./ci/bisect-test.sh
git bisect reset

**Notes & best practices**- Ensure tests are deterministic; retries or flaky-test handling will spoil bisect accuracy. If flaky, add stabilization or use `--term-old/--term-new` mapping.- Keep bisect-test lightweight (unit tests) to speed up binary search.- Use artifacts/logging to capture failing test output for the identified commit.

HardTechnical

74 practiced

You need to remove API keys and large binary files that were accidentally committed several commits ago. Describe a detailed migration and communication plan using git filter-repo or BFG to rewrite history, how to rotate keys, coordinate re-clone among contributors and CI, and how to keep the repo reachable during the cutover.

Sample Answer

**Situation & goals**I’d remove committed API keys and large binaries from history with minimal downtime, rotate secrets, and coordinate developer/CI re-clones so services stay reachable.

**Plan overview**1. Prep & communication - Announce timeline, impact, and required actions (re-clone, CI secret update) to team and stakeholders 72–48h before. - Create a private checklist and staging repo where we’ll test the rewrite.

2. Rewriting history (choose tooling) - Prefer git-filter-repo for speed/flexibility; BFG is OK for simple removals. - Example (git-filter-repo): remove a file or pattern and scrub blobs

bash

git clone --mirror git@example.com:org/repo.git
cd repo.git
git filter-repo --invert-paths --path sensitive.key --path-glob '*.pem' --strip-blobs-bigger-than 10M
git for-each-ref --format="%(refname)" refs/original | xargs -r -n1 git update-ref -d

- Or BFG for secrets:

bash

bfg --delete-files id_rsa --strip-blobs-bigger-than 10M repo.git
cd repo.git
git reflog expire --expire=now --all && git gc --prune=now --aggressive

3. Test & verification - Push to a temporary namespace (e.g., git@example.com:org/repo-rewritten.git) and run: - grep for secrets, git fsck, verify tags/branches. - Run CI on test mirror.

4. Rotate keys & credentials - Immediately rotate all exposed keys before pushing rewritten repo. Use cloud provider consoles / Vault to revoke and issue replacements. - Update CI/CD secrets and infrastructure (k8s secrets, Vault, CI variables) with new keys.

5. Cutover & minimize disruption - Set original repo to read-only and add a redirect README pointing to new repo and steps to re-clone. - Push rewritten repo to canonical URL once verified:

bash

# force-push mirror to origin (after read-only)
git push --force --mirror git@example.com:org/repo.git

- Keep a short window where both old and new repos exist: maintain DNS/remote guidance.

6. Coordinate re-clone & CI - Provide exact commands and automated script to re-clone and re-checkout:

bash

# recommended safe re-clone
git clone --recurse-submodules git@example.com:org/repo.git

- CI agents: update runners to use new credentials, purge workspace caches, and trigger fresh clones. Stagger updates: critical pipelines first, then others.

7. Rollback & auditing - Keep a private backup of the original mirror (offline, encrypted) for recovery/audit for a limited retention period. - After cutover, run audit scans (truffleHog, detect-secrets) and monitoring for abnormal usage of rotated keys.

**Why this works**- Rewrites remove secrets from history, rotating keys prevents leaked credentials from being valid, and coordinated communication + temporary read-only/redirect avoids surprises. Testing on mirrors and staged CI ensures reachability and minimal downtime.

HardTechnical

90 practiced

You suspect the remote Git repository has corrupt objects after CI jobs started failing with git errors. Explain the steps you would take to detect corruption, isolate the problem, restore service (e.g., using a mirror or backup), and prevent recurrence. Include commands like git fsck and git clone --mirror in your answer.

Sample Answer

**Detecting corruption (quick triage)**- Reproduce CI failure and capture git error messages (object name, pack file).- Try a fresh mirror clone to inspect every ref:

bash

git clone --mirror https://git.example.com/project.git /tmp/project.git
cd /tmp/project.git

- Run integrity checks:

bash

git fsck --full --no-reflogs --unreachable --name-not-found
# to place bad objects:
git fsck --full --lost-found

**Isolating the problem**- If fsck reports bad/missing objects or corrupt packs, note object IDs and refs affected.- Make remote read-only (disable pushes) to stop further damage: - Toggle repo permissions in hosting app or change filesystem perms on the git user.- Inspect pack files and refs in the mirror. If only certain refs broken, identify last good commit hashes.

**Restore service**- If you have a healthy mirror or backup, promote it:

bash

# from healthy host
git clone --mirror /backup/path/project.git
# push mirror to primary or new origin (careful with access)
cd project.git
git push --mirror https://git.example.com/project.git

- If no backup but local developer clones are healthy, rebuild from a good clone:

bash

git clone --mirror git@devmachine:project.git /tmp/rebuild.git
cd /tmp/rebuild.git
git fsck --full
git push --mirror https://git.example.com/project.git

- If corruption is minor, attempt repair:

bash

git reflog expire --all --expire=now
git gc --prune=now
git repack -a -d
git fsck --full

Only use these if you understand consequences; prefer restoring from a verified healthy source.

**Prevent recurrence**- Implement regular backups and off-site mirrors (automated cron or CI job):

bash

git clone --mirror https://git.example.com/project.git /backup/mirrors/project.git

- Automate periodic integrity checks:

bash

# run nightly
git fsck --full

- Enforce hosting integrity options and monitoring: - Enable repository checksum/pack validation if supported. - Alert on git errors in CI logs.- Harden access: restrict direct filesystem access, use SSH key policies, and audit hooks that run on push.- Document recovery runbook with commands above and test restores periodically.

Reasoning: mirror clones validate all refs/objects; fsck detects corruption; promoting a verified mirror or backup restores service safely; making repo read-only prevents more damage; automation and monitoring prevent future incidents.

Unlock Full Question Bank

Get access to hundreds of Git and Version Control interview questions and detailed answers.

Join thousands of developers preparing for their dream job.