Version Control

GitFlow & Semantic Versioning

In this article, I want to share Version control, History of Version Control, Semantic Version, and Gitflow.

What is Version Control?

A version control system saves to change files within the system. This can be source code that may be part of a software development project. Developers make changes to source code, in other words, we call it ‘commit’. We see who made the change, when, and what kind of change that make. A Software team uses a version control for system configuration, application configuration, and building and They can easily switch to previous versions of the code in the production environment which reduces the risk.

A Software engineering team uses a version control for system configuration, application configuration, and build. We can test code changes without changing the main project with a version control system. Don’t forget that, A strong version control system ensures optimum success.

History of Version Control

There are many version control systems tools but have you ever wondered how these tools came to be?

In 2000, The major version control system was Subversion, which was created by CollabNet. Subversion is an example of a centralized version control system (CVCS). Changes can be made to a single copy of the main project on a server, developers can pull the latest version of the code to make edits.

In 2005, Distributed version control system (DVCS) was created by Linus Torvalds. Git is a distributed version control software it’s solved many problems. Developers create a multi-branch(feature branch). Git does merge very fast because it only keeps the change.

Why Is Versioning Important?

We know that the software engineering team can easily manage their project with git. They create a feature branch from the master branch and make modifications as a result, the code has to be matched with a version. At this point, the concept of a single source of truth enters their lives.

What is the single source of truth?

Single source of truth(SSOT) is a concept. In information systems, Data should be in one place, everyone should take this data from there all the time, it must be modified in one place.

As data grows, dependencies will increase. When dependencies increase, it becomes difficult to manage the process but there is a simple solution for this. Versioning…

Semantic Versioning

Versioning is a crucial concept all development teams should take care of. We prefer to use semantic versioning for giving versions to release and hotfix branches in our projects. Of course, you can use different versioning systems for each project so the rules will be different.

Semantic Versioning is a three-component number in the format of X.Y.Z. Each version contains three version numbers. Major-Minor-Patch

Major: code is incompatible or contains a significant change

Minor: code has been changed but the changes are backward compatible

Patch: bug fixes have been made

You can find detailed information about semver.. link

When development teams combine versioning with a branching strategy, it provides great benefits in their work. Branching strategies coordinate work to allow easier integration of changes. As there are different branching strategies you may consider I’ll explain how git-flow works and fits with semantic versioning

Branching Strategy: GitFlow — WorkFlow

• Code is deployable at all times.
• When you want to start working on a new task, create a new branch and give it a descriptive name.
• Open a pull request when your changes are ready to be merged.
• After the new feature is approved, you can merge it.
• When your changes are merged, you can deploy them immediately.

Release Management has been done by using GitFlow Methodology. Every environment has its own “branch” and application owners should deploy their repositories on those branches.

Master: This branch is the main representation of the repository.

The master branch at origin should always reflect a production-ready state.

Develop: The source code in dev always mirrors a state with the latest development for the next release. Code is merged into dev from feature branches after code reviews happen. All code that reaches the dev branch should be in a stable state.

Feature: Branched from Develop. Allow developers to work on a specific feature.

Hotfix: Hotfix Branch is for emergency deployments for those issues, which are encountered in the Prod environment. As this creates a backdoor for our structure, we recommend not using it except in exceptional circumstances.

Release: Branched from Develop. It is deployed on Preproduction Environment. Minor bugs can be resolved directly.

Main Git-Flow rules to follow:

Never make commits to the master branch

One task, one feature branch

Every pull request must be tested before merging into the develop branch

New Functions must be added only to the develop branch

Semantic Versioning

How to Implement the Source Control Management and Semantic Versioning ?

There are some source control management tool. We manage our projects with SCM.

• Each service or application has a separate project in SCM.
• We store source code, configuration files and data scripts in bitbucket
• We support controlled gitflow.
• We improve the custom tool for bitbucket which is supported tagged versions. When Developers open a peer review(pull request), They must write MAJOR-MINOR-PATCH in the detail field as a result, a version is generated.
• We support easy creation and destroy brances.
• Code Review: we allow to review code for other developers.

I want to explain git-flow and versioning with an example scenario.

ForExample: At some point of time 2 new requirements has arrived that is two (minor) request. Our production version is 3.4.0

Developers will have the “Master”, “Release” and “Develop” branches by default. It is expected of developers to create a “Feature” branch for each task they work on. Feature branch will be created from Develop branch.

The Master branch has a “3.4.0” version. Release branch has “3.4.0 beta-2” and Develop branch has “3.4.0-alpha-3”.

Feature-1 is ready to merge the development branch. When the developer merged into the development environment, the “3.5.0-alpha-1” version is generated.

Feature 2 is ready to merge the develop branch, When the developer merged into the develop environment, the “3.5.0-alpha-2” version is generated.

Changes are ready to promote test environments and generate the “3.5.0-beta-1” version in the release environment.

Let’s assume that there is an emergency hotfix problem right now. Hotfix branch will be created from the Master branch. The error is fixed and merged into the development environment and generated “3.5.0-alpha.3” then merged into the release branch and generated “3.5.0-beta-2” then merged into the master branch or production environment and generated “3.4.1” version.

As a result, Both feature-1 and feature-2 business requests are completed and these improvements are ready for the production environment. When the developer merged into the master environment, the “3.5.0” version is generated and the process is completed.

I hope, this article is helpful and explanatory for you.

Thank you.