Foundations of Git

Understanding Git: Version Control for Collaborative Development What is Git? Git is a distributed version control system designed to manage versions of source code and data across multiple developers. Rather than relying on a central server to store your project history, Git maintains a complete copy of the entire repository on each developer's computer. This fundamental difference shapes everything about how Git works. The system was created by Linus Torvalds in 2005 and was designed with three core goals: speed, data integrity, and support for distributed, non-linear workflows. These design principles make Git particularly powerful for managing large collaborative projects with many parallel development branches. How Git Stores Information The Object Model Git doesn't store files like traditional systems. Instead, it stores objects identified by cryptographic SHA-1 hashes. Think of a SHA-1 hash as a unique fingerprint for each piece of data—if the content changes even slightly, the hash changes completely, which protects the integrity of your repository. Git uses four main types of objects: Blobs contain the actual contents of your files. When you save a file to Git, the file's contents become a blob object. Trees represent directory structures. A tree object contains references to blobs (files) and other trees (subdirectories), essentially describing what a folder looked like at a particular point in time. Commits are snapshots of your entire project. Each commit contains a reference to a tree object (representing the full state of your project) and one or more parent commits (linking it to previous states). This creates a historical chain. Tags are simply named references to specific commits, useful for marking important versions like releases. The Snapshot Model This is an important distinction from some other version control systems: Git stores complete snapshots of your entire project directory at each commit, rather than storing only the differences (deltas) between files. This means Git can quickly access any version of your project without having to replay a series of file-level changes. References and Branches A reference in Git is simply a pointer to a commit's SHA-1 hash. Branches are named references—they're just pointers to commits that help you organize your work. When you initialize a new repository with git init, Git creates a default branch called "master" by default. However, this branch name is not technically special; it's just a convention. You can create as many branches as you need, each pointing to different commits in your project history. Understanding this is crucial: branches aren't separate copies of your code. They're lightweight pointers, which is why Git makes branching so fast and easy compared to other version control systems. The Commit Graph Commits form a directed acyclic graph (DAG)—a structure where each commit points to one or more parent commits, creating a historical chain without any circular references. In most cases, a commit has exactly one parent (the previous commit). However, when you merge two branches together, you create a merge commit with multiple parents—it has both the commit from one branch and the commit from another branch as its ancestors. This preserves the complete history of how development happened. The DAG structure is what enables Git to handle "non-linear workflows"—meaning you can have multiple independent lines of development (branches) that later converge through merges. Distributed Architecture Local Repositories Here's what makes Git truly different: every developer gets a complete, independent copy of the entire repository on their machine. This means: You can work completely offline Local operations (commits, viewing history, branching) are fast because they don't require network access You have the full history available without contacting a server Each developer's machine is essentially a backup of the entire project There is no required central server—though many teams use one (like GitHub or GitLab) as a convenient place to share work and coordinate among developers. Script-Oriented Design Git was intentionally built as a collection of small, focused scripts and commands that can be combined to perform complex version control operations. This modular design allows developers to automate workflows and extend Git's functionality using shell scripts and other tools. <extrainfo> This design philosophy comes from Unix principles: do one thing and do it well. Each Git command is relatively simple, but they combine powerfully. </extrainfo> Merging Strategies When you integrate changes from different branches, Git needs a strategy for combining them. Git supports several approaches: The "resolve" strategy uses the traditional three-way merge algorithm. It compares three versions: the common ancestor (the last commit both branches shared), your version, and the other version. This helps Git intelligently determine what changed and how to combine the changes. The "recursive" strategy is Git's default for most merges. It's more sophisticated than resolve: when merging, it first identifies multiple common ancestors and creates a merged tree from them before performing the final three-way merge. This reduces the number of conflicts you'll encounter. The "octopus" strategy is automatically used when merging more than two branches together at once, though this is less common in typical workflows. <extrainfo> Different merge strategies exist because different projects have different needs. Most of the time, you'll use the default "recursive" strategy without even thinking about it. You'd only need to explicitly choose a different strategy for special cases. </extrainfo> Why This Design Matters The design choices discussed here—the object model, the snapshot approach, the distributed architecture, and the DAG structure—work together to achieve Git's stated goals. The speed comes from local operations on your complete repository. Data integrity comes from cryptographic hashing. And support for complex, non-linear workflows comes from the DAG structure and powerful merging capabilities. Understanding these foundations will help you predict how Git will behave and use it more effectively in your own projects.