This section is addressed to the mergers and to anyone interested in knowing how code gets committed into Django. If you're a community member who wants to contribute code to Django, look at 使用 Git 和 GitHub 工作 instead.
因为Django现在是托管在GitHub上的，所以大多数补丁都是以 pull requests 的形式提供的。
When committing a pull request, make sure each individual commit matches the commit guidelines described below. Contributors are expected to provide the best pull requests possible. In practice mergers - who will likely be more familiar with the commit guidelines - may decide to bring a commit up to standard themselves.
You may want to have Jenkins or GitHub actions test the pull request with one of the pull request builders that doesn't run automatically, such as Oracle or Selenium. See the CI wiki page for instructions.
If you find yourself checking out pull requests locally more often, this git alias will be helpful:
[alias]
pr = !sh -c \"git fetch upstream pull/${1}/head:pr/${1} && git checkout pr/${1}\"
将它添加到你的 ~/.gitconfig 文件中，并且把 upstream 改为 django/django 。然后你就可以通过运行 git pr #### 来检出对应的 pull request 了。
到了这个阶段,你可以着手于代码.使用"git rebase -i"和"git commit --ammend" 来确保你的提交准确无误. 一旦你准备好了:
$ # Pull in the latest changes from main.
$ git checkout main
$ git pull upstream main
$ # Rebase the pull request on main.
$ git checkout pr/####
$ git rebase main
$ git checkout main
$ # Merge the work as "fast-forward" to main to avoid a merge commit.
$ # (in practice, you can omit "--ff-only" since you just rebased)
$ git merge --ff-only pr/XXXX
$ # If you're not sure if you did things correctly, check that only the
$ # changes you expect will be pushed to upstream.
$ git push --dry-run upstream main
$ # Push!
$ git push upstream main
$ # Delete the pull request branch.
$ git branch -d pr/xxxx
...\> REM Pull in the latest changes from main.
...\> git checkout main
...\> git pull upstream main
...\> REM Rebase the pull request on main.
...\> git checkout pr/####
...\> git rebase main
...\> git checkout main
...\> REM Merge the work as "fast-forward" to main to avoid a merge commit.
...\> REM (in practice, you can omit "--ff-only" since you just rebased)
...\> git merge --ff-only pr/XXXX
...\> REM If you're not sure if you did things correctly, check that only the
...\> REM changes you expect will be pushed to upstream.
...\> git push --dry-run upstream main
...\> REM Push!
...\> git push upstream main
...\> REM Delete the pull request branch.
...\> git branch -d pr/xxxx
Force push to the branch after rebasing on main but before merging and pushing to upstream. This allows the commit hashes on main and the branch to match which automatically closes the pull request.
如果拉请求不需要合并为多个提交，则可以在网页上使用Github的“挤压和合并”按钮。根据需要编辑提交消息以符合：ref:`The guidelines<committing-guidelines>`并删除自动附加到消息第一行的请求编号。
当重写pull请求的提交历史时，目标是使Django的提交历史尽可能可用：
Practicality beats purity, so it is up to each merger to decide how much history mangling to do for a pull request. The main points are engaging the community, getting work done, and having a usable commit history.
此外，在将代码提交到Django的Git存储库时，请遵循以下准则：
永远不要通过强制推动来改变“django / django``分支的已发布历史。如果您绝对必须（出于安全原因），请先与团队讨论情况。
For any medium-to-big changes, where "medium-to-big" is according to your judgment, please bring things up on the Django Forum or django-developers mailing list before making the change.
If you bring something up and nobody responds, please don't take that to mean your idea is great and should be implemented immediately because nobody contested it. Everyone doesn't always have a lot of time to read mailing list discussions immediately, so you may have to wait a couple of days before getting a response.
以过去时态写出详细的提交消息，而不是现在时。
提交消息最多应为72个字符。 应该有一个主题行，用空白行分隔，然后是72个字符行的段落。 限制很软。 对于主题行，越短越好。 在提交消息的主体中，更多细节优于更少：
Fixed #18307 -- Added git workflow guidelines.
Refactored the Django's documentation to remove mentions of SVN
specific tasks. Added guidelines of how to use Git, GitHub, and
how to use pull request together with Trac instead.
可以在提交消息中添加对贡献者的感谢：“感谢A提供报告，B提供补丁，C提供审查。” 也推荐使用 git 的 Co-Authored-By _ 功能。
对于提交到分支，请在提交消息前面加上分支名称。例如：“[1.4.x]Fixed XXXX——增加了对思维阅读的支持。”
限制承诺最细微的变化是有意义的。这意味着，使用频繁的小额承诺，而不是很少的大额承诺。例如，如果实现功能X需要对库Y做一个小的更改，那么首先将更改提交到库Y，然后在单独的提交中提交功能X。这对帮助每个人跟踪你的变化有很大的帮助。
将错误修复与功能更改分开。根据：ref:supported versions policy，可能需要将错误修复返回到稳定分支。
如果你的提交解决了 Django ticket tracker 中的一个 ticket，请在提交信息的开头添加 "Fixed #xxxxx"，其中 ”xxxxx" 是你提交所解决的 ticket 的编号。示例："Fixed #123 -- Added whizbang feature." 。当系统检测到这种提交信息格式时，系统会自动关闭所指向的 ticket 并将完整的提交信息作为评论发出。
如果你好奇的话，我们使用 Trac plugin 来实现这种机制。
备注
Note that the Trac integration doesn't know anything about pull requests. So if you try to close a pull request with the phrase "closes #400" in your commit message, GitHub will close the pull request, but the Trac plugin will not close the same numbered ticket in Trac.
如果你只想要在提交信息中引用 Django ticket tracker 中的某个 ticket ，但并*不*想要关闭它时，可以使用 “Ref #xxxxx"，其中 "xxxxx" 是你的提交想引用的 ticket 的编号。这会触发系统自动的在被引用的 ticket 下发送一条评论。
使用此模式为后端端口编写提交消息：
[<Django version>] Fixed <ticket> -- <description>
Backport of <revision> from <branch>.
例如：
[1.3.x] Fixed #17028 -- Changed diveintopython.org -> diveintopython.net.
Backport of 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3 from main.
There's a script on the wiki to automate this.
如果提交修复了回归，请将其包含在提交消息中：
Regression in 6ecccad711b52f9273b1acb07a57d3f806e93928.
（使用引入回归的提交哈希）。
没有人是完美的；一些错误可能会被提交
But try very hard to ensure that mistakes don't happen. Just because we have a reversion policy doesn't relax your responsibility to aim for the highest quality possible. Really: double-check your work, or have it checked by another merger before you commit it in the first place!
当你发现了一个错误的提交，请遵循如下步骤：
git push upstream feature_antigravity`，那么做一个反向推送：git push upstream:feature_antigravity。5月 31, 2023