Skip to content

Latest commit

 

History

History
50 lines (37 loc) · 2.46 KB

CONTRIBUTING.md

File metadata and controls

50 lines (37 loc) · 2.46 KB

Contributing to GitHub Rulesets

As a solo developer, I maintain strict development practices to ensure code quality and maintainability. This guide outlines the processes I follow for development.

Branching Strategy

I follow a strict Gitflow workflow to maintain a clean and organized codebase:

  • main: Core branch with the latest shippable ruleset configurations. This branch is protected and receives merges from develop.
  • develop: Integration branch for ongoing development of new rulesets or updates. This branch maintains linear history.
  • feature/*: Branches for developing new ruleset capabilities. Create from develop and squash-merge back to develop.
  • fix/*: Branches for bug fixes or ruleset improvements. Create from develop and squash-merge back to develop.
  • release/*: Branches for preparing a new version. Create from develop and merge into both develop and main.

Commit Guidelines

  • Signed Commits: All commits must be signed using git commit -s or git commit --signoff.
  • Linear History:
    • develop branch: Maintains linear history through squash merges from feature branches.
    • main branch: Receives regular merges from develop, creating non-linear history.
  • Merge Strategy:
    • Feature branches → develop: Squash and merge
    • develop → main: Regular merge (not squashed)
  • Commit Messages: Write clear, concise commit messages that describe what was changed and why.
  • Tagging: Create tags on the main branch to mark official releases. Tags should point to the merge commit from develop to main.

Development Process

  1. Create a feature or fix branch from develop.
  2. Make changes and test thoroughly.
  3. Rebase onto the latest develop to resolve conflicts.
  4. Squash commits into meaningful units.
  5. Squash-merge back to develop via a pull request.
  6. When ready for release:
    • Create a release/* branch from develop
    • Make any final release preparations
    • Squash-merge the release/* branch back to develop
    • Then merge develop to main (regular merge, not squashed)
    • Create a tag on the main branch at the merge commit to mark the official release

Issue Tracking

I use GitHub issues to track tasks. Issue templates are available:

Development Setup

See the README.md for setup instructions.