The Core Idea
A Complete, Navigable History of Every Change
Git is a distributed version control system that tracks every change made to a codebase over time, letting you view, compare, and revert to any previous state, while also enabling multiple people to work on separate, independent copies of the code simultaneously without constantly overwriting each other's work. 'Distributed' specifically means every person working on the project has a COMPLETE copy of the entire project history on their own machine, not just a thin, incomplete slice pulled from one central server.
Without version control, collaborating on shared code typically means either working on one file at a time to avoid conflicts (extremely limiting) or risking one person's changes silently overwriting another's — Git solves this by giving each person their own independent working copy, with defined, structured processes (branching and merging) for bringing everyone's changes back together safely.
💡 Memory Trick
Think of Git as a video game's save-file system, but for an entire team playing simultaneously. A COMMIT is saving your current progress at a specific checkpoint, with a note describing what you just did. A BRANCH is forking off an entirely separate save file to try something experimental, without touching your main save at all. MERGING is combining your experimental branch's progress back into the main save file once you're confident it's ready, carefully reconciling anything that changed in both places in the meantime.
The Core Operations
Commits, Branches, and Merging
1
Commit
A snapshot of the project's current state at a specific point in time, saved permanently into the project's history along with a descriptive message explaining what changed and why. Commits form a chronological chain, letting you view the exact history of how the codebase evolved, and revert to any earlier commit if needed.
2
Branch
An independent line of development, forked off from a specific point in the project's history, allowing changes to be made in isolation without affecting the main codebase (often called 'main' or 'master') until those changes are specifically merged back in. Branches let multiple people (or one person working on multiple features) develop entirely independently without interfering with each other's in-progress work.
3
Merge
Combining changes from one branch into another, integrating both sets of changes into a single, unified result. If both branches modified the SAME part of the same file differently, Git flags this as a 'merge conflict,' requiring a person to manually decide how to reconcile the two competing versions of that specific section, since Git cannot safely guess which change should take precedence.
Why Distributed Version Control Matters
Every Copy Is a Complete, Independent Backup
Because every collaborator has a full copy of the entire project history on their own machine (not just a thin slice from a central server), work can continue completely offline, and losing any single machine (including the main shared server) doesn't lose the project's history, since every other collaborator's local copy already contains the complete history independently. This 'distributed' property is what specifically distinguishes Git from older 'centralized' version control systems, where a single central server held the only authoritative copy of the project's full history.
This structure is also exactly why feature branches have become standard practice: a developer can freely experiment, make mistakes, and iterate on a new feature entirely within their own isolated branch, without any risk of destabilizing the shared main codebase other collaborators are actively relying on — only once that feature branch's work is genuinely ready does it get merged back into the shared main line, at which point everyone else's copy can safely incorporate it.
🖥️ Applied Scenario
Two developers are simultaneously working on separate features for the same application, and both need to modify a shared configuration file, but in different, unrelated sections of that file.
1
Each developer creates their own separate branch off the main codebase, working independently on their respective features without either one's in-progress changes affecting the other or the shared main branch.
2
Developer A finishes first and merges their branch back into main — since their changes to the shared configuration file were in a completely separate section from anything Developer B is working on, this merge completes automatically with no conflict.
3
When Developer B later tries to merge their own branch into the now-updated main branch, Git detects that both Developer B's branch and the current main branch have each independently modified the shared configuration file (in different sections), and needs to combine both sets of changes.
4
Conclusion: because the two developers modified genuinely different, non-overlapping sections of the same file, Git can automatically merge both sets of changes together without any conflict requiring manual resolution — a conflict would only arise if they had both modified the exact same lines differently.
📌 Exam Application
Exam questions frequently ask you to explain the difference between a commit, a branch, and a merge, and to describe what happens when Git successfully auto-merges non-conflicting changes versus when a manual merge conflict resolution is required. You may also be asked to explain what makes Git specifically a 'distributed' version control system, as opposed to a centralized one.
⚠️ Most Common Version Control with Git Mistakes
The most common mistake is assuming Git ALWAYS requires manual conflict resolution whenever two people modify the same file — Git can automatically merge changes without any conflict as long as the actual modified LINES don't overlap; a conflict specifically arises only when both branches change the exact same lines of the same file in genuinely different, incompatible ways. Another frequent error is confusing 'distributed' with simply 'having multiple branches' — the distributed property specifically refers to every collaborator having a complete, independent copy of the ENTIRE project history on their own machine, which is a genuinely different property from branching (which exists even within a single person's local copy of the repository).
✓ Quick Self-Test
Can you explain, in your own words, the difference between a commit, a branch, and a merge? Can you explain exactly when a merge conflict occurs versus when Git can automatically combine two sets of changes without any conflict?
Next Lesson
Software Testing
→
← All Programming Concepts Lessons