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
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+21-21Lines changed: 21 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,14 +14,14 @@ Bug fixes
14
14
It's very important that we can easily track bug fix commits, so their hashes should remain the same in all branches.
15
15
Therefore, a pull request (PR) that fixes a bug, should be sent against a release branch.
16
16
This can be either the "current release" or the "previous release", depending on which ones are maintained.
17
-
Since the goal is a stable master, bug fixes should be "merged forward" to the next branch in order: "previous release" -> "current release" -> master (in other words: old to new)
17
+
Since the goal is a stable main, bug fixes should be "merged forward" to the next branch in order: "previous release" -> "current release" -> main (in other words: old to new)
18
18
19
19
Developing new features
20
20
-----------------------
21
21
22
-
Development should be done in a feature branch, branched off of master.
23
-
Send a PR(steps below) to get it into master (2x LGTM applies).
24
-
PR will only be merged when master is open, will be held otherwise until master is open again.
22
+
Development should be done in a feature branch, branched off of main.
23
+
Send a PR(steps below) to get it into main (2x LGTM applies).
24
+
PR will only be merged when main is open, will be held otherwise until main is open again.
25
25
No back porting / cherry-picking features to existing branches!
26
26
27
27
PendingReleaseNotes file
@@ -46,17 +46,17 @@ On your computer, follow these steps to setup a local repository for working on
It is important that you create a new branch to make changes on and that you do not change the `master` branch (other than to rebase in changes from `upstream/master`). In this example I will assume you will be making your changes to a branch called `feature_x`. This `feature_x` branch will be created on your local repository and will be pushed to your forked repository on GitHub. Once this branch is on your fork you will create a Pull Request for the changes to be added to the ACS project.
59
+
It is important that you create a new branch to make changes on and that you do not change the `main` branch (other than to rebase in changes from `upstream/main`). In this example I will assume you will be making your changes to a branch called `feature_x`. This `feature_x` branch will be created on your local repository and will be pushed to your forked repository on GitHub. Once this branch is on your fork you will create a Pull Request for the changes to be added to the ACS project.
60
60
61
61
It is best practice to create a new branch each time you want to contribute to the project and only track the changes for that pull request in this branch.
62
62
@@ -71,26 +71,26 @@ $ git commit -a -m "descriptive commit message for your changes"
71
71
> The `-b` specifies that you want to create a new branch called `feature_x`. You only specify `-b` the first time you checkout because you are creating a new branch. Once the `feature_x` branch exists, you can later switch to it with only `git checkout feature_x`.
72
72
73
73
74
-
Rebase `feature_x` to include updates from `upstream/master`
74
+
Rebase `feature_x` to include updates from `upstream/main`
It is important that you maintain an up-to-date `master` branch in your local repository. This is done by rebasing in the code changes from `upstream/master` (the official ACS project repository) into your local repository. You will want to do this before you start working on a feature as well as right before you submit your changes as a pull request. I recommend you do this process periodically while you work to make sure you are working off the most recent project code.
77
+
It is important that you maintain an up-to-date `main` branch in your local repository. This is done by rebasing in the code changes from `upstream/main` (the official ACS project repository) into your local repository. You will want to do this before you start working on a feature as well as right before you submit your changes as a pull request. I recommend you do this process periodically while you work to make sure you are working off the most recent project code.
78
78
79
79
This process will do the following:
80
80
81
-
1. Checkout your local `master` branch
82
-
2. Synchronize your local `master` branch with the `upstream/master` so you have all the latest changes from the project
81
+
1. Checkout your local `main` branch
82
+
2. Synchronize your local `main` branch with the `upstream/main` so you have all the latest changes from the project
83
83
3. Rebase the latest project code into your `feature_x` branch so it is up-to-date with the upstream code
84
84
85
85
```bash
86
-
$ git checkout master
86
+
$ git checkout main
87
87
$ git fetch upstream
88
-
$ git rebase upstream/master
88
+
$ git rebase upstream/main
89
89
$ git checkout feature_x
90
-
$ git rebase master
90
+
$ git rebase main
91
91
```
92
92
93
-
> Now your `feature_x` branch is up-to-date with all the code in `upstream/master`.
93
+
> Now your `feature_x` branch is up-to-date with all the code in `upstream/main`.
94
94
95
95
96
96
Make a GitHub Pull Request to contribute your changes
@@ -100,10 +100,10 @@ When you are happy with your changes and you are ready to contribute them, you w
100
100
101
101
Please include JIRA id, detailed information about the bug/feature, what all tests are executed, how the reviewer can test this feature etc. Incase of UI PRs, a screenshot is preferred.
102
102
103
-
> **IMPORTANT:** Make sure you have rebased your `feature_x` branch to include the latest code from `upstream/master`_before_ you do this.
103
+
> **IMPORTANT:** Make sure you have rebased your `feature_x` branch to include the latest code from `upstream/main`_before_ you do this.
104
104
105
105
```bash
106
-
$ git push origin master
106
+
$ git push origin main
107
107
$ git push origin feature_x
108
108
```
109
109
@@ -113,7 +113,7 @@ To initiate the pull request, do the following:
113
113
114
114
1. In your browser, navigate to your forked repository: [https://github.com/YOUR_ACCOUNT/cloudstack](https://github.com/YOUR_ACCOUNT/cloudstack)
115
115
2. Click the new button called '**Compare & pull request**' that showed up just above the main area in your forked repository
116
-
3. Validate the pull request will be into the upstream `master` and will be from your `feature_x` branch
116
+
3. Validate the pull request will be into the upstream `main` and will be from your `feature_x` branch
117
117
4. Enter a detailed description of the work you have done and then click '**Send pull request**'
118
118
119
119
If you are requested to make modifications to your proposed changes, make the changes locally on your `feature_x` branch, re-push the `feature_x` branch to your fork. The existing pull request should automatically pick up the change and update accordingly.
@@ -122,14 +122,14 @@ If you are requested to make modifications to your proposed changes, make the ch
122
122
Cleaning up after a successful pull request
123
123
-------------------------------------------
124
124
125
-
Once the `feature_x` branch has been committed into the `upstream/master` branch, your local `feature_x` branch and the `origin/feature_x` branch are no longer needed. If you want to make additional changes, restart the process with a new branch.
125
+
Once the `feature_x` branch has been committed into the `upstream/main` branch, your local `feature_x` branch and the `origin/feature_x` branch are no longer needed. If you want to make additional changes, restart the process with a new branch.
126
126
127
-
> **IMPORTANT:** Make sure that your changes are in `upstream/master` before you delete your `feature_x` and `origin/feature_x` branches!
127
+
> **IMPORTANT:** Make sure that your changes are in `upstream/main` before you delete your `feature_x` and `origin/feature_x` branches!
128
128
129
129
You can delete these deprecated branches with the following:
Copy file name to clipboardExpand all lines: README.md
+3-7Lines changed: 3 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# Apache CloudStack [](https://travis-ci.org/apache/cloudstack)[](https://sonarcloud.io/dashboard?id=apachecloudstack)[](https://sonarcloud.io/dashboard?id=apachecloudstack)
1
+
# Apache CloudStack [](https://travis-ci.org/apache/cloudstack)[](https://sonarcloud.io/dashboard?id=apachecloudstack)[](https://sonarcloud.io/dashboard?id=apachecloudstack)
0 commit comments