AndroidHire

Android Git Interview Questions

Branches, rebasing, and collaboration.

50 questions in this topic · 8 sample questions below

Practice Git in the quiz engine

Sample questions

  1. You run git reset --hard HEAD~1. Which of the three trees does this command touch?

    • Only the branch pointer (HEAD), leaving index and working tree unchanged
    • HEAD, the index, and the working tree — correct
    • HEAD and the index, but not the working tree
    • Only the working tree, leaving HEAD and the index unchanged

    Why: --hard resets all three: it moves HEAD, overwrites the index, and overwrites the working tree to match the target commit. The idea that --hard only moves the branch pointer is a common misconception; that describes --soft.

  2. What is the key difference between git reset --soft HEAD~1 and git reset --mixed HEAD~1?

    • --soft discards the changes entirely; --mixed keeps them staged
    • --soft only affects the working tree; --mixed only affects the index
    • --soft leaves the changes staged in the index; --mixed unstages them but keeps them in the working tree — correct
    • They are identical except --mixed also modifies the working tree

    Why: --soft moves HEAD only, so the undone commit's changes remain staged. --mixed (the default) also resets the index, leaving the changes present but unstaged in the working tree. Neither touches the working tree files, which is why --soft does not discard anything.

  3. How does git revert differ from git reset for undoing a commit that has already been pushed?

    • revert rewrites history to remove the commit, so a force push is required
    • revert creates a new commit that inverts the changes, preserving history — correct
    • revert and reset both move the branch pointer backward without new commits
    • revert only works on merge commits, while reset works on any commit

    Why: revert introduces a new commit whose diff is the inverse of the target, leaving all prior history intact and requiring no force push. reset moves the branch pointer and would rewrite shared history, which is why revert is preferred for pushed commits.

  4. What does git rebase --onto main feature~3 feature do?

    • Moves all commits of feature onto main, discarding the last 3
    • Rebases the last 3 commits of main onto feature
    • Replays the commits from feature~3 (exclusive) up to feature onto the tip of main — correct
    • Squashes feature into 3 commits and rebases them onto main

    Why: The form is git rebase --onto newbase upstream branch: commits reachable from feature but not from feature~3 are replayed onto main. It transplants only that range, unlike a plain rebase which would use the merge base as the excluded upstream.

  5. Which statement about a fast-forward merge is correct?

    • It always creates a new merge commit with two parents
    • It rebases the feature branch onto the target before merging
    • It can only happen when merging a tag
    • It simply moves the branch pointer forward when there is no divergent history — correct

    Why: A fast-forward merge occurs when the target branch has no commits the source lacks, so Git just advances the pointer with no new commit. Creating a two-parent merge commit is what --no-ff forces instead.

  6. Why might a team prefer git merge --no-ff even when a fast-forward is possible?

    • It makes the merge faster by skipping the three-way comparison
    • It preserves an explicit merge commit that records the feature branch's existence — correct
    • It automatically resolves all conflicts using the target branch's version
    • It prevents the feature branch from being deleted afterward

    Why: --no-ff forces a merge commit so the branch's grouping of commits stays visible in history, which aids review and reverting a whole feature. It does not speed anything up or auto-resolve conflicts.

  7. What does the reflog primarily let you recover?

    • Files that were never added to the index
    • Changes discarded by git checkout on a tracked file
    • Remote branches that were deleted on the server
    • Commits that became unreachable after operations like reset, rebase, or branch deletion — correct

    Why: The reflog records where HEAD and branch tips pointed over time, so you can find and restore commits orphaned by reset or rebase before gc prunes them. It does not track working-tree files that were never committed, so an un-added file overwritten by checkout is not recoverable via reflog.

  8. You are in a detached HEAD state and make several commits. What is the danger?

    • The commits are written directly to the remote and cannot be undone
    • Git refuses to let you commit at all in detached HEAD
    • The commits automatically overwrite the previously checked-out branch
    • The commits are not on any branch, so they can be lost once HEAD moves away — correct

    Why: In detached HEAD, new commits are not referenced by any branch; when you check out another branch, they become unreachable and eventually get garbage-collected. Git does allow committing in this state, so the risk is losing the work, not being blocked from it.

Practice all 50 Git questions

These 8 are a sample. The full Git bank is scored, tracks your progress, and explains every answer.

Open the quiz

More Android interview topics