Coding Practices & Guidelines - StoryTime-Productions/Stweaks GitHub Wiki

🟦 Git Flow Workflow

Git Flow is a branching model that helps teams manage features, releases, and hotfixes in a structured way. It is especially useful for projects with scheduled release cycles.

Key Branches:

  • main: Stores the official release history.
  • develop: Integration branch for features; contains the complete development history.
  • feature/*: Used for developing new features; branched from develop.
  • release/*: Used for release preparation; branched from develop, merged into both main and develop when finished.
  • hotfix/*: Used for quick fixes to production; branched from main, merged into both main and develop.

Typical Workflow:

  1. Create a develop branch from main.
  2. Create feature/* branches from develop for new features.
  3. Merge completed features back into develop.
  4. Create release/* branches from develop for release preparation.
  5. Merge finished releases into both main and develop.
  6. Create hotfix/* branches from main for urgent fixes, then merge into both main and develop.

Additional Resources:

🟩 80% Coverage Requirement

All code submitted to the repository must be accompanied by automated tests that achieve at least 80% code coverage. This means that at least 80% of the lines, branches, or statements in the codebase must be exercised by tests before a pull request can be merged.

Purpose:

  • Ensures code reliability and maintainability.
  • Reduces the risk of undetected bugs.
  • Encourages writing tests alongside new features and bug fixes.

How to Check:

  • Use the JaCoCo tool.
  • Coverage reports will also be generated and reviewed as part of the CI pipeline.

Additional Resources:

🟨 Semantic Commit Conventions

All commit messages must follow the semantic commit message format, based on the Conventional Commits specification.

Format:

[optional scope]:

text

  • <type>: Describes the kind of change (see below).
  • [optional scope]: The section or module affected (optional).
  • <description>: Short summary in the present tense.

Examples:

  • feat(login): add OAuth2 login support
  • fix(api): handle null pointer exception
  • docs: update README installation section
  • refactor(core): simplify data processing logic
  • test: add coverage for edge cases in parser
  • chore: update dependencies

Allowed Types:

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation only changes
  • style: Formatting, missing semi colons, etc; no code change
  • refactor: Code change that neither fixes a bug nor adds a feature
  • test: Adding or refactoring tests; no production code change
  • chore: Changes to the build process or auxiliary tools

Benefits:

  • Improves readability and traceability of changes.
  • Enables automated changelog generation and versioning.
  • Helps reviewers quickly understand the intent of each commit.

Additional Resources:

⚠️ **GitHub.com Fallback** ⚠️