(PART*) The Principles {-}

Use Version Control {#version_control}

(ref:versioncontrol-intro)

You Must - (ref:versioncontrol-must)

You Should - (ref:versioncontrol-should)

You Could - (ref:versioncontrol-could)

|Related Areas: | Demonstrably Correct,
Be Reproducible | |--------------- |------------------------------------------------------------|

What is version control? {#what_is_vc}

Version control is managing changes to the documents and files which make up your work. This typically includes a system for identifying versions (i.e. a version number or name) and some sort of log of what the changes are, who made them and when they were made. Version control systems are usually associated with tools for comparing, restoring and merging versions.

Git - (program for version control) {#git}

Git is the most popular way to version control code. You can tell Git to keep track of a folder full of code (a repository or 'repo'). As you make changes, Git identifies them and asks which should be kept (or 'committed'), and for a comment identifying why. It uses this to maintain a log of all the changes. This log can be used to restore old versions.

GitHub - (service for storing code version controlled using git) {#github}

GitHub is the most popular place to store git repositories. Storing your repository on GitHub has some key benefits:

As such, using a service like GitHub is a good way to ensure that your code is available to your team, and that knowledge is transferred.

Using Git & GitHub Effectively {#effective_vc}

To make effective use of Git and GitHub:

Version Control Workflow {#workflow_vc}

Define a version control workflow which explains how you use git as a team. This could include how you use branches, how you merge changes and how to handle pull requests.

Code in the Open

GitHub repositories can be open (shared with anyone) or private (shared only with selected collaborators).

The Technology Code of Practice encourages us to 'be open and use open source'. As such, code should be open unless there is a good reason for it not to be.

Good reasons for code to be private might be that it includes classified material, or information on an unreleased policy. GDS have published guidance on this for both external, and internal use.

Manual Version Control

It is possible to manually keep track of your code by systematically keeping copies of your code as you modify it and maintaining a corresponding log of all changes to the code. The log should include: What has changed, why, and a link to the relevant copy of the files. It is recommended to use version control tools (git) instead of this manual process.

Git & GitHub at DHSC

At present, DHSC base machines do not have git. If you have access to a developer account you can install git for windows from: git-scm.com It is anticipated that in the near future TAP (The Analytical Platform) will provide git functionality for all analysts within the department.



DataS-DHSC/coding_principles_book documentation built on March 11, 2020, 4:13 a.m.