Each development project, as well as collaborators team, is different. The needs for deliveries and reviews are different. But there is something that is required in any case: the need to keep everything organized and versioned, without this hindering the quality of the project or the agility of the team. At this point I would like to introduce some Git work strategies that can help teams.
Before going into further detail, we should understand that code versioning systems in general allow to:
As we can see, they are fundamental in the development process.
As I already mentioned, today we will focus on Git. This powerful code versioning engine is so flexible that it allows us to choose different work flows or strategies, choose the one that best suits the needs to be covered, and even build our own strategy.
The needs of the project that we are addressing with our team and our experience will allow us to choose some of the strategies that I will mention below.
It is a flow designed for those projects that have deliverables and well-defined development cycles. It is based on two large branches with an infinite lifetime (main and develop branches) and several support branches, some aimed at developing new features, others at hotfixing and others aimed at preparing new releases.
It is the way of working suggested by GitHub's own functionalities. It is focused on an iterative development and constant deployment model.
For a detailed explanation you can visit the following link on GitHub.
To provide more control, GitLab Flow adds more branches to the previous strategy. We can have branches by environments, QA, Production and by Release (version).
In this flow, each new production version is based on the previous production version. The biggest difference between One Flow and Git Flow is that the former has no development branch.
Here the objective is to carry out short, continuous, functional commits avoiding conflicts due to large mergers and always having a version ready to be published. This strategy is the most recommended for teams implementing DevOps.
I would like to conclude by highlighting that Git is a very powerful tool for our daily collaborative work. And that code versioning allows not only versioning applications source code, but also infrastructure. This turns it into the core of agile teams implementing DevOps in their projects and in the culture of their organization.
If you prefer a video, here is a link to a webinar I made on the topic: Workflows / Strategies for working with Git