You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All pull requests must include a brief but descriptive title, and a description of the changes that you've made with as much detail as possible. **Only include commits that are related to your feature, bug fix, or patch in your pull request.**
5
5
6
-
###Code formatting and comments:
6
+
## Code formatting and comments:
7
7
We ask that you follow existing naming schemes and coding conventions where possible, and that you add comments in your source code where appropriate to aid other developers in debugging and understanding your code in the future.
8
8
9
-
###Squashing commits for smaller changes:
9
+
## Squashing commits for smaller changes:
10
10
When submitting a pull request with multiple smaller commits which are related to the same issue (or file), we ask that you please **squash your commits** in order to keep the project's commit history clean and easy to follow for other developers.
11
11
12
-
###Working with branches:
12
+
## Working with branches:
13
13
Development for this project takes place in branches to effectively develop, manage, and test new features and code changes, helping to ensure that each release meets high quality standards. Our primary branches are as follows:
14
14
15
-
***master**: Active development code for the the next version of Hestia Control Panel.
16
-
***release**: The latest stable release code - installation packages generally align with this branch.
15
+
### Primary branches:
17
16
18
-
We ask that you create a new branch for your work based on **master**, this will allow you to submit only the necessary commits/changes that you've made. We generally adhere to the below naming convention for internal branches; you're welcome to use your own naming conventions so long as your commits follow the guidelines mentioned above.
17
+
*`develop`: Active development code for the the next version of Hestia Control Panel, considered to be unstable.
18
+
*`beta`: Feature locked code for the next release, which receives fixes only and goes through feedback and testing.
19
+
*`release`: Code in this branch aligns with the latest packages available on our APT repositories.
19
20
20
-
***feature-name**: New features
21
-
***bugfix-000**: Bug fixes
21
+
### I want to contribute some code to Hestia Control Panel, where do I start?
22
22
23
-
**Note**: Replace **000** with the GitHub Issue ID if available, or use a short but descriptive name.
23
+
First, create a new branch for your work based on the `develop` branch to ensure that you have the latest commits in your local repository, which will help make sure that your pull requests only contain the commits that are necessary.
24
24
25
-
### Feature freeze:
26
-
Once development has reached a point where all planned new features have been incorporated, the **master** branch will then enter a "feature freeze" period where only fixes to the existing functionality will be added or merged for inclusion. Once any known issues have been resolved and the build has passed internal validation and testing procedures, it will then be pushed to **release** and tagged with it's respective version number and made available through our APT repositories.
25
+
When creating your branches, **please adhere to the following naming conventions:**
26
+
27
+
-**Prefix:**`bugfix/` or `feature/` based on the type of submission.
28
+
-**ID**: `888` (GitHub Issue ID if an issue exists) -or- `2020-07` (Year-Month if an issue does not already exist)
29
+
-**Separator:**`_` (underscore)
30
+
-**Title:**`my-awesome-patch`
31
+
32
+
Branch name examples:
33
+
*`feature/777_my-awesome-new-feature` or `feature/2020-07_my-other-new-feature`
34
+
*`bugfix/000_some-bug-fix` or `bugfix/2020-07_this-feature-is-broken`
35
+
36
+
Once your code is complete and you have reviewed it for errors, submit a pull request to the correct integration branch:
37
+
38
+
*`staging/fixes`: bugfix/ branches will merge to this branch when they have been tested/verified.
39
+
*`staging/features`: feature/ branches will merge to this branch when they have been tested/verified.
40
+
41
+
All `staging` branches will integrate to `develop` to form the next release of Hestia Control Panel. Once all features and fixes planned for the release are merged, the code will then be pushed to the `beta` branch where it is feature locked, assigned a version number, and will receive thorough testing before being pushed to the `release` branch with new packages being pushed to APT.
27
42
28
43
**Please ensure that all pull requests meet the guidelines listed above; those that do not will be rejected and sent back for review.**
0 commit comments