Ryan Hodson - Rys Git Tutorial

Well talk more about the core philosophy behind Git in a moment, butfirst, lets step through the evolution of version control systems ingeneral.

Before the advent of revision control software, there were only files andfolders. The only way to track revisions of a project was to copy the entireproject and give it a new name. Just think about how many times youvesaved a backup called my-term-paper-2.doc. This isthe simplest form of version control.

Revision control with files and folders

But, its easy to see how copying files from folder to folder couldprove disastrous for software developers. What happens if you mis-label afolder? Or if you overwrite the wrong file? How would you even know that youlost an important piece of code? It didnt take long for softwaredevelopers to realize they needed something more reliable.

So, developers began writing utility programs dedicated to managing filerevisions. Instead of keeping old versions as independent files, these new VCSsstored them in a database. When you needed to look at an old version, you usedthe VCS instead of accessing the file directly. That way, you would only have asingle checked out copy of the project at any given time,eliminating the possibility of mixing up or losing revisions.

Local version control

At this point, versioning only took place on the developerslocal computerthere was no way to efficiently share codeamongst several programmers.

Enter the centralized version control system (CVCS). Instead of storingproject history on the developers hard disk, these new CVCS programsstored everything on a server. Developers checked out files and saved them backinto the project over a network. This setup let several programmers collaborateon a project by giving them a single point of entry.

Centralized version control

While a big improvement on local VCS, centralized systems presented a newset of problems: how do multiple users work on the same files at the same time?Just imagine a scenario where two people fix the same bug and try to committheir updates to the central server. Whose changes should be accepted?

CVCSs addressed this issue by preventing users from overriding otherswork. If two changes conflicted, someone had to manually go in and merge thedifferences. This solution worked for projects with relatively few updates(which meant relatively few conflicts), but proved cumbersome for projects withdozens of active contributors submitting several updates everyday: developmentcouldnt continue until all merge conflicts were resolved and madeavailable to the entire development team.

The next generation of revision control programs shifted away from the ideaof a single centralized repository, opting instead to give every developertheir own local copy of the entire project. The resultingdistributed network of repositories let each developer work inisolation, much like a local VCSbut now the conflict resolution problemof CVCS had a much more elegant solution.

Distributed version control

Since there was no longer a central repository, everyone could develop attheir own pace, store the updates locally, and put off merging conflicts untiltheir convenience. In addition, distributed version control systems (DVCS)focused on efficient management for separate branches of development, whichmade it much easier to share code, merge conflicts, and experiment with newideas.

The local nature of DVCSs also made development much faster, since you nolonger had to perform actions over a network. And, since each user had acomplete copy of the project, the risk of a server crash, a corruptedrepository, or any other type of data loss was much lower than that of theirCVCS predecessors.