Back in the early seventies, an engineer at Bell labs released the Source Code Control System, or SCCS. SCCS was an early attempt at maintaining records of changes made to source code. SCCS gave way to Revision Control System, or RCS, and RCS in turn gave way to Concurrent Versions System, or CVS. Eventually, CVS faced competition from newer, distributed version control systems such as Git and Mercurial. Each of these platforms inherited one or more crucial ideas, or components, or from their predecessors while still bringing new features and innovations to the table. Regardless of their individual features and innovations, all of them attempt to solve one basic problem: tracking and maintaining the history of files and projects. These tools are collectively called Version Control Systems or just Version Control, but they lead to an interesting question: why track and maintain the history of text files? The answer is at once both obvious and non-intuitive. It's obvious that keeping detailed history helps you rollback performance degradations and bugs quickly and easily. Many also facilitate easy backup of your code to a networked server. However, I think the real win with detailed histories is the way they enable multiple developers to work on the same file. If you and I are both editing the same file, a detailed history can help us interleave our changes, incorporating without overwriting the changes each of us has made.

The differences between version control systems is largely found in their ability to handle changes across one or multiple files for each commit or historical record, and the way they handle remote repositories. For instance, SCCS and RCS are only capable of handling the changes of a single file at a time. CVS, on the other hand, is capable of atomic commits of multiple files at the same time. CVS also provides the ability to commit one's work to a CVS centralized server. Conversely, Git enables developers to decentralize their code repository, sending their commits to any number of remote servers or even other developers.

Maintaining a historical record of everyone's work is, in my experience, the single largest problem with team development. It's a problem because my work may be in the same file as your work. If I submit my changes while you're still making yours, there's a good chance that your changes will overwrite mine and my work will be lost. Likewise, my work may overwrite a change you made just seconds before I started. Rather than simply locking one another out of the file(s) we're editing, we need a way that fosters the ability for you and I to work on the same file, often even editing the same method at the same time. Version control is the historical answer to this problem, and today one of the most common version control systems is Git. We'll learn more about Git and how it solves this problem later in this chapter.

Having to maintain a historical record of a developer's work to ensure no changes are inadvertently lost is by no means the only problem facing teams of developers. There's an old joke about asking a group of five developers what their favorite editor is and getting back nine answers. We developers are opinionated on how and what to use to accomplish our work. Style is, to many of us, just as important as substance. As a team, the issue of code style matters because it affects how we view, read, and understand code, which in turn affects our ability to quickly and easily find, fix, and test bugs. Traditionally, these kinds of problems have been solved by style guides, or social contracts among developers to maintain a common style between files and projects. Some of the most popular languages have even published style guides. Ruby and Python are some of the best examples of this, especially Python's Python Enhancement Project 0008 or PEP8 guide. Social contracts are great, but they tend to suffer in times of emergency. Maintaining the social style norms can be a chore. Ultimately, we'd be better off with an automatically applied style.

Perhaps one of the most vexing problems teams face is the issue of naming things. The hardest problem in computer science, as the old adage says, is cache invalidation and naming things. I once worked with a brilliant developer; he taught me a good number of things, but his background was in assembly and Fortran on ancient memory-strapped systems. All his variable names were single characters: a, b, …z. Modifying his code was an exercise in whiteboard-symbol management. Another developer I worked with maintained strict Hungarian notation names, prefacing all variables with a single character identifying the type: iIntegerVar, boolean, and so on. His code was far easier to read and understand, but it still stood out against the rest of the team's code, especially considering the strict typing and tools the language provided. This posed a problem for our team as it routinely meant finding blocks of functionally-duplicate code. Team members didn't have a common naming scheme to look up objects and functions, so they duplicated functionality. The bigger the project, the more likely this kind of thing is going to happen.