GitHub Rulesets

This repository contains GitHub rulesets configurations for managing branch protection and repository policies. As a collection of ruleset templates, I maintain strict development practices to ensure these configurations remain reliable and up-to-date.

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, make release changes, then squash-merge into develop. Finally merge develop to main for release.

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

Included Rulesets

main.json

Ruleset for the main branch with the following rules:

• Deletion: Prevents deletion of the branch
• Non-fast-forward: Requires linear history (no force pushes)
• Required Signatures: All commits must be signed
• Pull Request: Requires 1 approving review, allows squash merges only
• Required Linear History: Enforces linear commit history

develop.json

Ruleset for the develop branch with identical rules to main.json:

• Deletion: Prevents deletion of the branch
• Non-fast-forward: Requires linear history (no force pushes)
• Required Signatures: All commits must be signed
• Pull Request: Requires 1 approving review, allows squash merges only
• Required Linear History: Enforces linear commit history

Repository Settings

This repository has the following additional settings enabled:

• Require contributors to sign off on web-based commits: Contributors must sign off on commits made through GitHub's web interface, affirming compliance with the Developer Certificate of Origin (DCO).

• Issues: Lightweight task tracking is enabled with issue labels and milestones.

• Allow squash merging: Pull requests can be merged by combining all commits into a single commit.

• Default commit message: A default message is presented when merging pull requests with squash.

• Always suggest updating pull request branches: When new changes are available in the base branch, an "update branch" option is presented.

• Automatically delete head branches: Merged pull request branches are automatically deleted (but can be restored).

• Auto-close issues with merged linked pull requests: Issues are automatically closed when their linked pull requests are merged.

Usage

These ruleset configurations can be used as templates or examples for your own repositories. To apply them:

1. Copy the JSON content from the appropriate file
2. Go to your repository's Settings > Rules > Rulesets
3. Create a new ruleset and paste the JSON configuration
4. Adjust the source field to match your repository
5. Customize rules as needed for your workflow

Issue Tracking

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

• Bug Report
• Feature Request

Contributing

See CONTRIBUTING.md for detailed contribution guidelines.

License

This project is licensed under the MIT License - see the LICENSE file for details.