@@ -59,7 +59,7 @@ will allow others to reproduce the bug and provide insight into fixing. See
59
59
`this blogpost <https://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports >`_
60
60
for tips on writing a good bug report.
61
61
62
- Trying the bug-producing code out on the *master * branch is often a worthwhile exercise
62
+ Trying the bug-producing code out on the *main * branch is often a worthwhile exercise
63
63
to confirm the bug still exists. It is also worth searching existing bug reports and pull requests
64
64
to see if the issue has already been reported and/or fixed.
65
65
@@ -143,7 +143,7 @@ as the version number cannot be computed anymore.
143
143
Creating a branch
144
144
-----------------
145
145
146
- You want your master branch to reflect only production-ready code, so create a
146
+ You want your main branch to reflect only production-ready code, so create a
147
147
feature branch for making your changes. For example::
148
148
149
149
git branch shiny-new-feature
@@ -158,14 +158,14 @@ changes in this branch specific to one bug or feature so it is clear
158
158
what the branch brings to pandas. You can have many shiny-new-features
159
159
and switch in between them using the git checkout command.
160
160
161
- When creating this branch, make sure your master branch is up to date with
162
- the latest upstream master version. To update your local master branch, you
161
+ When creating this branch, make sure your main branch is up to date with
162
+ the latest upstream main version. To update your local main branch, you
163
163
can do::
164
164
165
- git checkout master
166
- git pull upstream master --ff-only
165
+ git checkout main
166
+ git pull upstream main --ff-only
167
167
168
- When you want to update the feature branch with changes in master after
168
+ When you want to update the feature branch with changes in main after
169
169
you created the branch, check the section on
170
170
:ref: `updating a PR <contributing.update-pr >`.
171
171
@@ -256,16 +256,16 @@ double check your branch changes against the branch it was based on:
256
256
#. Navigate to your repository on GitHub -- https://github.com/your-user-name/pandas
257
257
#. Click on ``Branches ``
258
258
#. Click on the ``Compare `` button for your feature branch
259
- #. Select the ``base `` and ``compare `` branches, if necessary. This will be ``master `` and
259
+ #. Select the ``base `` and ``compare `` branches, if necessary. This will be ``main `` and
260
260
``shiny-new-feature ``, respectively.
261
261
262
262
Finally, make the pull request
263
263
------------------------------
264
264
265
265
If everything looks good, you are ready to make a pull request. A pull request is how
266
266
code from a local repository becomes available to the GitHub community and can be looked
267
- at and eventually merged into the master version. This pull request and its associated
268
- changes will eventually be committed to the master branch and available in the next
267
+ at and eventually merged into the main version. This pull request and its associated
268
+ changes will eventually be committed to the main branch and available in the next
269
269
release. To submit a pull request:
270
270
271
271
#. Navigate to your repository on GitHub
@@ -294,14 +294,14 @@ This will automatically update your pull request with the latest code and restar
294
294
:any: `Continuous Integration <contributing.ci> ` tests.
295
295
296
296
Another reason you might need to update your pull request is to solve conflicts
297
- with changes that have been merged into the master branch since you opened your
297
+ with changes that have been merged into the main branch since you opened your
298
298
pull request.
299
299
300
- To do this, you need to "merge upstream master " in your branch::
300
+ To do this, you need to "merge upstream main " in your branch::
301
301
302
302
git checkout shiny-new-feature
303
303
git fetch upstream
304
- git merge upstream/master
304
+ git merge upstream/main
305
305
306
306
If there are no conflicts (or they could be fixed automatically), a file with a
307
307
default commit message will open, and you can simply save and quit this file.
@@ -313,7 +313,7 @@ Once the conflicts are merged and the files where the conflicts were solved are
313
313
added, you can run ``git commit `` to save those fixes.
314
314
315
315
If you have uncommitted changes at the moment you want to update the branch with
316
- master , you will need to ``stash `` them prior to updating (see the
316
+ main , you will need to ``stash `` them prior to updating (see the
317
317
`stash docs <https://git-scm.com/book/en/v2/Git-Tools-Stashing-and-Cleaning >`__).
318
318
This will effectively store your changes and they can be reapplied after updating.
319
319
@@ -342,12 +342,12 @@ Delete your merged branch (optional)
342
342
------------------------------------
343
343
344
344
Once your feature branch is accepted into upstream, you'll probably want to get rid of
345
- the branch. First, merge upstream master into your branch so git knows it is safe to
345
+ the branch. First, merge upstream main into your branch so git knows it is safe to
346
346
delete your branch::
347
347
348
348
git fetch upstream
349
- git checkout master
350
- git merge upstream/master
349
+ git checkout main
350
+ git merge upstream/main
351
351
352
352
Then you can do::
353
353
0 commit comments