2.1.3. Commit Types¶
PyPackIT categorizes each commit in your repository into one of the following five types:
2.1.3.1. Primary Types¶
Primary commit types only exist on release branches, and are automatically generated by PyPackIT when changes applied to a development branch are merged into a release branch. These are further divided into two categories, primary action commits, and primary custom commits.
2.1.3.1.1. Primary Action Types¶
Primary action commits signify a primary action that is to be performed by PyPackIT when changes are applied to a release branch. These actions are:
Package release: Publish a new release of the package. This action is further categorized into:
Major release: Publish a new major release.
Minor release: Publish a new minor release.
Patch release: Publish a new patch release.
Post release: Publish a new post release.
Website release: Publish a new release of the website.
Meta update: Update the meta content of the release branch, and apply the changes to the entire branch, or the entire repository, when the target is the default branch.
2.1.3.1.2. Primary Custom Types¶
Primary custom commits are additional user-specified primary commits that only exist on release branches, but do not induce any action by PyPackIT, other than the default workflow actions that are always applied, e.g., linting, testing etc.
2.1.3.2. Secondary Types¶
Secondary commit types are divided into two categories, secondary action commits, and secondary custom commits.
2.1.3.2.1. Secondary Action Types¶
Secondary action commits signify a secondary action that is to be performed by PyPackIT, when changes are applied to a branch. These actions are:
Meta sync: Synchronize all dynamic files and directories in the branch with its updated meta content.
Hook fix: Apply pre-commit hooks to the branch, and fix any issues that are found.
2.1.3.2.2. Secondary Custom Types¶
Secondary custom commits only exist on development branches and pre-release branches. The user can specify any number of secondary custom commit types, and link each of them to a specific section of a specific changelog file. When the branch is merged into a release branch, the corresponding changelogs will be automatically updated using the commit messages of the secondary custom commits.