Version Control
Git is a distributed version control system: it stores a project's history as a chain of commit snapshots, each with a parent. A full copy of the repository lives locally, so nearly every operation — commit, branch, view history — works with no server. That's what makes Git the backbone of team development: isolated branches, parallel work, managed merging.
The topic runs from the basics to the operations that cause the most confusion. First, remote work: fetch only downloads, pull also integrates — mixing them up is dangerous. Second, integration: merge preserves the real graph, rebase rewrites history into a linear one, and the golden rule is not to rewrite what's already published. Third, surgical operations like cherry-pick to port a single fix. The breakdown is in the layers below.
Topic map
- Git basics — the snapshot commit, the parent, the branch, and the distributed nature of the local copy.
- Fetch vs pull — how downloading differs from downloading-plus-merging, and what a submodule is.
- Branching model — git-flow, trunk-based, and why a team needs a branch convention.
- Merge vs rebase — a non-linear graph versus a linear history and the golden rule of rebase.
- Rebase and interactive mode — replaying commits onto a new base, squash, reword, and cleaning up a branch.
- Cherry-pick — porting one commit between branches with a new hash, backporting a hotfix.
Common traps
| Mistake | Consequence |
|---|---|
| Treating Git as "cloud storage with the latest file" | Loses the whole model of history, branches, and snapshots |
Confusing fetch and pull | pull unexpectedly integrates and changes the working branch |
| Rebasing already-published shared commits | The rewritten history forces colleagues to recover |
Thinking rebase preserves the real graph | rebase rewrites commits with new hashes — the history is linear |
Assuming cherry-pick moves a commit with the same hash | A new commit with a new hash is created |
| No branch convention | Chaos: unclear where work starts and how fixes reach prod |
Interview relevance
Git is asked as a check of team discipline: do you understand what's safe to do on a shared branch. A candidate who states the golden rule — "don't rebase what's published" — and explains the difference between the merge graph and a linear rebase history shows they've worked on a team, not just committed solo.
Typical checks:
- What Git and a commit are; why the system is distributed.
- The difference between
fetchandpull; why to look first, integrate second. mergevsrebaseand when rebase is dangerous.- Surgical operations:
cherry-pickfor backports, interactive rebase for cleanup.
Common wrong answer: "rebase is always better than merge, cleaner history". On shared branches rebase rewrites published commits and breaks colleagues' work — a clean history isn't worth a broken graph for the whole team.