Source Control – More than just a repository

Written by Fredrik Erasmus, Senior Developer at Saratoga

I find keeping a repository even for very small projects incredibly useful. In fact these days I hardly start a project without creating a code repository first. You just never know where you might need the code again. As a Software Developer who has worked on numerous client projects over the years, I find myself initializing a new git repository almost by habit when creating a new folder for a new project.

Code Repository Benefits

Having a git-based code repository for a project is very useful as you can create branches of work against the repository, and you can commit or revert changes as you choose by creating branches locally.

If you go too far with a feature you can easily revert to a previous version, or in git terms stash it. Ideally, I would suggest that you host your code in a remote repository, as a remote repository would provide more than just a way to keep your code safe.  

Remote Repositories

It’s worth noting that the git version control system has become the de facto standard. The version control system Subversion (SVN) is still in use by many teams. Mercurial was until recently still supported by BitBucket. BitBucket, however, discontinued support for Mercurial in favour of git. Cloud-hosted git providers such as GitHub, Azure Devops, BitBucket, AWS CodeCommit, Google Cloud Repositories and GitLab mostly use the git version control system.

Cloud-hosted git repositories are great for team collaboration. Why? Because they provide so much more than just a place to keep your code. Azure Devops, for instance also provides integrated project management (think Agile) support through Azure Boards. Whereas GitHub provides projects as a way to track work.

GitHub as a Repository

It’s important to recognise the integration of your code repository with the project management tools provided by Azure Devops and GitHub. Your team typically creates user stories with tasks or features using Azure Devops Boards, for instance. The stories (features) are then displayed on a project board. The team then performs work against a task or a feature. The work may involve writing code by a developer for example. In the case of a developer they would typically start the development of a task or feature by creating a git branch in their local environment. Work will be done on the feature or task with regular commits on a local branch. When the developer is finished with the work they will push the local branch to the remote repository.

All the details of the commits are then tracked against the project item. Azure Devops, for instance, shows the commit details against a feature or task. In my mind the project item is no longer just a ‘sticky’ (using Agile terms) to track progress but also a valuable source of information. It promotes transparency. Non-technical stakeholders can sign-in to Azure Devops, for instance, to look at a project’s progress.

In many environments developers will create pull requests from the branches they pushed. A pull request is a great opportunity to collaborate – reviewing code. Both Azure Devops and GitHub provide great support for reviewing code from pull requests, and reviewing code is a great team collaboration mechanism. Teams should regularly perform code reviews as it improves the quality of a project immeasurably. It also helps build trust within a team.

Project and Deployment Benefits

An approved pull request will merge code into a main branch such as master or development. If configured, the merge will trigger a CI/CD pipeline. CI/CD pipelines delivers updates to your project without any human intervention – continuously. With the deployment process being automated the quality of your project increases because it happens after every merge of a pull request. Features can be tested quicker, and feedback from testers (QA) can be received sooner and bugs reported timeously – ultimately enabling developers to fix the bugs quicker.

Source control, therefore, must be seen as more than just keeping your code in a repository. Your source control strategy should ideally provide a collaborative experience for your team. It should also provide a way to speed up the iterations to your project through constant integration using CI/CD pipelines.