Source control has a long history. Fast forward to today, we have passed several milestones in source control innovation that improves developer productivity and collaboration.

Tip: Source control is a subset of version control, that is designed to track changes in source code.

Early Days of Source Control

In the early days, developers realized the need for source control for collaboration. Yet the technology and sophistication of developer needs were limited. Initially, most source control models use a shared file system locally. It was named the Local Data Model. This allowed developers sitting in an office to contribute to the same code base.

And, for obvious reasons, developers needed a more robust model that wasn’t limited to local file systems.

Entering the era of SVN

As the next stage of evolution, client-server models emerged, allowing robust infrastructure to track code remotely while developers can contribute via a network. These early client-server models focused on a centralized remote repository implementation. Subversion (SVN) was one of the most adopted and lasted over decades, originally inspired by CVS.

SVN primarily focuses on tracking changes to individual files. Since most of you are familiar with Git, think of it as Git without push . Once you commit, the code directly goes into the remote server. Simply put, your local changes are tracked in the file system, and once they are ready, you can commit them to the SVN repository.

If we look at its features, I believe Git was mainly inspired by it.

• Open-source licensed — Apache License since the 1.7 release
• Commits as true atomic operations.
• Support for branching.
• Maintains versioning for directories and some specific file metadata.
• Versioning of symbolic links.
• Natively client–server, layered library design.
• Optimum use of network while transmitting the diffs between client and server.
• File locking for unmergeable files (“reserved checkouts”).
• Path-based authorization.
• Language bindings for C#, PHP, Python, Perl, Ruby, and Java.
• Merges between branches will be tracked and allow automatic merging between branches.

However, this model has several downsides addressed in distributed version control systems like Git.

• Having a central repository means that everybody has to write to it. Limiting by directory paths makes it difficult for fine-grained access control.
• Developers need to commit robust code to the central repository. Therefore, each commit needs thorough testing and takes time. If anything happens before committing, your local code changes may get lost forever.

And the list goes on and on. If you would like to know more about the limitations of centralized version control systems, watch the video from Linus Torvalds on git.

Distributed model with Git

With a distributed model like Git, developers can now have their own repository. Now, you have a repository with complete autonomy where you can use a branching strategy of your choice, commit frequently, etc. Once the code is ready, you can create a Pull Request to the central repository. This makes code collaboration a whole lot easier.

Tip: Git tracks your content. It never tracks a single file. However, it’s completely possible to track a project with a single file. Git thinks of it as full content that tracks the whole project’s history. This improves performance over SVN, which tracks files.

There are many commercial implementations of Git, including;

• GitHub
• GitLab
• AzureDevOps

These are only a few advantages of using Git, which still dominates the source control space.

But what if you want to use Monorepos or move into Multirepos and share code between these repositories?

Regarding Monorepos, you need a higher level of context (e.g., module boundaries) for the code you track in the repository. For example, if you track multiple projects in a Monorepo, each requires CI/CD configuration that needs to be triggered depending on which part of the code is updated.

Also, Monorepos demands more optimizations for commonly executed tasks and ways to reduce cognitive load from developers.

And, if you move ahead with multiple repositories, it introduces a whole new set of challenges. You may need ways to reuse code between repositories. Moving towards options like Git Submodules, Git Subtree, or using a packaging system (e.g., NPM) alone won’t address the issue. It creates more problems. Check out the article 4 Git Submodules Alternatives You Should Know to understand some of these limitations.

So simply put, when projects scale, they demand new tools and technologies that go beyond source control to track changes in higher-order modules/components.

Component-based model

Bit is an open-source build system that completely changes your software development, taking you into composable architectures. If you are new to Bit and the component-based model, I highly recommend reading Thinking Bit.

In the world of Bit, a component has its own repository. Component changes can be tracked, versioned, exported independently to bit.cloud, and shared between projects, teams, etc. Bit is technology agnostic and has direct support for components in;