@@ -108,9 +108,9 @@ report the bug or propose the feature you'd like to add.
108108It's best to synchronize your fork with the upstream repository, then create a
109109new, separate branch for each piece of work you want to do. E.g.::
110110
111- git checkout master
111+ git checkout main
112112 git fetch upstream
113- git rebase upstream/master
113+ git rebase upstream/main
114114 git push
115115 git checkout -b shiny-new-feature
116116 git push -u origin shiny-new-feature
@@ -120,18 +120,18 @@ this branch specific to one bug or feature so it is clear what the branch brings
120120Zarr.
121121
122122To update this branch with latest code from Zarr, you can retrieve the changes from
123- the master branch and perform a rebase::
123+ the main branch and perform a rebase::
124124
125125 git fetch upstream
126- git rebase upstream/master
126+ git rebase upstream/main
127127
128- This will replay your commits on top of the latest Zarr git master . If this leads to
128+ This will replay your commits on top of the latest Zarr git main . If this leads to
129129merge conflicts, these need to be resolved before submitting a pull request.
130- Alternatively, you can merge the changes in from upstream/master instead of rebasing,
130+ Alternatively, you can merge the changes in from upstream/main instead of rebasing,
131131which can be simpler::
132132
133133 git fetch upstream
134- git merge upstream/master
134+ git merge upstream/main
135135
136136Again, any conflicts need to be resolved before submitting a pull request.
137137
@@ -206,7 +206,7 @@ Documentation
206206
207207Docstrings for user-facing classes and functions should follow the
208208`numpydoc
209- <https://github.com/numpy/numpy/blob/master /doc/HOWTO_DOCUMENT.rst.txt> `_
209+ <https://github.com/numpy/numpy/blob/main /doc/HOWTO_DOCUMENT.rst.txt> `_
210210standard, including sections for Parameters and Examples. All examples
211211should run and pass as doctests under Python 3.8. To run doctests,
212212activate your development environment, install optional requirements,
@@ -242,7 +242,7 @@ one core developers before being merged. Ideally, pull requests submitted by a c
242242should be reviewed and approved by at least one other core developers before being merged.
243243
244244Pull requests should not be merged until all CI checks have passed (GitHub Actions
245- Codecov) against code that has had the latest master merged in.
245+ Codecov) against code that has had the latest main merged in.
246246
247247Compatibility and versioning policies
248248~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -337,9 +337,9 @@ Release procedure
337337 Most of the release process is now handled by github workflow which should
338338 automatically push a release to PyPI if a tag is pushed.
339339
340- Checkout and update the master branch::
340+ Checkout and update the main branch::
341341
342- $ git checkout master
342+ $ git checkout main
343343 $ git pull
344344
345345Verify all tests pass on all supported Python versions, and docs build::
0 commit comments