A Visual Guide to Version Control – SCM & VCS

What is Version Control?

Version control is a system that records changes to a file or a set of files over time so that specific versions can later be retrieved. In this article, we will use source software code as version-controlled files for the context, but you can actually do this with almost any type of file on a device.

A Version Control System (VCS) is a very smart thing to do if you are a graphic or web designer and want to manage every version of an image or layout (which you would most likely want to). This allows you to revert selected files back to an earlier state, revert the whole project back to a previous state, compare changes over time, see who last changed something that might trigger a problem, who implemented a problem, and when and more. Utilising VCS also usually ensures that you can recover files quickly if you mess stuff up. Additionally, with very little overhead, you get all this.

Git (distributed), Mercurial (distributed), and Subversion (centralised) are some common version control systems.

Software that offers versioning features (Git, Subversion, TFS Version Control) all fall into this group. Version Control Systems are just that.

Caution, SCM can refer to different meanings about Versioning:

• Software Configuration Management is a wider approach that integrates all the software building, packaging, and deployment processes required, including Version Control Systems. It does not apply per se to apps.
• Source Control Management is same as Version Control and Source Control and VCS.

Moreover, people may use SCM to refer to other naming:

• Source Code Management, as in Source Code Control System
• Software Code Management, but this is a deformation of Software Configuration Management
• Source Configuration Management, same meaning as Software Configuration Management but maybe more focused on source code than on the whole software (settings, command line arguments, host parameters, etc)

Therefore it is misleading to only use the acronym SCM: some individuals may understand the same concept as VCS, some others may understand the whole process where VSC is just an element.

There are two general version control varieties: centralised and distributed. Distributed version control is more modern, runs smoother, has more functionality, is less prone to bugs, and is somewhat more difficult to comprehend. You will need to determine if it is worth the extra difficulty for you.

The number of repositories is the key difference between centralised and distributed version control. There is only one repository in centralised version control and there are several repositories in distributed version control. Here are pictures of the typical arrangements:

Each user gets his or her own working copy inside centralised version control, but there is only one central repository. As soon as you commit, it is possible for your co-workers to update and to see your changes. For others to see your changes, 2 things must happen:

• You commit
• They update

Each user obtains his or her own repository and working copy in distributed version control. After you commit, others have no access to your changes until you push your changes to the central repository. When you update, you do not get others’ changes unless you have first pulled those changes into your repository. For others to see your changes, 4 things must happen:

• You commit
• You push
• They pull
• They update

Note that commands to commit and update only transfer changes between the working copy and the local repository, without affecting any other repository. The push and pull commands, on the other hand, transfer modifications between the local repository and the central repository without affecting your working copy.

Conflicts

The version control system lets multiple users edit their own copies of a project simultaneously. Usually, the version control system is able to merge simultaneous changes by two different users: for each line, the final version is the original version if neither user edited it, or is the edited version if one of the users edited it.

A conflict occurs when two different users make different changes to the same line of a file simultaneously. In this case, the version control system cannot automatically decide which of the two edits to use (or a combination of them, or neither!). To resolve the conflict, manual intervention is needed.

“Simultaneous” changes do not necessarily happen at the exact same moment of time. Change 1 and Change 2 are considered simultaneous if:

• User A makes Change 1 before User A does an update that brings Change 2 into User A’s working copy, and
• User B makes Change 2 before User B does an update that brings Change 1 into User B’s working copy.

There is an explicit process called merge, in a distributed version control system that incorporates concurrent editing by two separate users. Sometimes merge completes automatically, but if there is a conflict, merge requests help from the user by running a merge tool. In centralised version control, any time you update, merging occurs implicitly.

It is better to avoid a conflict than to resolve it later. Conflicts, notwithstanding the best efforts, are bound to occur.

Git

Git is a distributed version control system created by Linus Torvalds in 2005 to monitor changes in any set of files, originally designed to manage work between source code programmers during the development of software. Speed, data integrity and support for distributed and non-linear workflows are its objectives.

Git vs GitHub

Git is a version control system that allows you to maintain your source code history and keep track of it while GitHub is a cloud-based storage service that allows you to manage Git repositories. If you have open-source projects using Git, GitHub is intended to help you manage them better.

Many open source enthusiasts are probably weary of GitHub acquisition by Microsoft, knowing very well that Microsoft is a for-profit corporation, and who knows, terms and conditions are bound to change (as is often the case for such deals) concerning the world’s leading software development platform.

If you are one of those already thinking of alternatives to Github for hosting your open source project(s), then check out the list below.

1. GitLab – https://about.gitlab.com
2. BitBucket – https://bitbucket.org
3. Beanstalk – https://beanstalkapp.com
4. SourceForge – https://sourceforge.net

Version control best practices

1. Use a descriptive commit message
2. Make each commit a logical unit
3. Avoid indiscriminate commits
4. Incorporate others’ changes frequently
5. Share your changes frequently
6. Coordinate with your co-workers
7. Remember that the tools are line-based
8. Don’t commit generated files
9. Understand your merge tool

Tips

1. Cache your password so that you don’t have to type it every time
2. Setup email notification whenever someone pushes or commits to the central server

References

https://git-scm.com

https://en.wikipedia.org/wiki/Git

https://en.wikipedia.org/wiki/Version_control

https://stackoverflow.com

If you are looking for exciting opportunities, sign up on Talent500 to work with Fortune500 companies across the globe.