VERSION CONTROL SYSTEMS ARE A CRUCIAL PART OF BUILDING SOFTWARE — COMBINING A REPOSITORY OF PROJECT FILES WITH THE HISTORY OF ALL CHANGES IN CODE, MAKES EDITING AND UNDERSTANDING CODE A LOT EASIER OVER TIME.
The main asset to using a version control system is in keeping the workflows of team members coordinated as they work through various releases. They can research, track, and undo code with ease. Being able to work on the same code simultaneously without code conflicts, means they can see when changes were made, who made them and why.
You wouldn’t drive a car without knowing how to drive… or maybe you would… but it wouldn’t be the logical thing to do.
The same goes for version control systems, you wouldn’t implement one into your workflow without first deciding which version control system is the most suitable. And while a majority of options out there have similar benefits, the differences can have a massive impact.
GIT VS. SVN
If you know a little something about version controls, it’s likely you’ll be familiar with the rivalry between Git and SVN.
When it comes to deciding whether to use a centralised version control system — SVN, or a distributed version control system — Git, you need to understand that whichever one you choose will affect how you commit changes.
Just because one method works well for one organisation, doesn’t mean it’ll work the same for another. To determine which system to use, you first need to look at how each one works.
SVN, or Subversion, held the title for most popular centralised version control system for a long time.
How it works is, all files and historical data are stored on a central server, where developers commit to changes directly from within that central server repository.
Work is comprised of three parts:
Trunk: The hub of current, stable code and product. It includes only tested, unbroken code.
Branch: Where new code and features are housed. Team members use a copy of the trunk code, and conduct research and development in the branch. Doing so allows each team member to work on the enhanced features without the disruption of individual progress.
Tags: Can be viewed as a duplicate of a branch at a specific point in time. They are used during deployment after the branch code is finished rather than during development. Code with tags makes it easier to not only review, but revert code where necessary.
Here’s how it looks in motion: On creation of a new feature, code is first branched from the trunk, i.e. an exact copy of the trunk is taken and placed into a new folder within the area of the branch. Work is then started on a feature, and on completion, changes are merged back into the trunk.
The benefit of branching is in making commits into the branch without breaking the trunk. It is only when code is error-free that you can merge into the trunk, keeping it stable.
The downside? Limited offline access is a common area of complaint, but more detrimental is the prospect of a single point of error destroying all builds as a result of working on one central server — one central server = one single point of failure.
Centralised systems were the version control system of choice for years, until recently surpassed by Git.
Because unlike SVN, Git utilises multiple repositories — a central repository and a series of local repositories.
What are local repositories?
Exact copies of the central repository with an entire history of changes.
Similar to SVN is the Git workflow, except with the addition of an extra step — in creating a new feature, an exact copy of the central repository is taken to create the local repository on your local machine, or local trunk if you will. Work on your local repository is done exactly as would be the case in SVN, by creating new branches, tags, etc. Branches are then merged into your local repository (local trunk), and when ready to merge into the central repository, changes from the local repository are pushed to the central repository.
Why users prefer Git for version control:
- Commit faster – In SVN, you commit to the central repository more frequently, resulting in slower network traffic, which affects everyone.
- No single point of failure – Each developer has their own repository, meaning if the central repository breaks, it doesn’t really matter, developers can continue to commit code locally until the central repository is fixed where they can then push changes.
- Offline availability – Git works offline, meaning teams can continue working without losing features in the event of connection failure.
The downside? Where developers take extra steps when merging, history logs of each issue can become dense and difficult to understand. This complicates an analysis of the overall system.
Despite this downside, it is evident that Git has surpassed SVN in popularity with many teams now opting to migrate from SVN to Git. Clearvision’s sister company ClearHub have had many requests from organisations over the years asking for assistance from ClearHub’s technically tested contractors to aid them in their migration.
Have you been using SVN, but would like to migrate over to Git? ClearHub contractors can make this happen. Get in touch with them today.