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
+13-13Lines changed: 13 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ opening a new [issue](https://github.com/spacetelescope/jwst/issues).
15
15
## Contributing code
16
16
17
17
If you would like to contribute code, this is done by submitting a [pull request](https://github.com/spacetelescope/jwst/pulls)
18
-
to the "master" branch of `spacetelescope/jwst`. To do this, we recommend the
18
+
to the "main" branch of `spacetelescope/jwst`. To do this, we recommend the
19
19
following workflow (which assumes you already have a Github account / command line tools).
20
20
If you are also new to git, please refer to the [git reference manual](https://git-scm.com/docs)
21
21
for an overview of git basics.
@@ -33,7 +33,7 @@ First, to clarify some terms that will be commonly used here:
33
33
The first step is to create your own 'remote' (online) and 'local' (on your machine)
34
34
clones of the central `spacetelescope/jwst` repository. You will make code changes
35
35
on your machine to your 'local' clone, push these to 'origin' (your online fork),
36
-
and finally, open a pull request to the ''master'' branch of `spacetelescope/jwst`.
36
+
and finally, open a pull request to the ''main'' branch of `spacetelescope/jwst`.
37
37
38
38
1. On the 'spacetelescope/jwst' Github repository page, 'fork' the JWST repository
39
39
to your own account space by clicking the appropriate button on the upper right-hand
@@ -77,16 +77,16 @@ If you ever want to reset these URLs, add references to other remote forks of
77
77
78
78
### Step 2: Creating a branch for your changes
79
79
80
-
It is a standard practice in git to create a new 'branch' (off `upstream/master`)
80
+
It is a standard practice in git to create a new 'branch' (off `upstream/main`)
81
81
for each new feature or bug fix. You can call this branch whatever you like - in
82
82
this example, we'll call it 'my_feature'. First, make sure you
83
83
have all recent changes to upstream by 'fetching' them:
84
84
85
85
>> git fetch upstream
86
86
87
-
The following will create a new branch off local/master called 'my_feature', and automatically switch you over to your new branch.
87
+
The following will create a new branch off local/main called 'my_feature', and automatically switch you over to your new branch.
88
88
89
-
>> git checkout -b my_feature upstream/master
89
+
>> git checkout -b my_feature upstream/main
90
90
91
91
### Step 3: Installing `jwst` for development
92
92
@@ -149,14 +149,14 @@ you open a pull request, add the corresponding PR number.
149
149
150
150
### Step 4: Opening a pull request
151
151
152
-
Now, you can open a pull request on the master branch of the upstream `jwst` repository.
152
+
Now, you can open a pull request on the main branch of the upstream `jwst` repository.
153
153
154
154
1. On the `spacetelescope/jwst` web page, after you push your changes you should
155
155
see a large green banner appear at the top prompting you to open a pull request
156
156
with your recently pushed changes. You can also open a pull request from the
157
157
[pull request tab](https://github.com/spacetelescope/jwst/pulls) on that page.
158
158
Select your fork and your 'my_feature' branch, and open a pull request against
159
-
the 'master' branch.
159
+
the 'main' branch.
160
160
161
161
2. There is now a checklist of items that need to be done before your PR can be merged.
162
162
* The continuous integration (CI) tests must complete and pass. The CI
@@ -177,16 +177,16 @@ the 'master' branch.
177
177
## Keeping your development branch current - rebasing
178
178
179
179
As `jwst` is constantly evolving, you will often encounter the situation where you've
180
-
made changes to your branch off 'master', but in the time its taken you to make those
181
-
changes, 'upstream/master' has evolved with new commits from other developers. In this
180
+
made changes to your branch off 'main', but in the time its taken you to make those
181
+
changes, 'upstream/main' has evolved with new commits from other developers. In this
182
182
situation, you will want to make sure you incorporate these changes into your branch.
183
183
Rebasing allows you to do two things - 1. apply others changes on top of yours, and 2.
184
184
squash your commits, even if there aren't new changes to apply.
185
185
186
186
Periodically, while writing code, to keep your branch up to date you will want to
187
-
do an interactive rebase against upstream/master to apply any new changes on top of yours:
187
+
do an interactive rebase against upstream/main to apply any new changes on top of yours:
188
188
189
-
>> git rebase -i upstream/master
189
+
>> git rebase -i upstream/main
190
190
191
191
This will then prompt you to select commits and commit messages - if you select
192
192
just the top commit, this will 'squash' the others and combine them into one. You
@@ -204,7 +204,7 @@ commits into a single one, which is also done with `git rebase`
204
204
`jwst` uses [sphinx](https://docs.readthedocs.io/en/stable/intro/getting-started-with-sphinx.html) to generate documentation, which is then hosted online on [readthedocs](https://readthedocs.org/).
205
205
206
206
You can access two versions of the documentation on the [JWST readthedocs website](https://readthedocs.org/projects/jwst-pipeline/)
207
-
- the 'latest' version is whatever is currently on the master branch, and the 'stable'
207
+
- the 'latest' version is whatever is currently on the main branch, and the 'stable'
208
208
version is the last released version. If you successfully merge a PR with documentation
209
209
changes, they will only appear on 'latest' until the next JWST release.
210
210
@@ -329,7 +329,7 @@ last released version of `stcal`, and stcal points to the last version of `jwst`
329
329
issue becomes circular. What you will need to do is modify the `pyproject.toml` files in both
330
330
packages to point to the other to demonstrate that CI tests pass (and make a comment
331
331
noting this in your PR), and then change it back before the PR is merge so that changes
332
-
to `pyproject.toml` are not merged into master/main. In your `jwst` branch, to point to your
332
+
to `pyproject.toml` are not merged into main. In your `jwst` branch, to point to your
333
333
branch in the dependent package (in this example `stcal`), change the required `stcal`
0 commit comments