GitFlow

Owned by DevPortal Editor (Unlicensed)
Last updated: 21/06/23 by Onesait Platform
3 min read

In the Platform, we use GitLab as a code repository and GitFlow as a methodology or workflow, following this branch scheme:

  • master: Stable code branch. From this branch, the stable release branches are generated within the quarter.

  • develop: Branch of new features programmed within the Q, according to the product roadmap. This branch merges to master, once stabilized and tested and once the Q is over.

  • stable (release candidate): Branch generated from master, intended for bug fixes and improvements. This branch is deployed weekly in the stable environment and merges both to master and to develop.

Each new functionality, bug correction or improvement is associated with the corresponding Issue in GitLab, labeled as FEATURE, BUG or UPTURN.

The issue is associated with a development branch and a brief description:

Besides, the issue must be associated with the corresponding milestone (weekly if it is a release candidate or RC) or quarterly if it is intended to the Q's end.

Once the development is finished, a pull request or request is generated to merge the branch to develop or to the stable branch. Tor this purpose, the corresponding request is created from GitLab

We will mark the check to delete the origin branch once merged:

and it is assigned to a team member, usually a senior one.

Once the issue has been tested and validated in the corresponding environment, it must be changed to state: closed: