Advanced Git Interview Questions and Answers

As a content-addressed database of four object types: blobs (file contents), trees (folders), commits (a tree, parents and metadata) and tags. Each object's ID is a hash of its content. Branches and HEAD are small references pointing to commits.

Snapshots. Each commit points to a complete tree, and unchanged files reuse the same blobs. Differences are calculated when you ask for them. Packfiles do use delta compression, but only as a storage optimisation.

A commit's ID depends on its content, including its parent's ID. A new ID for one commit changes its child, and so on along the chain. This makes history tamper-evident, and it is why rebasing creates new commits.

The binary file .git/index, which implements the staging area. It lists the paths and blob IDs for the next commit, plus file metadata so that Git can quickly detect changes.

git gc packs loose objects into packfiles using delta compression, and removes unreachable objects once they are old enough. Git runs it automatically from time to time.

A local log of every position of HEAD and of each branch. After a bad reset or rebase, find the earlier position with git reflog, and return with git reset --hard HEAD@{n}, or make a branch there. It is local only, and entries expire.

Find its last commit in git reflog, or in the output of git branch -D, then run git branch name <id>. If someone else has a copy, or it is still on the remote, you can fetch it from there.

A binary search through history for the commit that introduced a bug. You mark one good and one bad commit, and Git checks out commits in between until it finds the first bad one. git bisect run <command> automates it with a test.

git blame shows the last commit for each line. git log -S "text" finds commits that added or removed the text. git log -L 10,20:file follows the history of a range of lines.

Revoke or rotate the secret first, because it must be assumed to be compromised. Then, if needed, remove it from history with git filter-repo, force-push, and have everyone re-clone. Add prevention: secret scanning, push protection, .gitignore and hooks.

Git compares the two branch tips with their common ancestor (the merge base). If only one side changed a part, it takes that change. If both changed it differently, that is a conflict. ort is Git's default merge strategy.

They seem reversed. In a merge, "ours" is your current branch. During a rebase, Git is replaying your commits onto the other branch, so "ours" is that base, and "theirs" is your commit being applied.

git diff main..feature compares the two tips directly, the same as git diff main feature. git diff main...feature compares feature with its merge base with main, so it shows only what the branch changed. For git log, main..feature lists commits in feature that are not in main.

git revert -m 1 <merge-commit>, where -m 1 keeps the first parent's side. Note that merging the same branch again later will not bring those changes back unless you revert the revert first.

"Reuse recorded resolution". When enabled with rerere.enabled, Git remembers how you resolved a conflict, and applies the same fix if it appears again, which helps with long rebases.

Use shallow clones (--depth 1) in CI, partial clones (--filter=blob:none), sparse checkout to fetch only some folders, Git LFS for big binaries, and scheduled maintenance with git maintenance.

A monorepo makes shared code and atomic changes across projects easy, but needs tooling to keep builds and clones fast. Many repositories give clear ownership and separate releases, but make cross-project changes and shared versions harder. The right choice depends on team structure and tooling.

A submodule stores a pointer to a commit in another repository, so its code stays separate, but everyone needs extra commands to update it. A subtree copies the code into your repository, which is simpler for users but harder to contribute back.

Protect main with required reviews and status checks, run linting and tests in CI, use CODEOWNERS for required reviewers, and add local hooks for quick feedback. Hooks can be skipped, so CI must be the real gate.

Author details can be set to anything, so sign commits with GPG or SSH keys (git commit -S). GitHub marks verified commits, and branch rules can require them.