GitFlow and semantic versioning

GitFlow is a strategy for keeping a repository organised, clean, and coordinating risk-free release cycles as the size of the developer team grows.

GitFlow and its conventions

Master, dev, feature, hotfix and branch defined with different and shared meanings within the software life cycle and the development and workflow of the team.

Vincent Driessen theorised GitFlow to make the most of Git's potential and define a shared branching model that would facilitate collaboration within a team. GitFlow provides for the presence of two master branches, "dev" (or "develop") used for development and "master" for official releases. These two branches are the reference for the 'history' of the project and keep it clean and legible by excluding the development of new features and hotfixes (corrections on the version under production), which would otherwise flow into the main branch without filters, making the history of the project difficult to understand and reversions to previous states more complex. At ELbuild, we use GitFlow for all development projects, regardless of team size; however, the benefits become apparent when the team reaches 5 or 6 developers.

Semantic versioning

x.y.z, how three simple numbers can help solve conflicts and problems of backwards compatibility and dependencies

Semantic versioning is a software release numbering convention based on three integers: major, minor and patch. A release name is obtained by chaining these three numbers together using dot notation. For example: 2.3.4, indicates major version: 2, minor version: 3 and patch: 4. There are precise rules on whether or not the versions are backwards compatible, depending on the variation of one of the numbers, and this leads to clear benefits in determining release strategies. Semantic versioning is also part of the shared conventions, now a component of the development best practices that we adopt for both internal and customer projects.

The importance of shared methodologies and conventions

We have experienced the advantage of having a shared methodology and conventions for ourselves, and we can offer you advice to convey the same benefits to your team.

At ELbuild, we very often offer consulting services to companies equipped with their own development teams, both regarding issues of technology transition (for example, migrating skills and human resources from one stack to another) and the establishment of a shared methodology and a series of best practices aimed at increasing the quality of a development team's work. This consultancy service is essential in the case of startups that decide to invest in an internal team at a later stage, after the product has been launched, to carry out the project independently.