GitHub Flow Way-Of-Work

Created: April 17, 2026

Introduction

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

• GitHub Flow
• Semantic Versioning
• GitVersion — Increment Strategy

The implementation described here is a simplified variant of the GitFlow model. It removes the develop and support branches to streamline the workflow for teams that prefer a single long-lived branch (master / main) as the integration target for all work. All feature and hotfix flows are directed straight to master / main. Versioning is managed automatically through +semver: commit message patterns defined in .cloudopsworks/.gitversion.yaml — there are no manual release branches.

General Rules:

• Direct commits to master / main branch are Not allowed.
• All development starts from master / main — there is no develop branch.
• Feature and hotfix branches both merge back to master / main only.
• Continuous deployment targets (alpha/develop) are not used in this workflow.
• Version increments are driven by +semver: patterns in commit messages — no release branches needed.

The GitHub Flow way-of-work with Tronador Accelerator uses the same two-step publishing model:

1. Flow Creation (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:

• release: Release happens when a version got merged and tagged on master branch, driven by +semver: patterns in commit messages. SemVer have this format vX.X.X
  • Manually
  • Automatic
• test: Test environment deployment is done when a hotfix branch is created or a quick-fix is pushed to the hotfix branch. SemVer have this format: vX.X.X-beta.YY-ZZZZ
• prerelease: Pre Release environment is deployed when a version is tagged from the hotfix branch. SemVer format: vX.X.X-beta.YY

Note: There is no develop (alpha) deployment target in GitHub Flow. Pre-production testing is handled through test and prerelease stages on hotfix branches only.

Preview Environments

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

Version Management

Versions are automatically computed from commit messages using +semver: patterns configured in .cloudopsworks/.gitversion.yaml. No manual release branch creation is needed — simply include the appropriate pattern in your commit message before merging to master / main.

+semver: Commit Message Patterns

Example Commit Messages

feat: add user authentication +semver: minor
fix: resolve null pointer on login +semver: patch
chore: update README +semver: none
refactor!: rework auth module with breaking API changes +semver: major

The +semver: pattern can appear anywhere in the commit message body or subject. The pattern is evaluated when the PR is merged to master / main.

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 (soon)
• Java Template (soon)
• Python Template (soon)
• GoLang Template (soon)
• .Net Template (soon)
• Rust Template (soon)
• XCode Template (soon)
• 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)
   

No initialization step is required. Unlike GitFlow, there is no develop branch to create. Repositories created from the templates above are ready to use immediately.

Feature Branches

Feature branches are created directly from master / main and merged back to master / main via pull request.

Steps:

1. Create the feature branch, feature name must not contain any whitespaces.
   • make gitflow/feature/start-no-develop:<feature-name>
2. Publish the feature branch to GitHub repository, remember that this action must be done while working on the feature branch (it validates this condition). This action can also be used to push all commits on the local branch to the 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 push changes to GitHub.
4. Include the appropriate +semver: pattern in your final commit message to control the version bump on merge (see Version Management).
5. To trigger a preview environment and open the pull request against master / main:
   • make gitflow/feature/finish-no-develop

This process will create a pull request against master / main in order to create the preview environment and to review all changes made. Merging the PR completes the feature and deletes the feature branch.

Additional commands:

• To purge a failed or abandoned feature branch:
  • make gitflow/feature/purge:<feature-name>

Post-Release

Release Tagging

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

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

This qualifier will be used to tag the release, eg: v3.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 and are always created from master / main.

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 done while working on the hotfix branch (it validates this condition). This action can also be used to push all commits on the local branch to the 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 push changes to GitHub. You have to be aware of the following:
   1. Each commit and further push will reach the designated test environment and generate incremental -beta.X versions.
   2. You can perform a Version tagging in order to trigger a deployment into the designated prerelease target. Refer to cloudopsworks-ci.yaml configuration.
5. To close the hotfix and perform the merge into master/main only:
   • make gitflow/hotfix/finish

This process will create a pull request against master / main. If the merge is possible, it will be done automatically; if there are conflicts, they must be resolved within the PR process. The hotfix branch is deleted upon merging.

Additional Commands:

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

Pre Release Tagging

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

• 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