Commit Loss During Squash Merge Causes Version Increment Failures

[sergiotejon]

Description: The current version file (version.json) is structured as follows:

{
  "version": "0.5.0",
  "commit": "76ada272285ea6a513c80bce7fa280af8d06f34a",
  "prefix": "my_prj",
  "version_files": [
    "mi_file.yaml:version"
  ]
}

The commit field represents the commit hash used by the repository's application (Gommitizen) to track changes and determine version increments. However, an issue arises when using this file in a feature branch later merged into the main branch using a squash merge strategy.

Since squash merges and condenses all commits into a single commit, the commit hash stored in the version.json file no longer exists after the merge. As a result, the application fails to locate the commit and properly determine version increments.

Proposed Solution:

• To avoid issues with lost commits, avoid using gommitizen in branches that are intended for squash merges.
• Alternatively, we could specify a branch in the version.json file (e.g., main) where the commit field is always tracked and squash merges are not allowed.

This would ensure that version control mechanisms are based only on commits that are preserved in the repository.

Impact:

• Squash merging could break version increment processes, causing potential failures in automated pipelines or deployments.
• Limiting the use of squash merges on certain branches could maintain the integrity of version tracking.