本部分针对提交者以及任何有兴趣了解如何为Django贡献代码的人员。 如果您是想向Django贡献代码的社区成员，请查看：doc：writing-code / working-with-git。
\n由于Django现在在GitHub上托管，因此大多数补丁都是以pull请求的形式提供的。
\n提交请求时，请确保每个单独的提交符合下面提到的提交准则。贡献者将尽可能提供最佳的请求。 然而，在实践中，提交者 - 谁可能更熟悉提交准则 - 可能会决定提交一个自己的提交标准。
\n您可能希望让Jenkins使用其中一个不自动运行的拉取请求构建器测试拉取请求，例如Oracle或Selenium。有关说明，请参阅Jenkins wiki页面。
\n你可以通过在"~/.gitconfig"文件中添加别名的方式来更简单地在本地获取新的pull request. (例如将"~/.gitconfig"中的upstream设置为"django/django"):
\n[alias]\n pr = !sh -c \\"git fetch upstream pull/${1}/head:pr/${1} && git checkout pr/${1}\\"\n现在你可以轻松地通过执行"git pr ####"来获取对应的pull request.
\n到了这个阶段,你可以着手于代码.使用"git rebase -i"和"git commit --ammend" 来确保你的提交准确无误. 一旦你准备好了:
\nLinux / macOS
$ # Pull in the latest changes from master.\n$ git checkout master\n$ git pull upstream master\n$ # Rebase the pull request on master.\n$ git checkout pr/####\n$ git rebase master\n$ git checkout master\n$ # Merge the work as "fast-forward" to master to avoid a merge commit.\n$ # (in practice, you can omit "--ff-only" since you just rebased)\n$ git merge --ff-only pr/XXXX\n$ # If you're not sure if you did things correctly, check that only the\n$ # changes you expect will be pushed to upstream.\n$ git push --dry-run upstream master\n$ # Push!\n$ git push upstream master\n$ # Delete the pull request branch.\n$ git branch -d pr/xxxx\nWindows
...\\> REM Pull in the latest changes from master.\n...\\> git checkout master\n...\\> git pull upstream master\n...\\> REM Rebase the pull request on master.\n...\\> git checkout pr/####\n...\\> git rebase master\n...\\> git checkout master\n...\\> REM Merge the work as "fast-forward" to master to avoid a merge commit.\n...\\> REM (in practice, you can omit "--ff-only" since you just rebased)\n...\\> git merge --ff-only pr/XXXX\n...\\> REM If you're not sure if you did things correctly, check that only the\n...\\> REM changes you expect will be pushed to upstream.\n...\\> git push --dry-run upstream master\n...\\> REM Push!\n...\\> git push upstream master\n...\\> REM Delete the pull request branch.\n...\\> git branch -d pr/xxxx\n在对master进行rebase之后但在合并并推送到上游之前强制推送到分支。这允许master和branch上的提交哈希值匹配，从而自动关闭pull请求。
\n如果拉请求不需要合并为多个提交，则可以在网页上使用Github的“挤压和合并”按钮。根据需要编辑提交消息以符合：ref:`The guidelines<committing-guidelines>`并删除自动附加到消息第一行的请求编号。
\n当重写pull请求的提交历史时，目标是使Django的提交历史尽可能可用：
\n如果补丁包含来回提交，则将其重写为一个。例如，如果提交添加了一些代码，第二个提交修复了第一次提交中引入的样式问题，那么这些提交应该在合并之前被压缩。
通过逻辑分组对不同提交进行单独更改：如果在对文件进行其他更改的同时进行样式清理，则将更改分成两个不同的提交将使查看历史记录变得更容易。
注意拉取请求中上游分支的合并。
测试应该通过，文档应该在每次提交后构建。测试和文档都不应该发出警告。
随意和小型的补丁通常最好在一次提交中完成。如果有意义，可以将中型到大型工作分成多个提交。
实用性胜过纯度，所以每个贡献者都要决定为拉取请求做多少历史记录。主要观点是参与社区，完成工作以及拥有可用的提交历史记录。
\n此外，在将代码提交到Django的Git存储库时，请遵循以下准则：
\n永远不要通过强制推动来改变“django / django``分支的已发布历史。如果您绝对必须（出于安全原因），请先与团队讨论情况。
对于任何根据您的判断“中到大”的变化，请在进行更改之前在django开发者邮件列表上提出。
\n如果你对Django开发人员提出了一些建议，但没有人回应，请不要认为这意味着你的想法很棒，应该立即实施，因为没有人反对。每个人都没有足够的时间立即阅读邮件列表讨论，因此您可能需要等待几天才能得到答复。
\n以过去时态写出详细的提交消息，而不是现在时。
\n正确："Fixed Unicode bug in RSS API."
错误："Fixes Unicode bug in RSS API."
错误："Fixing Unicode bug in RSS API."
提交消息最多应为72个字符。 应该有一个主题行，用空白行分隔，然后是72个字符行的段落。 限制很软。 对于主题行，越短越好。 在提交消息的主体中，更多细节优于更少：
\nFixed #18307 -- Added git workflow guidelines.\n\nRefactored the Django's documentation to remove mentions of SVN\nspecific tasks. Added guidelines of how to use Git, GitHub, and\nhow to use pull request together with Trac instead.\n如果补丁不是拉请求，您应该在提交消息中对贡献者进行评价：“感谢A提供报告，B提供补丁，C提供审查。”
\n对于提交到分支，请在提交消息前面加上分支名称。例如：“[1.4.x]Fixed XXXX——增加了对思维阅读的支持。”
限制承诺最细微的变化是有意义的。这意味着，使用频繁的小额承诺，而不是很少的大额承诺。例如，如果实现功能X需要对库Y做一个小的更改，那么首先将更改提交到库Y，然后在单独的提交中提交功能X。这对帮助每个人跟踪你的变化有很大的帮助。
将错误修复与功能更改分开。根据：ref:supported versions policy，可能需要将错误修复返回到稳定分支。
If your commit closes a ticket in the Django ticket tracker, begin\nyour commit message with the text "Fixed #xxxxx", where "xxxxx" is the\nnumber of the ticket your commit fixes. Example: "Fixed #123 -- Added\nwhizbang feature.". We've rigged Trac so that any commit message in that\nformat will automatically close the referenced ticket and post a comment\nto it with the full commit message.
\nFor the curious, we're using a Trac plugin for this.
\nIf your commit references a ticket in the Django ticket tracker but\ndoes not close the ticket, include the phrase "Refs #xxxxx", where "xxxxx"\nis the number of the ticket your commit references. This will automatically\npost a comment to the appropriate ticket.
使用此模式为后端端口编写提交消息：
\n[<Django version>] Fixed <ticket> -- <description>\n\nBackport of <revision> from <branch>.\n例如：
\n[1.3.x] Fixed #17028 -- Changed diveintopython.org -> diveintopython.net.\n\nBackport of 80c0cbf1c97047daed2c5b41b296bbc56fe1d7e3 from master.\nThere's a script on the wiki\nto automate this.
\n如果提交修复了回归，请将其包含在提交消息中：
\nRegression in 6ecccad711b52f9273b1acb07a57d3f806e93928.\n（使用引入回归的提交哈希）。
\n没有人是完美的；一些错误可能会被提交
\n但要努力确保错误不会发生。仅仅因为我们有一个退换货政策，并不能放松你的责任，使你的目标尽可能达到最高的质量。真的：仔细检查你的工作，或者让另一个提交者检查它，在你首先提交它**之前**！
\n当你发现了一个错误的提交，请遵循如下步骤：
\n可能的话，让原始作者撤回他们的提交。
不要在未获得原始作者同意的情况下还原其他作者的更改。
Use git revert -- this will make a reverse commit, but the original\ncommit will still be part of the commit history.
If the original author can't be reached (within a reasonable amount\nof time -- a day or so) and the problem is severe -- crashing bug,\nmajor test failures, etc. -- then ask for objections on the\ndjango-developers mailing list then revert if there are none.
If the problem is small (a feature commit after feature freeze,\nsay), wait it out.
If there's a disagreement between the committer and the\nreverter-to-be then try to work it out on the django-developers\nmailing list. If an agreement can't be reached then it should\nbe put to a vote.
If the commit introduced a confirmed, disclosed security\nvulnerability then the commit may be reverted immediately without\npermission from anyone.
The release branch maintainer may back out commits to the release\nbranch without permission if the commit breaks the release branch.
If you mistakenly push a topic branch to django/django, just delete it.\nFor instance, if you did: git push upstream feature_antigravity,\njust do a reverse push: git push upstream :feature_antigravity.