DEV Community

Cover image for Guiding sprints with Gitflow ✨🔨
Fabrício Santos
Fabrício Santos

Posted on

Guiding sprints with Gitflow ✨🔨

Git has become the heart of our code, hasn't it? And since it serves as the core of our daily lives as developers, why not combine it with one of the best methodologies? Allow me to introduce Gitflow with sprint as a methodology.

A little history before. Created by Vincent Driessen, Gitflow was primarily designed for continuous delivery project models. It prioritizes the delivery of new "features" and project maintenance "on deploy."

The sprints, pioneered by Jeff Sutherland and his team at Easel Corporation in the early 1990s, are Agile development cycles lasting 1-4 weeks. They emphasize iterative planning, execution, and review, fostering rapid and adaptable project advancement.Then lean features being delivered time by time.

So, how does Gitflow work?

You might have faced this scenario: making changes, merging, updating the server, and encountering application issues. Gitflow addresses this by providing a structured model:

This model has five key branches:

Gitflow workflow. Atlassian solutions. All directs reserved

Main (Master):
The stable production version. Changes are merged here after thorough testing.
Hotfix:
Urgent fixes to Main for critical production issues.
Release:
Stable version preparation for deployment, ensuring tested code.
Develop:
Integration branch for ongoing development, testing changes together.
Feature:
Branch for specific functionality or improvement development.

Now that we know how to use Gitflow,

How can we improve our workflow?


The big question is, how did I apply Gitflow and improve the team's development flow?

To implement Gitflow, I personally use it in conjunction with sprint planning.

First, we need a structured backlog and sprints. Before organizing our code, we need to know what needs to be done and when it needs to be done.

Once we have aligned our backlog and appropriately separated our sprints, we can move on to the practical aspect of branch creation. Each separate functionality in the sprint will have its own feature branch, following naming conventions set by the team.

Once a feature is complete a PR (Pull Request) will be sent to development branch, then it needs pass testing, including unit tests and QA tests. Once the feature is validated, it waits for the sprint review to be mergeded into the Release branch.

With the sprint review validation complete, all features at release branch receive permission to be launched into the Main branch.

Maintaining stability in our project mandates preserving a stable version pre-Main branch merge. Prior to merging into Main, safeguarding the version in a separate branch is imperative for security.

Once features are successfully merged, we meticulously monitor deployments for inconsistencies. If corrections are needed, they are expertly implemented via a hotfix branch, subsequently merged into Main.

I hope this way of working with agile development and code flow would help your team develop better features.😁

References

Top comments (0)