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:
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
-
12
-
## Working with branches:
9
+
## Working with branches
13
10
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:
|`main`| Contains a snapshot of the latest development code.<br>**Not intended for production use and may be unstable.**| Daily |
15
+
|`beta`| Contains a snapshot of the next version currently in testing.<br>**Accepts bug fixes and code clean-up only!**| Weekly |
16
+
|`release`| Contains a snapshot of the latest stable release.<br>**This code aligns with the packages released via apt**| Monthly |
16
17
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.
18
+
### Creating a new branch and submitting pull requests
20
19
21
-
### I want to contribute some code to Hestia Control Panel, where do I start?
20
+
The first step is to create a fork under your account on GitHub. This will provide you with your own copy of the code to work with at any time.
22
21
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.
22
+
Next, create a new topic branch for your work. When submitting pull requests, it is important to target the correct branch to ensure that your changes are properly integrated and tested based on our release schedule. When creating a new branch, we ask that you please adhere to the following naming conventions as much as possible:
24
23
25
-
When creating your branches, **please adhere to the following naming conventions:**
26
-
27
-
-**Prefix:**`bugfix/` or `feature/` based on the type of submission.
24
+
### Branch naming convention:
25
+
-**Prefix:**`topic/` (such as **bugfix**, **feature**, **refactor**, etc.)
28
26
-**ID**: `888` (GitHub Issue ID if an issue exists) -or- `2020-07` (Year-Month if an issue does not already exist)
29
27
-**Separator:**`_` (underscore)
30
28
-**Title:**`my-awesome-patch`
31
29
32
30
Branch name examples:
33
31
*`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.
32
+
*`fix/000_some-bug-fix` or `fix/2020-07_this-feature-is-broken`
33
+
*`refactor/2020-07_v-change-domain-owner`
34
+
*`test/2020-07_main-domain-ssl`
35
+
36
+
To better understand our branch structure, please refer to the following table:
37
+
38
+
### Git branch target workflow:
39
+
40
+
| Topic branches: | Target: | Final destination: |
|**`refactor/*`**|`staging/cleanup`|`main` or `beta`|
45
+
|**`test/*`**|`staging/tests`|`main`|
46
+
|**`doc/*`**|`staging/docs`|`main`, `beta`, or `release`|
47
+
48
+
### Notes:
49
+
-`topic/*` branches are submitted to our team via pull request for eventual inclusion into the `main` code branch and a future version of Hestia Control Panel.
50
+
-`staging/*` branches are integrated into `main` at various intervals throughout the development process until all planned work items are integrated.
51
+
- Once a new version is ready for testing and validation, a snapshot of the code from `main` is merged to `beta`.
52
+
- When the `beta` release is ready to move to production, the code is then pushed to `release`.
53
+
- Each major version (such as v1.1, v1.2) will also have a corresponding `release/vX.x` version branch for archival and maintenance/servicing purposes.
54
+
55
+
## Squashing commits for smaller changes
56
+
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.
42
57
43
-
**Please ensure that all pull requests meet the guidelines listed above; those that do not will be rejected and sent back for review.**
58
+
**IMPORTANT: 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