Version control Study Guide

📖 Core Concepts Version control – System for tracking who, what, and when changes are made to files. Repository – Authoritative store of all revisions and metadata. Working copy – Local editable copy of files; changes are made here before committing. Commit – Atomic snapshot of the working copy plus a commit message; recorded in the repository. Change list / Change set – The group of file modifications that make up one commit. Revision (snapshot) – The complete state of the project at a given point; each revision gets a unique identifier. Branch – Independent line of development that diverges from a particular revision. HEAD – Pointer to the tip (latest commit) of the currently checked‑out branch. Merge – Combines two branches, creating a new commit that contains both sets of changes. Conflict – Overlapping edits that cannot be merged automatically; must be resolved manually. Tag / Label / Baseline – Fixed, read‑only marker of a specific revision (often a release). Atomic operation – Either completes fully or has no effect; commits must be atomic so the repo never sees a half‑finished state. --- 📌 Must Remember Centralized vs. Distributed – Centralized: single server holds the repo; Distributed: every clone holds the full repo. HEAD = tip of current branch – not necessarily the newest commit in the whole repo. Commit = atomic – all files in the change set become visible together. Pull = fetch + merge (or rebase) from another repo; Push = send your local commits to another repo. Merge creates a new commit; Rebase rewrites history to a linear chain. Small, single‑task commits = easier debugging and bisecting. File locking prevents concurrent writes; Merging allows concurrent edits (best for text). Tags are immutable snapshots; moving a tag after release is poor practice. --- 🔄 Key Processes Making a Commit Edit files in working copy → git add <files> (stage) → git commit -m "msg" → atomic snapshot recorded. Branching Workflow git branch <new‑name> (create) → git checkout <new‑name> (switch) → develop → commit as usual. Merging git checkout <target‑branch> → git merge <source‑branch> → automatic merge → if conflict, edit files, git add, then git commit. Rebasing git checkout <feature‑branch> → git rebase <base‑branch> → reapplies each commit onto new base; resolves conflicts per commit. Pull / Push Synchronization Pull: git pull = git fetch + (git merge or git rebase). Push: git push <remote> <branch> sends local commits to the remote repo. Squashing Commits Interactive rebase: git rebase -i HEADN → mark commits as squash → combine into one logical commit. Tagging a Release git tag -a v1.2.0 -m "Release 1.2" → creates immutable label on current HEAD. --- 🔍 Key Comparisons Centralized ↔ Distributed Centralized: single authoritative server; most ops need network access. Distributed: every clone is a full repo; local commits, history, and backups are always available. Merge ↔ Rebase Merge: preserves true history, creates a merge commit; safe for shared branches. Rebase: rewrites history to a linear series; good for cleaning up private feature work. Locking ↔ Merging (for concurrent edits) Locking: one writer at a time → avoids conflicts; suited for binary files. Merging: multiple writers → relies on automatic merge; works best for plain‑text. Pull ↔ Push Pull: bring others’ changes into your repo. Push: send your local changes to another repo. Tag ↔ Branch Tag: fixed point, never moves. Branch: moving pointer that continues to receive new commits. --- ⚠️ Common Misunderstandings “Pull automatically updates my code without merging.” Pull always incorporates fetched commits; by default it merges (or rebases if configured). “Tags can be edited like branches.” Tags are intended to be immutable; moving a tag after release breaks reproducibility. “Distributed VCS means there is no central server at all.” Teams often still use a canonical remote (e.g., GitHub) for coordination; the model just allows any clone to act as a source. “Rebase is safe on a branch that others are using.” Rewriting shared history forces collaborators to force‑push and can lose work. “A conflict means the merge has failed completely.” Conflicts are resolvable; after manual edits and a new commit, the merge succeeds. --- 🧠 Mental Models / Intuition Repo as a Tree – Each commit is a node; branches are separate limbs; merges are knots joining limbs. HEAD = Your Cursor – It points to the current node you’re “standing on”; moving HEAD = checking out another commit/branch. Commit = Photo – It captures the entire project state at a moment, not just the changed files. Pull = Receiving Mail – You fetch a package (patches) and then open it (merge/rebase). --- 🚩 Exceptions & Edge Cases Binary Files – Automatic merge often fails; use file locking or specialized merge tools. Atomic Commit Failure – Network loss during push can leave the remote repo unchanged; local repo still has the commit. Rebase on Public Branch – Can cause duplicated commits and diverging histories for collaborators. Tagging After a Force‑Push – The tag may point to a commit that no longer exists in the visible history. --- 📍 When to Use Which Centralized → Small team, strict access control, need for single source of truth. Distributed → Open‑source, remote work, need for offline work and fast local operations. Merge → Integrating feature branches that are already shared; preserving full history. Rebase → Cleaning up a private feature branch before it’s merged; keeping linear history. File Locking → Binary assets (images, compiled libraries) where merges are impractical. Squash Commits → Before merging a feature branch to keep the mainline history concise. Tag vs. Branch → Use a tag for immutable release points; use a branch for ongoing development. --- 👀 Patterns to Recognize Many small commits → easy bisect – If a bug appears, binary search (git bisect) works best when commits are granular. Frequent merge conflicts on the same file → likely a binary or configuration file → consider locking. Long-lived branches without rebasing → risk of large, complex merges → schedule periodic merges or rebase onto mainline. Commit messages lacking “why” → harder to trace rationale → look for accompanying issue tracker IDs. --- 🗂️ Exam Traps Distractor: “Push automatically merges remote changes.” Why it’s tempting: Both involve network communication. Why it’s wrong: Push only sends your commits; remote merges only if the remote does a fast‑forward or you trigger a merge there. Distractor: “A tag can be moved to a newer commit after a release.” Why it’s tempting: Tags look like branches in some UIs. Why it’s wrong: Tags are meant to be permanent snapshots; moving them breaks reproducibility. Distractor: “Rebase is just another form of merge.” Why it’s tempting: Both combine histories. Why it’s wrong: Rebase rewrites history, creating new commit IDs; merge preserves original commits and adds a merge commit. Distractor: “In a distributed system there is no need for backups.” Why it’s tempting: Every clone has full history. Why it’s wrong: Local disk failure still risks loss of unpushed work; regular backups of at least one clone are still best practice. Distractor: “HEAD always points to the newest commit in the whole repo.” Why it’s tempting: “Head” sounds like “top.” Why it’s wrong: HEAD points to the tip of the currently checked‑out branch, not the global newest commit.