When working with a group on a project, you need to have a way to integrate the contributions of various team members.
It is possible to write in software like MS Word and email copies of the files around between collaborators. However this is a risky practice. As revisions of the file move around, the number of versions of the file will go up. Trying to ensure that changes are not overwritten by mistake becomes an increasingly difficult task.
Given enough contributers and enough versions of the file it is inevitable that someone’s changes will get lost or that an older version of a paragraph will suddenly return when someone uses the wrong version of a file.
Sharing the file on a site like dropbox is also not a solution because if more than one person wishes to edit at the same time it is impossible to know which version of the file will be there when everyone is done.
The quote in French means "Good accounts make for good friends" and is fitting. As business venture needs a good system to track its money, and a project needs a good system to keep track of the work done by its members.
A project can be any form of creative work, a computer program, a Novel, this book, a set of knitting patterns and so forth. Most projects will consist of one or more files that will reside on the computers of the project members.
As an example take this book. It consists of around 20 or so files that contain the actual text of the book, one for each chapter or section, and then a bunch of other files that contain things like the images that are included and a few random others.
As the book is being written we want to be able to share those documents between the writers, reviewers, editors, and in this case the world at large. Other projects will be shared in different ways.
In order to make this collaboration work we need two things. First a way to share the documents between the project members, and secondly a set of rules on how those contributors will work together.
It is all fine and good to say that it is possible to know if two users have the same version of a file, or how their copies differ, but if you have 20 people attempting to assemble a complex project you need a way to organize people so that tasks can be managed.
This book will attempt to lay out how to construct a system that will work for your team, by showing how different teams have faced these problems and mapping out their solutions.
Thankfully various computer programmers over the years have faced this problem and realizing that it was a problem, built tools to try and solve it. These tools collectively are known as "Version Control Systems" Or "Revision Control Systems". The history of Version Control systems dates back to the 1970’s and has generated significant progress.
The current major Version Control system is called "git" and was created by Linus Torvolds, when he was unable to find that existing systems did not meet the needs of the team that was developing the Linux kernel.
GIT is a very powerful tool that has a lot of features, but most of what is needed to work and collaborate with others can be done with a small enough to learn pretty quickly. In addition while many git tutorials show how to use git from a command line there are now many very nice graphical tools to enable the use of git without having to ever see a command line if you don’t want too.
The way version control systems work is they track files and changes to those files. So it is possible to see the history of changes to a file and when each line was last changed and by whom.
This allows project members to say that they all the same version of a file, and to ensure that everyone’s changes have been accounted for. Git allows users to ensure that they have the same version of the project files by applying a mathematical function called SHA1 to the files in a project. At any given time the files committed to a project will have a unique SHA1 key.
Furthermore, if two members of project team have a project directory with the same SHA1 key they can be sure that the files in the project are the same.
Every time files are changed in a project git will create a new SHA1 key for the project. So if Bob and Lisa want to know if they have the same files they do not have to check every file for changes they can just compare their keys. If they match they know that the files are the same.
However if they are not the same git can look at the history of the files and figure out what has changed. So if Bob has sent Lisa file for editing and she made some changes, git will use the SHA1 keys to compare the history of the files. In this case it will see that Bob’s files are an ancestor to Lisa’s. It can then know exactly what changes Lisa made and allow Bob to safely merge her changes. We will see an example of how to do this in Pull Request.
SHA1 is a cryptographic hash that when you apply it to data will return a 40 character string that looks like this, 3fee35069bb9591edc3ab76f44b69c7b2d44be88.
|
Note
|
you can not recover the original files from that hash, SHA1 is strictly a one way function. |
In general you will see a shorter form that looks like 3fee350. In this case git will use as short a version of the string as it can as long as it is unique. Git does this because the developers realized that having to use a 40 character string would be difficult for users.
The details of how SHA1 turns arbitrary data into a hash are rather technical. If you want to know more about how SHA1 works you can look on WIkipedia.
The thing to remember is that the chances that two SHA1 keys will be the same while the files are not is 1:1048. That is close enough to 0 for me.
The use of git is greatly enhanced by GitHub a company that was founded in 2008 to facilitate using git to collaborate on software projects. Since the GitHub has grown to become the most popular site for building collaborations in the open source software community.
GitHub is itself a distributed company with its team spread out all over the place so they not only develop the tools for working with distributed teams, they use them ever day.