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:

• Take versions of each change we make to our code
• Share this code and versions with our team
• Mix changes
• Review changes
• Get a copy of a specific version
• Undo changes
• Label
• Etc.

Characteristics

• Some are centralized (svn, cvs, etc)
• Others are of the distributed type (Git, Mercurial, etc)

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.

Git Flow

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.

GitHub Flow

It is the way of working suggested by GitHub's own functionalities. It is focused on an iterative development and constant deployment model.

• Everything in the main branch is ready to go into production.
• To work on something new, a new branch must be created from the main branch, with a descriptive name. The work will be integrated on that branch locally and, regularly, also on that branch on the server.
• When help or information is needed or when the branch is ready to be integrated into the main branch, a pull request (change integration request) should be opened.
• The project manager must review and approve the changes to merge them with the main branch.
• Integrated changes can be put into production.

For a detailed explanation you can visit the following link on GitHub.

Gitlab Flow

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).

One Flow

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.

Trunk Based Development

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.

Conclusion

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