@@ -10,53 +10,95 @@ We love your input! We want to make contributing to Helm Values Manager as easy
1010
1111## Development Process
1212
13- We use GitHub to host code, to track issues and feature requests, as well as accept pull requests.
14-
15- 1 . Fork the repo and create your branch from ` main ` .
16- 2 . If you've added code that should be tested, add tests.
17- 3 . If you've changed APIs, update the documentation.
18- 4 . Ensure the test suite passes.
19- 5 . Make sure your code passes all code quality checks.
20- 6 . Issue that pull request!
13+ Before starting work:
14+ 1 . Check if a GitHub issue exists for your feature/bug
15+ - If not, create a new issue using the appropriate template:
16+ - Bug Report: For reporting bugs
17+ - Feature Request: For proposing new features
18+ - Documentation: For documentation improvements
19+ - If yes, comment on the issue to let others know you're working on it
20+
21+ For contributors with write access:
22+ 1 . Create a new branch from ` main ` using the issue number (see Branch Naming below)
23+ 2 . Make your changes following our development guidelines
24+ 3 . Create a pull request
25+
26+ For contributors without write access:
27+ 1 . Fork the repository
28+ 2 . Create a new branch in your fork
29+ - We recommend creating a branch even in your fork to:
30+ - Keep your fork's main branch clean and in sync with upstream
31+ - Work on multiple issues simultaneously
32+ - Make PR feedback changes easier
33+ 3 . Make your changes in the branch
34+ 4 . Create a pull request from your fork's branch to our main repository
35+
36+ For all contributors:
37+ 1 . If you've added code that should be tested, add tests
38+ 2 . If you've changed APIs, update the documentation
39+ 3 . Ensure the test suite passes
40+ 4 . Make sure your code passes all code quality checks
2141
2242## Version Control Guidelines
2343
24- ### Branch Naming
25- - Feature branches: ` feature/short-description `
26- - Bug fixes: ` fix/issue-description `
27- - Documentation: ` docs/what-changed `
28- - Release branches: ` release/version-number `
44+ ### Branch Naming Convention
45+
46+ All branches should follow this naming convention:
47+
48+ ```
49+ <issue-number>-<short-description>
50+ ```
51+
52+ For example:
53+ - ` 123-add-aws-secrets-backend `
54+ - ` 456-fix-path-validation `
55+ - ` 789-update-documentation `
56+
57+ Note: This naming convention is required for branches in the main repository. When working in your own fork, we recommend:
58+ 1 . Creating a dedicated branch for each issue (don't work in main)
59+ 2 . Following the same naming convention for consistency
60+ 3 . Keeping your fork's main branch clean for easy upstream syncing
2961
3062### Commit Messages
31- Follow the [ Conventional Commits] ( https://www.conventionalcommits.org/ ) specification:
63+
64+ Follow the [ Conventional Commits] ( https://www.conventionalcommits.org/ ) specification with issue number references:
65+
3266```
33- <type>[optional scope]: <description>
67+ <type>[optional scope]: #<issue-number> <description>
3468
3569[optional body]
3670
3771[optional footer(s)]
3872```
3973
4074Types:
41- - ` feat ` : New feature
42- - ` fix ` : Bug fix
75+ - ` feat ` : A new feature
76+ - ` fix ` : A bug fix
4377- ` docs ` : Documentation only changes
4478- ` style ` : Changes that do not affect the meaning of the code
45- - ` refactor ` : Code change that neither fixes a bug nor adds a feature
79+ - ` refactor ` : A code change that neither fixes a bug nor adds a feature
4680- ` test ` : Adding missing tests or correcting existing tests
4781- ` chore ` : Changes to the build process or auxiliary tools
4882
49- Example:
83+ Examples:
84+ ```
85+ feat: #123 add AWS Secrets backend
86+ fix: #456 handle empty paths correctly
87+ docs: #789 update installation guide
88+ test: #234 add integration tests for Value class
5089```
51- feat(value): add support for remote storage backends
52-
53- - Implement ValueBackend interface
54- - Add AWS Secrets Manager backend
55- - Add Azure Key Vault backend
5690
57- Closes #123
91+ For multiple issues, include all issue numbers:
92+ ```
93+ fix: #111 #222 resolve path handling edge cases
5894```
5995
96+ Note:
97+ - Always include the issue number with a ` # ` prefix
98+ - Place the issue number before the description
99+ - Multiple issues should be space-separated
100+ - The description should still be clear without the issue number
101+
60102## Important Documentation
61103
62104Before contributing, please review these important documents:
0 commit comments