GitFlow Way-Of-Work

Created: March 8, 2026

Introduction

In order to understand the intent of this way of work you can take a look on the following links:

• A successful Git branching model
• GitFlow examples
• GitHub Flow
• Semantic Versioning

The implementation described here is based on a mix of the flows described on these tutorials.

General Rules:

• Direct commits to master / main branch are Not allowed.
• Direct commits to support branches are Not allowed.
• All development starts pushing on develop branch.
• develop branch deploys continuously on the environment configured.

The GitFlow way-of-work with Tronador Accelerator mostly uses a two step publishing steps:

1. Flow Creation (release / tag / hotfix / feature) done locally.
2. Publishing to remote repository (GitHub)

Is at the entire responsibility of the developers to coordinate this way of work related to the flows created, must be done by a designated developer in each case and proceed with the publishing, the rest of the team then can sync up with the remote repository.

Configuration

Configuration of CI/CD is performed through the cloudopsworks-ci.yaml file. The section dedicated to this is under cd.deployments each one of the flows goes to a specific deployment. This configuration may be done mostly by your DevOps/SRE.

Deployments / Effect / Triggers:

• develop: Continuous Deployment: happens on each push to the repository, aka: alpha version. SemVer have this format vX.X.X-alpha.YY
• release: Release happens when a version got merged and tagged on master branch, there are two ways to get this done. SemVer have this format vX.X.X
  • Manually
  • Automatic
• test: Test environment deployment is done when a release branch is created or a quick-fix is pushed to the release branch. SemVer have this format: vX.X.X-beta.YY-ZZZZ
• prerelease: Pre Release environment is deployed when a version is tagged from the release branch. this version tagging has its SemVer with this format: vX.X.X-beta.YY
• support: <TBD>

Preview Environments

• Available only on select Pull Requests
  • From hotfix branches to master / main or support branches
  • From feature branches to develop

Working with code

What is needed

To use the following automated process it is required to use any of the following repository templates:

• NodeJS Template
• Java Template
• Python Template
• GoLang Template
• .Net Template
• Rust Template
• XCode Template
• Terraform IAC Template
• Terragrunt Modular IAC Template

These templates ensure that the proper branch protection gets in place as per the configuration described in previous section.

In the case of using it manually as well from a blank project you can do the following, taking into account that you may not be able to leverage the CI/CD features.

1. Create a file named Makefile
2. Add the following entries to your .gitignore file:
   • tronador/
   • .tronador
3. Paste the following code into the file and you are ready to go:

   TRONADOR_AUTO_INIT := true
   -include $(shell curl -sSL -o .tronador "https://cowk.io/acc"; echo .tronador)
   

Initialization

⚠️ This process is performed one time, at the very beginning after creation of the product repository based on the previous templates.

Initialization or conversion of Project is easy as a straight command, this will create the develop branch based from master / main branch:

• make gitflow/init

Development Branch

Development (develop) is the main code work-in-progress branch. The preferred way is to proceed with Feature branches for each major feature for the next release.

There are no Further steps than pushing commits into the develop branch being respectful of the code of conduct applied for the organization.

Performing pre-release tagging in develop performs tagging on -alpha.X SemVer Pattern.

Pre Release Tagging

These operations are very important to achieve the objective of point 4.b.

• Tag pre-release, this tagging increments properly the beta.1, beta.2, etc. sequence.
  • make gitflow/version/tag
• Tag pre-release with specific deployment qualifier:
  • make gitflow/version/tag:<qualifier>

This qualifier will be used to tag the pre-release, eg: -beta.1+deploy-target1. This will make the build to look-out the configuration on deployment.prerelease.targets entry in the cloudopsworks-ci.yaml configuration file.

• Publish the pre-release independently of the way was created:
  • make gitflow/version/publish

Feature Branches

Feature branch flow is described as below:

Steps:

1. Create the feature branch, feature name must not contain any whitespaces.
   • make gitflow/feature/start:<feature-name>
2. Publish the feature branch to GitHub repository, remember that this action must be doing working on the feature branch (it validates this condition), this action also can be used to push all commits on local branch to remote GitHub repo:
   • make gitflow/feature/publish
   • If you are not on the feature branch and want to push the changes on the feature you can issue the command: make gitflow/feature/publish:<feature-name>
3. Work normally on the Feature locally and can push changes into GitHub.
4. To trigger a preview environment you can go ahead issuing the following command:
   • make gitflow/feature/finish

This process will create a pull request in order to create the preview environment and also to review all changes made and proceed there with the Merging of the PR. This very process will delete the feature branch upon merging into the develop branch.

