Git: Difference between revisions
(Created page with 'The development of Bedymo and Dynlib is coordinated with the version control system [http://git-scm.com git]. git is a ''distributed'' version control system in that ther…') |
No edit summary |
||
| Line 9: | Line 9: | ||
=== Distributed version control === | === Distributed version control === | ||
In a distributed version control system like git, there is no central repository. Every copy of the repository is technically equal, and is equally able to crate new '''versions'''. In a non-distributed version control system, only the central repository residing on a (publicly available) server is able to create new versions. Hence, you need connection to that server to be able to commit changes. | |||
=== Advantages of distributed version control === | |||
Apart from the ability to track changes and view the entire history of the project also when offline (on a cruise, plane, conference or summer school with limited connectivity) the main advantage of distributed version control systems lies in the handling of '''branches'''. | |||
=== Disadvantages of distributed version control === | |||
The added flexibility of a distributed system comes at the cost of loosing an intuitive way to address the different revisions. Using a central repository, one simply increases an internal revision counter, such that revision 765 supersedes revision 764. Without a central repository there is noone that could assign those kind of numbers. git uses the SHA1-hash of the commited files as an identifier for the revision, e.g. something like <code>bbe0e301cb39b597a49b3819ccf8b0d08d817d2e</code>. One need however only type the first couple of symbols until the identifier becomes unique. In this example taken from dynlib, <code>bbe0</code> is enough to uniquely identify the revision. | |||
Revision as of 14:55, 15 January 2013
The development of Bedymo and Dynlib is coordinated with the version control system git. git is a distributed version control system in that there is no central repository required, as would be for older systems like svn (subversion) or cvs. Any central repository is only central by convention.
Background
Common ideas all version control systems
All version control systems store the history of a set of files and directories in a repository, and are able to restore the file as it used to be in a previous version. In addition to the actual changes in the file(s) all systems also keep meta-information like the editing user, the date and time of the changes as well as a small description of the changes. The development of the project is tracked through commits, which creates and stores a new version or revision of all changed files.
Distributed version control
In a distributed version control system like git, there is no central repository. Every copy of the repository is technically equal, and is equally able to crate new versions. In a non-distributed version control system, only the central repository residing on a (publicly available) server is able to create new versions. Hence, you need connection to that server to be able to commit changes.
Advantages of distributed version control
Apart from the ability to track changes and view the entire history of the project also when offline (on a cruise, plane, conference or summer school with limited connectivity) the main advantage of distributed version control systems lies in the handling of branches.
Disadvantages of distributed version control
The added flexibility of a distributed system comes at the cost of loosing an intuitive way to address the different revisions. Using a central repository, one simply increases an internal revision counter, such that revision 765 supersedes revision 764. Without a central repository there is noone that could assign those kind of numbers. git uses the SHA1-hash of the commited files as an identifier for the revision, e.g. something like bbe0e301cb39b597a49b3819ccf8b0d08d817d2e. One need however only type the first couple of symbols until the identifier becomes unique. In this example taken from dynlib, bbe0 is enough to uniquely identify the revision.