So, when we develop a program or some kind of app, we worked as a group. That’s a usual thing.
Let’s imagine there are 3 people woks in the same project and they are in a different location in the world.
- Kasun from Sri Lanka
- David from the USA
- Mathew from the UK
Here above three guys who worked in this project. First, Kasun develops a program with his idea, and he wants to share this with his group. In earlier, he had to zip it and upload to google drive and share the link. Then David and Mathew have to download it, then change something and upload again. But that method wasn’t reliable for programmers.
So, to overcome that obstacle version control systems were introduced. In here we can create a specific location in server for our every single project. So, Kasun, David and Mathew can work in the same project at the same time.
Version control system
Version control refers to the cataloging of reversions to some (generally text-based) documents. While the term “Version control” in most generally associated with programmers, it is equally relevant for writers, journalists, and even university students. Examples of common services that automatically track document revisions and versions include Google Docs and dropbox.
Benefits of version control system
- Backup and restore
- Sync with multiple computers
- Working in a team
- Safely create and text new feature
- Ownership / Credits / Blames
Purpose of version control Systems
- To allow developers to work simultaneously on the same project
- To avoid conflicts arising from different developers working simultaneously on the same code.
- To archive every version of everything that has ever existed
Available version controlling systems
Common terminology in version control system
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.
A change (or diff, or delta) represents a specific modification to a document under version control. The granularity of the modification considered a change varies between version control systems.
- Change list
On many version control systems with atomic multi-change commits, a change list (or CL), change set, update, or patch identifies the set of changes made in a single commit. This can also represent a sequential view of the source code, allowing the examination of source as of any particular changelist ID.
To check out (or co) is to create a local working copy from the repository. A user may specify a specific revision or obtain the latest. The term ‘checkout’ can also be used as a noun to describe the working copy. When a file has been checked out from a shared file server, it cannot be edited by other users. Think of it like a hotel, when you check out, you no longer have access to its amenities.
Cloning means creating a repository containing the revisions from another repository. This is equivalent to pushing or pulling into an empty (newly initialized) repository. As a noun, two repositories can be said to be clones if they are kept synchronized, and contain the same revisions.
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 conflict occurs when different parties make changes to the same document, and the system is unable to reconcile the changes. A user must resolve the conflict by combining the changes, or by selecting one change in favor of the other.
- Delta compression
Most revision control software uses delta compression, which retains only the differences between successive versions of files. This allows for more efficient storage of many different versions of files.
- Dynamic stream
A stream in which some or all file versions are mirrors of the parent stream’s versions.
exporting is the act of obtaining the files from the repository. It is similar to checking out except that it creates a clean directory tree without the version-control metadata used in a working copy. This is often used prior to publishing the contents, for example.
- Forward integration
The process of merging changes made in the main trunk into a development (feature or team) branch.
Also sometimes called tip, this refers to the most recent commit, either to the trunk or to a branch. The trunk and each branch have their own head, though HEAD is sometimes loosely used to refer to the trunk.
importing is the act of copying a local directory tree (that is not currently a working copy) into the repository for the first time.
to create a new, empty repository.
- Interleaved deltas
some revision control software uses Interleaved deltas, a method that allows storing the history of text based files in a more efficient way than by using Delta compression.
Similar to trunk, but there can be a mainline for each branch.
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 branch is created, the code in the files is independently edited, and the updated branch is later incorporated into a single, unified trunk.
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. (This type of selective merge is sometimes known as a cherry pick to distinguish it from the complete merge in the previous case.)
The act of copying file content from a less controlled location into a more controlled location. For example, from a user’s workspace into a repository, or from a stream to its parent.
- Pull, push
Copy revisions from one repository into another. Pull is initiated by the receiving repository, while push is initiated by the source. Fetch is sometimes used as a synonym for pull, or to mean a pull followed by an update.
The repository is where files’ current and historical data are stored, often on a server. Sometimes also called a depot.
The act of user intervention to address a conflict between different changes to the same document.
- Reverse integration
The process of merging different team branches into the main trunk of the versioning system.
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.
The act of making one file or folder available in multiple branches at the same time. When a shared file is changed in one branch, it is changed in other branches.
A container for branched files that has a known relationship to other such containers. Streams form a hierarchy; each stream can inherit various properties (like versions, namespace, workflow rules, subscribers, etc.) from its parent stream.
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. See baselines, labels and tags.
The unique line of development that is not a branch (sometimes also called Baseline, Mainline or Master)
An update (or sync, but sync can also mean a combined push and pull) merges changes made in the repository (by other people, for example) into the local working copy. Update is also the term used by some CM tools (CM+, PLS, SMS) for the change package concept (see changelist). Synonymous with checkout in revision control systems that require each repository to have exactly one working copy (common in distributed systems)
- Working copy
The working copy is the local copy of files from a repository, at a specific time or revision. All work done to the files in a repository is initially done on a working copy, hence the name. Conceptually, it is a sandbox.
- Pull request
A developer telling others to review his “pushed” changes
Let discus more about version control system in near future.
- First, the idea of VCS came from participating in the session done by Random Software Ltd. To check more about RSL click here.
- Git Handbook.