This second Git set moves to the commands you use every day in a team, and that interviewers love to ask about: rebasing, working with remotes, safely rewriting and undoing history, and picking a branching workflow. Each explanation tells you what the command does to history that others share with you.
How to practise: read each question and tap the option you think is correct. You will see right away whether you got it, along with a short explanation, and your score is tracked at the bottom of the screen. This set has 15 questions.
Topics covered in this set
- Rebase vs merge and the golden rule
- Interactive rebase: squash, fixup, reword, drop
- fetch vs pull and upstream branches
- push --force-with-lease, cherry-pick and stash
- revert vs reset and recovery with reflog
- Tags, Git Flow vs trunk-based and pull requests
Git MCQs with answers and explanations
Q1. How does git rebase main (run on a feature branch) differ from git merge main?
a) They produce identical history
b) Rebase replays the feature commits on top of the latest main, creating new commits with new hashes and a linear history; merge keeps the original commits and adds a merge commit
c) Rebase deletes the main branch
d) Merge rewrites the commit hashes on main
Q2. What is the "golden rule" of rebasing?
a) Always rebase main onto feature branches
b) Rebase only on Fridays
c) Never use rebase with merge
d) Do not rebase commits that you have already pushed and others may have based work on
Q3. You want to combine your last four local commits into one before opening a pull request. Which command starts that?
a) git rebase -i HEAD~4, then mark commits as squash or fixup
b) git cherry-pick HEAD~4
c) git merge --squash HEAD~4
d) git reset --hard HEAD~4
Q4. In an interactive rebase, what is the difference between squash and fixup?
a) fixup deletes the commit's changes
b) squash only works on merge commits
c) Both combine the commit into the one before it, but squash lets you edit a combined message while fixup discards the fixup commit's message
d) There is no difference
Q5. What is the difference between git fetch and git pull?
a) pull only works on tags
b) They are aliases
c) fetch uploads commits; pull downloads them
d) fetch downloads new commits and updates remote-tracking branches such as origin/main without touching your current branch; pull runs a fetch and then merges (or rebases) into your branch
Q6. What does git pull --rebase do on a local branch with unpushed commits?
a) Deletes the unpushed commits
b) Pushes your commits first
c) Rebases the remote branch onto yours
d) Fetches, then replays your unpushed commits on top of the updated remote branch instead of creating a merge commit
Q7. Why is git push --force-with-lease preferred over git push --force after a rebase?
a) It refuses to overwrite the remote branch if it has commits you have not fetched, so you do not wipe out a teammate's work
b) It is faster
c) It pushes tags too
d) It merges automatically
Q8. What does git cherry-pick a1b2c3d do?
a) Moves the commit a1b2c3d to another branch and deletes the original
b) Shows the diff of a1b2c3d only
c) Applies the changes from commit a1b2c3d onto the current branch as a new commit with a different hash
d) Reverts a1b2c3d
Q9. You run git stash with modified tracked files and one new untracked file. What happens to the untracked file?
a) It is committed
b) It is stashed too
c) It stays in the working tree, because plain git stash only saves tracked changes; use git stash -u to include untracked files
d) It is deleted
Q10. What is the difference between git stash pop and git stash apply?
a) apply deletes the stash without applying
b) pop applies the latest stash and removes it from the stash list if it applies cleanly; apply keeps the stash entry
c) pop only works on new branches
d) There is no difference
Q11. A bad commit is already on the shared main branch. What is the safe way to undo it?
a) git stash
b) git reset --hard HEAD~1 and force-push
c) Delete the .git folder
d) git revert <hash>, which adds a new commit that reverses the changes without rewriting history
Q12. You ran git reset --hard HEAD~3 by mistake and lost three local commits. How can you get them back?
a) Run git fetch
b) Run git reflog to find the commit HEAD pointed to before the reset, then git reset --hard to that hash (or create a branch at it)
c) Run git stash pop
d) They are gone forever
Q13. Which statement about Git tags is correct?
a) git push sends all tags automatically
b) Lightweight tags store a message
c) An annotated tag (git tag -a v1.0 -m "...") is a full object with tagger, date and message; tags must be pushed explicitly, for example with git push origin v1.0 or --follow-tags
d) Tags move forward with each new commit
Q14. How does trunk-based development differ from Git Flow?
a) Git Flow forbids branches
b) Trunk-based uses long-lived develop and release branches
c) In trunk-based development, developers merge small, short-lived branches into main frequently, often using feature flags; Git Flow uses long-lived develop, release and hotfix branches
d) They are the same workflow
Q15. Which statement about pull requests is correct?
a) A pull request is the same as git pull
b) Pull requests only work with tags
c) A pull request is a built-in Git command that merges branches
d) A pull request is a feature of hosting platforms such as GitHub, GitLab or Bitbucket for reviewing and discussing a branch before it is merged
Quick revision notes
- Rebase rewrites commits for a linear history; never rebase commits others already use.
- rebase -i: pick, reword, edit, squash (keep message), fixup (drop message), drop.
- fetch updates origin/* only; pull = fetch + merge (or --rebase); use --force-with-lease, not --force.
- cherry-pick copies a commit with a new hash; stash -u includes untracked; pop removes the entry, apply keeps it.
- Use revert on shared history and reset only on local work. reflog brings back lost commits. Tags must be pushed on purpose.
Frequently asked questions
Should my team use merge or rebase?
Many teams rebase their own feature branches to stay up to date, then merge into main through a pull request. The one rule to remember: do not rebase commits that others already depend on.
Is git pull dangerous?
No, but it can surprise you with merge commits or conflicts. Run git fetch first, or set pull.rebase or pull.ff only, and you will always know what it will do.
Can I recover a deleted branch?
Usually yes. Find its last commit hash in git reflog, then run git branch with the branch name and that hash. This works as long as the commits have not been garbage collected.
Comments
Post a Comment