This software version control tutorial talks about one of the most useful features, branching, which is a way, for example, of maintaining files for software features separate from the main code branch. Watch more at: Fundamentals of Software Version Control.
This tutorial is a single movie from the third chapter of Fundamentals of the Software Version Control course presented by lynda.com author Michael Lehman. The complete course is 2 hours and 55 minutes long and reviews the history of version control and demonstrates the fundamental concepts: check-in/checkout, forking, merging, commits, and distribution.
1. Overview of Software Version Control
2. Background of Software Version Control
3. Version Control Concepts
6. Microsoft Team Foundation Server (TFS)
Example history graph of a revision-controlled project.
Version control and source control (and an aspect of software configuration management), is the management of changes to documents, computer programs, large web sites, and other collections of information. Changes are usually identified by a number or letter code, termed the “revision number”, “revision level”, or simply “revision”. For example, an initial set of files is “revision 1″. When the first change is made, the resulting set is “revision 2″, and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged.
Version control systems (VCS) most commonly run as stand-alone applications, but revision control is also embedded in various types of software such as word processors and spreadsheets, e.g., Google Docs and Sheets and in various content management systems, e.g., Wikipedia’s Page history. Revision control allows for the ability to revert a document to a previous revision, which is critical for allowing editors to track each other’s edits, correct mistakes, and defend against vandalism and spam.
Software tools for revision control are essential for the organization of multi-developer projects.
Common Terms Used
Terminology can vary from system to system, but some terms in common usage include:
An approved revision of a document or source file from which subsequent changes can be made.
A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may develop at different speeds or in different ways independently of each other.
To commit (check in, ci or, more rarely, install, submit or record) is to write or merge the changes made in the working copy back to the repository. The terms ‘commit’ and ‘checkin’ can also be used as nouns to describe the new revision that is created as a result of committing.
A fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software.
A merge or integration is an operation in which two sets of changes are applied to a file or set of files. Some sample scenarios are as follows:
- A user, working on a set of files, updates or syncs their working copy with changes made, and checked into the repository, by other users.
- A user tries to check in files that have been updated by others since the files were checked out, and the revision control software automatically merges the files (typically, after prompting the user if it should proceed with the automatic merge, and in some cases only doing so if the merge can be clearly and reasonably resolved).
- A set of files is branched, a problem that existed before the branching is fixed in one branch, and the fix is then merged into the other branch.
- A branch is created, the code in the files is independently edited, and the updated branch is later incorporated into a single, unified trunk.
The repository is where files’ current and historical data are stored, often on a server. Sometimes also called a depot (for example, by SVK, AccuRev and Perforce).
Also version: A version is any change in form. In SVK, a Revision is the state at a point in time of the entire tree in the repository.
A tag or label refers to an important snapshot in time, consistent across many files. These files at that point may all be tagged with a user-friendly, meaningful name or revision number.
The unique line of development that is not a branch (sometimes also called Baseline, Mainline or Master).
Git is a distributed revision control and source code management (SCM) system with an emphasis on speed. Git was initially designed and developed by Linus Torvalds for Linux kernel development in 2005. Based on a recent survey of Eclipse IDE users, Git is reported to have 30% adoption as of 2013.
Every Git working directory is a full-fledged repository with complete history and full version tracking capabilities, not dependent on network access or a central server.
Git is free software distributed under the terms of the GNU General Public License version 2.
Mercurial is a cross-platform, distributed revision control tool for software developers. Mercurial’s major design goals include high performance and scalability, decentralized, fully distributed collaborative development, robust handling of both plain text and binary files, and advanced branching and merging capabilities, while remaining conceptually simple. It includes an integrated web interface. Mercurial has also taken steps to ease the transition for SVN users.
The creator and lead developer of Mercurial is Matt Mackall. Mercurial is released as free software under the terms of the GNU GPL v2 (or any later version).
See a Related Resource:
A Visual Guide to Version Control
Build My Site