Additional commands:

• To do the feature merge locally with manual conflict resolve, not recommended for newbies.
  • make gitflow/feature/manual/finish:<feature-name>
• To purge a failed or abandoned feature branch:
  • make gitflow/feature/purge:<feature-name>

Release Management

Releases are divided between Major Releases & Minor Releases.

• Major releases are those that their SemVers are set as v1.0.0, v2.0.0, v3.0.0
• Minor releases are those that their SemVers are set as v1.5.0, v2.3.0, v3.1.0

Releases Flow

1. Creates the release branch, infers the version number from the commit and Git commit tree:
   • make gitflow/release/start Creates a minor release, if you need a major release, proceed at point 1b. If you need to generate a specific version (most cases not needed) you may proceed to point 1c.
   • 1b. Major release: make gitflow/release/start/major
   • 1c. Specific version: make gitflow/release/start:vX.Y.Z (The version should be nominated as indicated here: v<major>.<minor>.<patch>)
2. Publish the release branch to GitHub repository, remember that this action must be doing working on the release branch (it validates this condition), this action also can be used to push all commits on local branch to remote GitHub repo:
   • make gitflow/release/publish
3. Publishing will trigger the build and deployment to the designated environment on the test deployment target in cloudopsworks-ci.yaml.
4. Work normally on the Release locally and can push changes into GitHub. You have to be aware of the following:
   1. Each commit changes and further push will reach designated test environment, and generate incremental -beta.X versions.
   2. You can perform a Version tagging in order to trigger a deployment into designated prerelease target. Refer to cloudopsworks-ci.yaml configuration.
5. To close the release and perform the proper merges into master/main & develop branches:
   • make gitflow/release/finish

This process will create pull requests, one against master / main and the other against develop. If the merge is possible, merging will be done automatically; if there are conflicts, they have to be solved within the PR process. This very process will delete the release branch upon merging into the develop & master / main branches.

Additional Commands:

• To do the release merge locally with manual conflict resolve, not recommended for newbies.
  • make gitflow/release/finish/local
• To purge a failed or abandoned release branch:
  • make gitflow/release/purge:vX.Y.Z

Pre Release Tagging

These operations are very important to achieve the objective of point 4.b.

• Tag pre-release, this tagging increments properly the beta.1, beta.2, etc. sequence.
  • make gitflow/version/tag
• Tag pre-release with specific deployment qualifier:
  • make gitflow/version/tag:<qualifier>

This qualifier will be used to tag the pre-release, eg: -beta.1+deploy-target1. This will make the build to look-out the configuration on deployment.prerelease.targets entry in the cloudopsworks-ci.yaml configuration file.

• Publish the pre-release independently of the way was created:
  • make gitflow/version/publish

Post-Release

Release Tagging

These operations are exclusive for alternate targets for release deployments already done by default release target.

• Tag release with specific deployment qualifier:
  • make gitflow/version/tag:<qualifier>

This qualifier will be used to tag the release, eg: v.3.1.0+deploy-target1. This will make the build to look-out the configuration on deployment.release.targets entry in the cloudopsworks-ci.yaml configuration file.

• Publish the release independently of the way was created:
  • make gitflow/version/publish

Hot-Fix

Hotfix branches are used when you need to do a patch release in the GitFlow workflow and are always created from main branch.

Steps:

1. Creates the hotfix branch, infers the version number from the last commit and Git commit tree:
   • make gitflow/hotfix/start Creates a patch release, if you need a major release this is not the process.
2. Publish the hotfix branch to GitHub repository, remember that this action must be doing working on the hotfix branch (it validates this condition), this action also can be used to push all commits on local branch to remote GitHub repo:
   • make gitflow/hotfix/publish
3. Publishing will trigger the build and deployment to the designated environment on the test deployment target in cloudopsworks-ci.yaml.
4. Work normally on the Hotfix locally and can push changes into GitHub. You have to be aware of the following:
   1. Each commit changes and further push will reach designated test environment, and generate incremental -beta.X versions.
   2. You can perform a Version tagging in order to trigger a deployment into designated prerelease target. Refer to cloudopsworks-ci.yaml configuration.
5. To close the hotfix and perform the proper merges into master/main & develop branches:
   • make gitflow/hotfix/finish

This process will create pull requests, one against master / main and the other against develop. If the merge is possible, merging will be done automatically; if there are conflicts, they have to be solved within the PR process. This very process will delete the hotfix branch upon merging into the develop & master / main branches.

Additional Commands:

• To do the hotfix merge locally with manual conflict resolve, not recommended for newbies.
  • make gitflow/hotfix/finish/local