version_control:introduction_to_version_control_systems
This is an old revision of the document!
Table of Contents
Introduction to Version Control Systems
Mithat Konar
Many names, same thing
- Version Control System (VCS)
- Revision Control System (RCS)
- Source Control (SC)
- Source Control Management (SCM)
Examples
Primary functions
- Create a repository to store all the source code for a project.
- Maintain a complete history of the changes to the source code for a project.
Secondary functions
- Permit moving back and forth through different revisions (i.e., the history) of the project.
- Allow branching and merging of revisions.
- Let multiple users (a team) share and integrate code.
Backing up is not a core function!
- The primary reason for using VCS is not backing up your code!
- The VCS you use may suck as a backup system.
- Backing up is something you may or may not get “for free.”
- Depending on the VCS you use, if you lose the repository, you may lose all the history—or the entire project.
Centralized versus distributed
- Two main groups of VCS:
- Centralized
- Distributed
Centralized systems
- Early systems were based on a centralized client-server architecture.
- The server holds TheOneHolyRepository™.
- Clients are allowed to “check out” one or more source files for editing.
- When a user is finished editing, it is “checked in” to the server.
- Only one user at a time can check out a given file.
- CVS, SVN
Distributed systems
- Distributed systems use a peer-to-peer architecture.
- Replacing centralized systems.
- Individual users have complete, fully editable repositories.
- Users synchronize their repositories with each other as needed.
- Managing can be more complicated for groups, but is more flexible.
- Can be configured to work like to a centralized system.
- Git, Mercurial, Bazaar
Revisions
- A revision is a snapshot of the state of a project at a given moment.
- When a meaningful change to the code of a project is completed, a revision incorporating that change is committed (placed) into the repository.
- Revisions are also called commits, snapshots, and changesets.
- If needed, differences between the most recent state and older revisions can be determined.
Navigating revisions
- Many VCS's let users move back to older revisions of files or the whole project.
- Details are system dependent.
Branching
- Many VCS's facilitate branching: making a copy of the project whose development will go in parallel with the original.
- A branch to test ideas that develops in parallel with the main release.
- A branch to develop a bugfix.
Merging
- Many VCS's facilitate merging: incorporating changes from a branch or another repository.
- Applying a bugfix to the current release.
- Applying a security update developed for a 2.0 release to the 1.0 releases.
Single-user vs. multi-user scenarios
- How a VCS is used depends somewhat on whether the project is a single-person or multiple-person one.
Getting started with git
-
- GitHub's guides (the Windows stuff covers git based on their own Desktop Client).
- You will need to know how to open an appropriate command line interface (i.e., “terminal” or “command prompt window”) in your OS.
Basic operations with git
- Create a repository:
git init
- Add a new file or the changes to an existing file to the repository:
git add {filename}
- Add all new and changed files to the repository:
git add *
Basic operations with git
- Commit the staged (“added”) changes:
git commit -m "A message about this commit."
- Get status of repository:
git status
- Get history of repository:
git log
GUI interface
git gui
: opens a GUI for performing common git functionsgitk
: opens a GUI commit browsing tool.- Other third party git tools are available.
More git stuff
- Roger Dudler's git - the simple guide is beginner friendly and quite good.
Revisions vs. versions
- A revision (i.e., commit or snapshot) that has has been published for general use is a release or a version.
- Often not a VCS concept but an arbitrary determination by the developers.
- Typically there are several revisions (commits) between releases/versions.
Version numbering
- A VCS will typically automatically assign identifiers for revisions.
- Identifiers for releases (i.e., the “version number”) are up to you.
Version numbering
- The Microsoft system1):
- {major}.{minor}.{build}.{revision}
- e.g.:
5.50.4807.2300
- {build} and {revision} are optional.
- {revision} here does not have the same meaning as revision used above (i.e., commit or changeset).
Version numbering
- Microsoft defines these as2):
- Major: … different major versions are not interchangeable. A higher version number might indicate a major rewrite of a product where backward compatibility cannot be assumed.
- Minor: … significant enhancement with the intention of backward compatibility. This higher minor version number might indicate a point release of a product or a fully backward-compatible new version of a product.
- Build: … a recompilation of the same source. Different build numbers might be used when the processor, platform, or compiler changes.
- Revision: … intended to be fully interchangeable. A higher revision number might be used in a build that fixes a security hole in a previously released assembly.
Version numbering
- Another common system is {major}.{minor}.{maintenance}.
- {maintenance} is essentially MS's {revision}.
- The character
a
is often used to indicate an alpha release,b
for beta,rc
for a release candidate.- e.g.:
4.5b2
- The last alpha should become the first beta.
- The last beta should become the first release candidate.
- The last release candidate should become the first full release.
Version numbering
- Some projects use date-based versioning, e.g.:
2015.06.23
,15.033
, etc. - Whatever you do, be consistent and meaningful.
Endcruft
This content is Copyright © 2011-2016 Mithat Konar
version_control/introduction_to_version_control_systems.1461180741.txt.gz · Last modified: 2016/04/20 19:32 by mithat