Skip to main content
In this lesson, we’ll explore the two main models of source control: centralized and distributed. Understanding their architectures, advantages, and use cases will help you choose the right system for your projects.

​
Centralized Source Control

In a centralized model, a single repository acts as the authoritative source for all code changes. Developers commit directly to this central hub.
The image illustrates a concept of centralized source control with a server repository depicted as a cylinder.

​
Examples of Centralized Systems

The image lists examples of centralized source control systems: Team Foundation Version Control (TFVC), Concurrent Versions System (CVS), Apache Subversion (SVN), and Perforce Helix Core.
Common advantages:
  • Scalability: Handles large codebases efficiently.
  • Access Management: Fine-grained permission controls.
  • Usage Oversight: Tracks who made which changes and when.
  • Exclusive Control: File locking prevents conflicting edits.
The image outlines the advantages of centralized source control, highlighting scalability, access management, and usage oversight.

​
When to Choose Centralized Control

  • Large, monolithic codebases requiring consistent structure
  • Projects needing detailed audit trails and permission scopes
  • File types that are difficult to merge concurrently

​
Distributed Source Control

Each developer has a full local copy of the repository, including its entire history. This architecture boosts autonomy, redundancy, and offline work.
The image illustrates a distributed source control system, showing interactions between a central server repository and two systems (A and B) with pull, push, commit, and replace actions.
The most popular distributed systems are Git and Mercurial:
The image lists examples of distributed source control systems: Git and Mercurial.
You get full history access even when offline, making code reviews and commits possible without an internet connection.
Key Strengths:
  • Cross-Platform Flexibility: Runs on Windows, macOS, and Linux.
  • Community-Driven Reviews: Pull requests streamline collaboration.
  • Offline Functionality: Full commit, diff, and log capabilities without network access.
  • Complete History in Every Clone: Every contributor has a backup of the repository.
  • Wide Adoption: The de facto choice for open-source development.
The image lists the key strengths of distributed source control, including flexibility, community-centric development, offline functionality, history tracking, and growing popularity. Each strength is highlighted in a colorful box with an icon.

​
Ideal Use Cases for Distributed Control

  • Modular or microservice-based codebases
  • Open source projects with many external contributors
  • Teams spread across different regions
  • Cross-platform development environments
The image outlines ideal applications for distributed source control, highlighting its efficiency for compact codebases, open-source projects, remote collaboration, and cross-platform development.

​
Git vs. Team Foundation Version Control (TFVC)

FeatureGit (Distributed)TFVC (Centralized)
Repository ModelEach developer has a full clone locallySingle central repository; local workspace for latest code
Offline OperationsFull commit, branch, and history access at all timesLimited to local workspace edits; must check out changes
Branching & MergingLightweight branches, easy mergesHeavyweight branching, file locking for conflict prevention
Collaboration WorkflowPull requests, forks, social codingCheck-in policies, gated check-ins
The image compares Git and Team Foundation Version Control, highlighting Git as a decentralized system and Team Foundation as a centralized framework.

​
Reasons to Select Git for Source Control

  1. Feature Branching
    Isolate new features in dedicated branches before merging.
The image lists reasons for selecting Git for source control, including branching for features, decentralized repositories, integration via pull requests, collaboration with the community, and feedback-driven releases. It also includes a diagram illustrating feature branching.
  1. Full Autonomy
    Every developer holds a complete, self-contained repository.
The image is a slide titled "Selecting Git for Source Control – Reasons," listing benefits such as decentralized repositories and collaboration, with a diagram illustrating full repositories.
  1. Pull Requests & Code Reviews
    Built-in workflows for peer review, discussion, and approval.
The image outlines reasons for selecting Git for source control, highlighting integration via pull requests with a diagram and brief explanations.
  1. Community Collaboration
    Forks and pull requests simplify contributions from any developer.
The image is a slide titled "Selecting Git for Source Control – Reasons," highlighting five reasons, with "Collaboration With the Community" emphasized. It includes a diagram and notes on Git's collaborative benefits.
  1. Continuous Integration & Rapid Feedback
    Seamless integration with CI/CD pipelines for faster release cycles.
The image outlines reasons for selecting Git for source control, including branching for features, decentralized repositories, integration via pull requests, collaboration with the community, and feedback-driven releases. It also highlights Git's role in enabling continuous integration and incorporating feedback into release cycles.

​
Common Objections to Using Git

  • History Rewrites: Mistakes in rebasing or force-push can alter commit history.
  • Large File Management: Git isn’t optimized for big binaries; consider Git LFS.
  • Steep Learning Curve: New users may need training to master branching strategies.
Improper use of git reset or git rebase can rewrite shared history—coordinate closely with your team.
The image lists three objections to using Git: history management, handling of voluminous files, and educational investment.

Watch Video