Reasons to use a Code Version Control system such as GIT

18th August 2021

Reasons to use a Code Version Control system such as GIT

There are many good reasons for using a code versioning and control system such as GIT for any project you work on.

  • Transparency – sharing code via a repo is a great way to show others what you’re working on and demonstrate progress.
  • Collaboration – it’s great at supporting collaboration, different developers can work on different features, each on their own branches, and easily link to other pieces of code.
  • Code Reviews / Peer Programming – it supports reviews of code and peer review, particularly if you set appropriate branching and merging strategies. It drives people to review and sign off code, which fits well with the sort of active collaboration we’re aiming for.
  • Easy to revert / recover previous versions – if you make a mistake or need to backtrack it’s very easy to revert to previous versions or step through changes to identify the errors.
  • Easily Review Changes – you can view code side by side, with the changes between different versions highlighted.
  • Encourages documentation with the code – through readme files and commit messages which if done correctly can help demonstrate your development journey and help identify changes that introduced errors.
  • Different versions, i.e production & development – you can maintain a deployed or production branch, whilst also developing new features or improvements.
  • Code protection / backup – the code is securely stored, and backed up, so if you accidently delete something you’ll be able to recover it, and if you face system issues, your valuable code will remain safe.
  • Promotes organisation, and documents development progress – thinking about how you set up the repo, document the code, and comment on the commits helps to drive good organisation leading to a cleaner development journey.
  • Provides some level of governance, control, and audit - it’s easy to demonstrate what people are working on, who has made changes and why.

There are many different choices when it comes to GIT repos, you could simly use GIT on your local machine, but in a team setting it makes much more sense to use a remote repository, on an online platform.

I’m currently using Azure DevOps which integrates well with Azure and provides all sorts of DevOps functionality such as CI/CD pipelines, but I other options include BitBucket, GitLab or probably the most well-known, GitHub.

Most modern IDEs and code editors will integrate with GIT Repos seamlessly, for example I most often use RStudio and VSCode both of which make using GIT very easy. I’d certainly recommend VS Code in particular, as an incredibly versatile code editor which is modular such that there is a marketplace full of extensions to provide all sorts of additional functionality.

Using an editor that implements version control makes it particularly easy to use GIT as part of your normal development routine.

Once you’re using GIT, you need to start to think about your ways of working – how exactly will your team organise its development work? Part of this would likely involve the implementation of a branching strategy, I’d recommend GitFlow and GitHub Flow as two solid options, with GitHub Flow being slightly simpler, but fine for smaller projects.

The real power of using a remote GIT Repository comes with the ability to integrate CI/CD pipelines, which allow you to automate the build and deployment of your code, incorporating many useful automations.

For example, you could trigger your pipeline on a merge into the main branch to lint your code, test all components, build your solution and deploy it to a test environment, before waiting for authorisation to promote further. I’ll no doubt be writing more about this in due course.

There is a lot of functionality to GIT and plenty of shortcuts to learn, but you can start as simply as you wish. A good resource is the GIT Cheat Sheet linked here.