Version Control and Collaborative Workflows
What to know
Candidates should be fluent in Git's object model at a conceptual level: commits are immutable snapshots linked to parents, branches are movable pointers, and HEAD tracks the current reference. Understand merge vs. rebase (merge preserves history and creates a merge commit; rebase rewrites commits onto a new base, producing linear history but new hashes). Know fast-forward, three-way merge, cherry-pick, revert (safe, creates an inverse commit) versus reset (moves the branch pointer; --hard discards working changes). Know tags (annotated vs. lightweight), remotes, fetch vs. pull, and force-with-lease as the safe force push.
Workflow traps
Questions blur trunk-based development (short-lived branches, frequent integration, feature flags) with GitFlow (long-lived develop/release branches). Trunk-based is favored for continuous delivery because it reduces merge risk. Another trap: rebasing shared branches rewrites public history and breaks collaborators-rebase only unshared commits. Also distinguish revert from reset in a shared branch scenario: revert is correct because it does not rewrite history. git pull is fetch plus merge (or rebase if configured); it is not a plain download.
Rule of thumb
Rewrite private history, preserve public history. Use small, atomic commits with messages explaining why, and require review via pull/merge requests with protected branches and required status checks.
Worked example
A commit with a leaked credential is already pushed to main. The correct sequence is: rotate the secret immediately, then git revert the commit (history stays intact), and optionally purge history with a history-rewriting tool only after coordinating with all collaborators. Deleting the branch or force-pushing over it without coordination is the classic wrong answer.