Commit Types.md (To be rewritten)

Commit Types.md

Commit Conventions

This document outlines standardized commit types for all repositories, along with extended types for script/tool-focused repos. The goal is to provide a clear, maintainable commit history, aid in automated changelog generation, and guide semantic versioning decisions. Use these conventions for consistent communication and streamlined project management.

Core Commit Types

The following commit types are commonly used across various projects, and form the base set that contributors should be familiar with. They remain applicable regardless of whether you’re working in a general codebase or a specialized script repository.

Commit Type	Title	Description	Release	Include in changelog
feat	Feature Addition	Introduces a new capability or feature to the project. Affects end-users by enabling new use cases or expanding the application’s functionality.	minor	true
fix	Bug Fixes	Addresses bugs that impair the intended functionality. Ensures existing features work as expected.	patch	true
docs	Documentation	Updates or improvements to documentation. Includes README updates, usage guides, or additional instructions.	-	true
style	Style Adjustments	Non-functional changes related to formatting, code style, or aesthetics. Does not affect behavior or output.	-	false
refactor	Code Refactoring	Changes to the code structure or internal logic without altering external behavior. Improves maintainability or clarity.	-	true
perf	Performance Improvements	Optimizations that enhance speed, efficiency, or resource usage without altering functionality.	patch	true
test	Testing Enhancements	Adds or improves test cases, test scripts, or testing frameworks to ensure code reliability and stability.	-	true
build	Build System Updates	Modifications to build tooling, dependencies, or automation processes that are used to package, deploy, or compile the code.	patch	true
ci	Continuous Integration Changes	Changes to CI/CD configuration or pipelines for integrating, testing, and deploying code.	-	true
chore	Maintenance	Routine tasks that don’t directly affect functionality (e.g., dependency updates, cleanup tasks, housekeeping).	-	false
revert	Reverts	Reverses a previous commit, typically to rollback changes that introduced issues. Version implications depend on what’s being reverted.	-	true

Extended (Script/Tool-Specific) Commit Types

These additional commit types apply to repositories containing standalone scripts or tools—often each with its own versioning and lifecycle—or integrated tool suites that evolve together. They help clarify the nature of changes in tool-centric contexts.

Commit Type	Title	Description	Release Guidance	Include in changelog
func	Functionality Extension	Enhances an existing tool’s capabilities without introducing an entirely new feature. These changes often deepen existing functionality and are typically backward-compatible, resulting in a patch or minor release for that specific tool.	patch or minor (depending on scope)	true
security	Security Enhancements	Implements security fixes or improvements for a specific tool. Usually treated as a patch if fixing a vulnerability, though it can be minor if it introduces a new security-related feature.	patch or minor	true
tool	New Tool Introduction	Introduces a completely new script or standalone tool. For repositories of independently versioned scripts: Start the new tool’s lifecycle at v1.0.0 once it’s stable. If it’s a work-in-progress (WIP) or pre-release, begin at 0.x.x until it’s ready for v1.0.0. Note that this does not affect other tools unless they depend on this new one. For integrated projects: If adding a new tool is backward-compatible and non-disruptive, treat it as a minor addition. If it breaks workflows, changes configurations, or alters user expectations for the entire suite, treat it as a major release for that project.	- Standalone script (Stable): v1.0.0 (major, as the start of its lifecycle). - Standalone script (WIP): Use 0.x.x until stable. - Integrated project (non-breaking): Minor release for the suite. - Integrated project (breaking): Major release for the suite.	true

Additional Notes

• Scopes: If needed, use scopes (e.g., feat(tool-name): ...) to clarify which tool is affected.
• Incremental Changes After Introduction: Once a tool is introduced, incremental improvements or fixes to it should use existing types (fix, perf, func, etc.) that reflect the nature of the change.
• Pre-Releases and Stability: For standalone tools in a scripts-only repository, don’t hesitate to use pre-release versions (0.x.x) for WIPs. Move to v1.0.0 only when the tool reaches a stable, feature-complete state.
• Documentation: Reference these commit types and rules in your CONTRIBUTING.md or development wiki. Consistent usage will improve transparency and the quality of your project’s version history.