| Mar | APR | May |
| 18 | ||
| 2021 | 2022 | 2023 |
COLLECTED BY
Collection: Ukrainian Web
●Getting Started
●Where to Get Help
●Lifecycle of a Pull Request
●Running & Writing Tests
●Increase Test Coverage
●Helping with Documentation
●Documenting Python
●Silence Warnings From the Test Suite
●Fixing “easy” Issues (and Beyond)
●Issue Tracking
Toggle child pages in navigation
●GitHub Labels
●GitHub issues for BPO users
●Triaging an Issue
●Following Python’s Development
●Porting Python to a new platform
●How to Become a Core Developer
●Developer Log
●Accepting Pull Requests
●Development Cycle
●Continuous Integration
●Adding to the Stdlib
●Changing the Python Language
●Experts Index
●gdb Support
●Exploring CPython’s Internals
●Changing CPython’s Grammar
●Guide to CPython’s Parser
●Design of CPython’s Compiler
●Design of CPython’s Garbage Collector
●Updating standard library extension modules
●Changing Python’s C API
●Coverity Scan
●Dynamic Analysis with Clang
●Running a buildbot worker
●Core Developer Motivations and Affiliations
●Git Bootcamp and Cheat Sheet
●Appendix: Topics
v: latest
Versions
latest
Downloads
pdf
html
epub
On Read the Docs
Project Home
Builds
Back to top
Edit this page
Toggle Light / Dark / Auto color theme
Toggle table of contents sidebar
origin), and then create a pull request against
the official CPython repository (upstream).
make patchcheck
Commit and push
changes to your GitHub fork
Create Pull Request on GitHub to merge a branch from your fork
Make sure the continuous integration checks on your Pull Request
are green (i.e. successful)
Review and address comments on your Pull Request
When your changes are merged, you can delete the PR branch
Celebrate contributing to CPython! :)
*
If an issue is trivial (e.g. typo fixes), or if an issue already exists,
you can skip this step.
Note
In order to keep the commit history intact, please avoid squashing or amending
history and then force-pushing to the PR. Reviewers often want to look at
individual commits.
upstream repository:
git fetch upstreamCreate a new branch in your local clone:
git checkout -b <branch-name> upstream/mainMake changes to the code, and use
git status and git diff to see them.
(Learn more about Making Good PRs)
Make sure the changes are fine and don’t cause any test failure:
make patchcheck
./python -m test
(Learn more about patchcheck and about Running & Writing Tests)
Once you are satisfied with the changes, add the files and commit them:
git add <filenames>
git commit -m '<message>'
(Learn more about Making Good Commits)
Then push your work to your GitHub fork:
git push origin <branch-name>Finally go on
https://github.com/<your-username>/cpython: you will
see a box with the branch you just pushed and a green button that allows
you to create a pull request against the official CPython repository.
When people start adding review comments, you can address them by switching
to your branch, making more changes, committing them, and pushing them to
automatically update your PR:
git checkout <branch-name> # make changes and run tests git add <filenames> git commit -m '<message>' git push origin <branch-name>If a core developer reviewing your PR pushed one or more commits to your PR branch, then after checking out your branch and before editing, run:
git pull origin <branch-name> # pull = fetch + merge
If you have made local changes that have not been pushed to your fork and
there are merge conflicts, git will warn you about this and enter conflict
resolution mode. See Resolving Merge Conflicts below.
If time passes and there are merge conflicts with the main branch, GitHub
will show a warning to this end and you may be asked to address this. Merge
the changes from the main branch while resolving the conflicts locally:
git checkout <branch-name> git pull upstream main # pull = fetch + merge # resolve conflicts: see "Resolving Merge Conflicts" below git push origin <branch-name>After your PR has been accepted and merged, you can delete the branch:
git branch -D <branch-name> # delete local branch git push origin -d <branch-name> # delete remote branch
git statusEdit the affected files and bring them to their intended final state. Make sure to remove the special “conflict markers” inserted by git. Commit the affected files:
git add <filenames> git merge --continueWhen running the final command, git may open an editor for writing a commit message. It is usually okay to leave that as-is and close the editor. See the merge command’s documentation for a detailed technical explanation.
patchcheck#
patchcheck is a simple automated patch checklist that guides a developer
through the common patch generation checks. To run patchcheck:
OnUNIX (including Mac OS X):
make patchcheckOnWindows (after any successful build):
python.bat Tools\scripts\patchcheck.pyThe automated patch checklist runs through: Are there any whitespace problems in Python files? (using
Tools/scripts/reindent.py)
Are there any whitespace problems in C files?
Are there any whitespace problems in the documentation?
(using Tools/scripts/reindent-rst.py)
Has the documentation been updated?
Has the test suite been updated?
Has an entry under Misc/NEWS.d/next been added?
(using blurb-it,
or the blurb tool)
Has Misc/ACKS been updated?
Has configure been regenerated, if necessary?
Has pyconfig.h.in been regenerated, if necessary?
The automated patch check doesn’t actually answer all of these
questions. Aside from the whitespace checks, the tool is
a memory aid for the various elements that can go into
making a complete patch.
gh-42: Make the spam module more spammy (GH-NNNN) The spam module sporadically came up short on spam. This change raises the amount of spam in the module by making it more spammy.The first line or sentence is meant to be a dense, to-the-point explanation of what the purpose of the commit is. The imperative form (used in the example above) is strongly preferred to a descriptive form such as ‘the spam module is now more spammy’. Use
git log --oneline to see existing title lines.
Furthermore, the first line should not end in a period.
If this is not enough detail for a commit, a new paragraph(s) can be added
to explain in proper depth what has happened (detail should be good enough
that a core developer reading the commit message understands the
justification for the change).
Check the git bootcamp for further
instructions on how the commit message should look like when merging a pull
request.
Note
How to Write a Git Commit Message
is a nice article that describes how to write a good commit message.
cpython-cla-bot comments on your pull request that commit
authors are required to sign a Contributor License Agreement, click
on the button in the comment to sign it. It’s enough to log in through
GitHub. The process is automatic.
After signing, the comment by cpython-cla-bot will update to
indicate that “all commit authors signed the Contributor License
Agreement.
git commit -a and
that will commit everything. You can always run git status to see
what changes are outstanding.
When all of your changes are committed (i.e. git status doesn’t
list anything), you will want to push your branch to your fork:
git push origin <branch name>This will get your changes up to GitHub. Now you want to create a pull request from your fork. If this is a pull request in response to a pre-existing issue on the issue tracker, please make sure to reference the issue number using
gh-NNNN in the pull request title or message.
If this is a pull request for an unreported issue (assuming you already
performed a search on the issue tracker for a pre-existing issue), create a
new issue and reference it in the pull request. Please fill in as much
relevant detail as possible to prevent reviewers from having to delay
reviewing your pull request because of lack of information.
If this issue is so simple that there’s no need for an issue to track
any discussion of what the pull request is trying to solve (e.g. fixing a
spelling mistake), then the pull request needs to have the “skip issue” label
added to it by someone with commit access.
Your pull request may involve several commits as a result of addressing code
review comments. Please keep the commit history in the pull request intact by
not squashing, amending, or anything that would require a force push to GitHub.
A detailed commit history allows reviewers to view the diff of one commit to
another so they can easily verify whether their comments have been addressed.
The commits will be squashed when the pull request is merged.
Misc/ACKS file (and, most
often, in a contribution’s news entry as well). You may be
asked to make these edits on the behalf of the core developer who
accepts your pull request.
Next
Running & Writing Tests
Previous
Where to Get Help
Copyright © 2011-2022, Python Software Foundation
Made with Sphinx and @pradyunsg's
Furo
Last updated on Apr 16, 2022
Contents
●Lifecycle of a Pull Request
●Introduction
●Quick Guide
●Step-by-step Guide
●Resolving Merge Conflicts
●Making Good PRs
●patchcheck
●Making Good Commits
●Licensing
●Submitting
●Converting an Existing Patch from b.p.o to GitHub
●Reviewing
●How to Review a Pull Request
●Leaving a Pull Request Review on GitHub
●Dismissing Review from Another Core Developer
●Committing/Rejecting
●Crediting