Git MCQs - Collaboration and Troubleshooting (Set 4)

Q1. You run git rebase main on a feature branch and hit a conflict. In this situation, what does git checkout --ours file.js take?

a) The common ancestor's version

b) An empty file

c) The version from main (the branch being rebased onto), because during a rebase "ours" and "theirs" are swapped compared with a merge

d) Your feature branch's version of the file

Q2. On main, what is the difference between git merge -X ours feature and git merge -s ours feature?

a) They are identical

b) -s ours fails on conflicts while -X ours does not

c) -X ours deletes the feature branch

d) -X ours merges feature normally but resolves only conflicting hunks in favour of main; -s ours records a merge commit but ignores every change from feature

Q3. You keep resolving the same conflict each time you rebase a long-running branch. Which Git feature can reapply your earlier resolution automatically?

a) rerere ("reuse recorded resolution"), enabled with git config rerere.enabled true

b) git notes

c) git bisect

d) git gc

Q4. After git merge --squash feature and git commit on main, git branch -d feature reports that the branch is not fully merged. Why?

a) The squash merge failed silently

b) git branch -d never works after a merge

c) A squash merge creates one new commit with no link to feature's commits, so Git does not see feature's commits as ancestors of main

d) The feature branch was pushed

Q5. Why do teams turn on signed commits (git commit -S with a GPG or SSH key)?

a) Signing is needed to push to any remote

b) The author name and email in a commit can be set to anything, so a signature lets hosting platforms verify who actually made the commit

c) Signing compresses commits

d) Signed commits cannot be reverted

Q6. A repository on GitHub or GitLab has a protected main branch. What does this typically enforce?

a) Automatic squashing of every commit

b) Rules on the hosting platform, such as blocking force-pushes and deletion and requiring reviews and passing status checks before merging

c) A Git feature that encrypts the branch

d) A rule that stops anyone from cloning main

Q7. A CODEOWNERS file contains * @org/core on the first line and /docs/ @org/writers on the second. Who is requested for review on a change to docs/intro.md?

a) @org/core only, because the first rule wins

b) Both teams equally

c) Nobody, because the patterns conflict

d) @org/writers only, because the last matching pattern takes precedence

Q8. You ran git stash drop on a stash you still needed. Which approach can often recover it?

a) git stash pop again

b) git revert HEAD

c) git pull --rebase

d) Run git fsck --unreachable (or --lost-found), find the dangling commit that holds the stash, and apply it with git stash apply <hash>

Q9. A merge commit that brought a broken feature into the shared main branch has already been pushed. How do you undo it safely?

a) git revert -m 1 <merge-hash>, which reverses the changes the merge brought in relative to its first parent (main)

b) git reset --hard to before the merge and force-push

c) Delete the feature branch on the remote

d) git revert <merge-hash> with no options

Q10. A merged feature was reverted on main. After fixing the feature branch, you merge it again, but the original changes do not come back. Why, and what fixes it?

a) The merge needs --no-ff

b) The old commits are already in main's history, so Git does not reapply them; revert the revert commit and then merge the fixes

c) Git deletes reverted branches

d) The fixes must be cherry-picked one by one and the old ones are lost

Q11. You committed a 300 MB video, deleted it in the next commit, and the push to GitHub is still rejected for a large file. Why?

a) GitHub rejects all video files

b) The file is still in the working tree

c) The remote is out of disk space

d) The large file still exists in an earlier commit being pushed, so history must be rewritten to remove it

Q12. After running git lfs track "*.psd" and committing a design file, what is stored in the Git repository itself?

a) The full binary file, compressed

b) A link to the designer's local disk

c) Nothing; LFS files are ignored

d) A small pointer file containing the object's hash and size, while the real content is stored on the LFS server

Q13. With Conventional Commits and semantic-release style tooling, which commit causes a major version bump?

a) feat: add export button

b) feat!: remove v1 endpoints, or any commit with a BREAKING CHANGE: footer

c) fix: handle empty input

d) chore: update dependencies

Q14. An API key in config/secrets.env was pushed months ago. Which steps are correct?

a) Run git revert on the commit that added it

b) Rotate the key, run git filter-repo --path config/secrets.env --invert-paths to remove the file from all history, force-push, and have collaborators re-clone

c) Delete the file in a new commit; that removes it from history

d) Add the file to .gitignore

Q15. git push fails with "rejected (non-fast-forward)" because a teammate pushed to the same branch. What should you do?

a) Delete your local branch

b) Create a new repository

c) Fetch the new commits, integrate them with git pull --rebase (or a merge), resolve any conflicts and push again

d) Run git push --force