A development project with more than one contributor requires a source code repository (repo) or "version control system" (VCS). These systems allow two or more programmers to work on the same set of files. Every programmer can "commit" changes to files. Other participants can then get the changes.
There are a few differences between a programmer's VCS and a normal file sharing system. A VCS keeps track of the file system as it existed before each change. If you decide later that there is a problem with a change, you can "roll back" to a previous version. This safety valve, also used in wikis, gives you the security to make changes. A VCS also shows you details about each change, down to the line that was changed, so you can track down problems.
A VCS also helps merge changes from different contributors. If Bill and Ted each edit different files, then Bill can get Ted's changed file, and Ted can get Bill's changed file. If they both edit the same file, then there is a conflict. The early VCS systems (and their modern descendants like Dropbox and Google Drive) give you both copies (like file_Ted and file_Bill) and let you pick the one that you want. A modern programmer's VCS will merge the changes. If Bill and Ted edited different lines in a text file, the merge can automatically include both sets of changes. If Bill and Ted edit the same line, and the VCS can't figure out what to do, it will ask the recipient to pick the version of the line that he or she wants.
Different VCS systems have different strategies for merging changes in moved and edited files.
A centralized VCS is a server, like a file server. Contributors use client software to pull out a chunk of the files into a local "working copy" or "workspace." They can send changes (commits) to the server, and get updates back with changes from other developers.
A centralized VCS can handle large files and very large repositories. Not every file needs to be replicated to clients, which is important for designers, and for building games that have big graphical files.
Subversion (SVN) is the most popular centralized VCS. Subversion operations are simple and easily learned by everyone on your team. However, Subversion in its current version has a very limited merge operation, which means that it is difficult to use it for merge-intensive workflows like feature and task branches, branch review, and cascading promotion.
Subversion works well for three workflows:
Subversion will easily synchronize developers for centralized continuous integration (CI) and centralized continuous delivery (CD). Historically, centralized CI and CD have evolved with Subversion.
In a distributed version control system, or DVCS, every user has a complete copy of the repository on his or her machine. Users move code changes around with peer-to-peer operations like "push" and "pull." However, in practice few teams use peer-to-peer exclusively; almost all teams use a centralized portal to share code and changes.
Distributed VCS systems need to be good at merging, because they merge every time code moves from one person or place to another. They are good at moving code around the cloud. They have produced a burst of innovation in coding workflows that involve contributing, moving, testing and merging changes.
There are several good open source distributed VCS systems. The most popular system is Git, originally designed by Linus Torvalds to handle code contributions for Linux. Git is loved by programmers because it provides a powerful way for them to manage their local code. However, it is implemented with more than 40 commands, so non-programmers find it confusing.
DVCS systems have created a revolution in the scale of open source software development. Anyone on the Internet can become a contributor to a project by making a copy or "clone" of the project repository and working on it. In contrast, a centralized system limits the number of contributors by requiring an administrator to grant permission to use the centralized repository.
DVCS systems have spawned new workflows that are very useful for continuous delivery. A DVCS system needs to be good at moving and merging "changesets." These bundles of code changes can be routed on any path you want, including release branches, task branches, feature clones, branch review and cascading integration. You can use Git to implement any of the workflows in this guide.
Centralized repository systems like ClearCase, AccuRev and Perforce can use a topology called "streams." Streams give you a structured form of branching, forking and merging, where you can feed changes down predefined paths between individuals, teams and integrated builds. It naturally supports the cascading process. You can use a stream topology to implement any of the workflows we will discuss.
Perforce is a centralized repository that has some of the advantages of Subversion. It can handle big files and big repositories, and is often used to build games with spectacular graphics. Compared with Subversion, it has a good structure for merging and tracking changesets. That allows it to implement many of the merge-based workflows that are coming out of the DVCS world. It can even host a centralized view of Git repositories.
As a centralized repository, Perforce requires some administration and places more restrictions on contributors than a DVCS. However, it has an advantage over a DVCS if you are assembling multiple systems from multiple components. In Perforce, you can assemble systems just by making mix-and-match views of the shared components. With a DVCS you would be required to copy and maintain multiple copies of the components.