这一节解释了社区如何通过拉请求向Django贡献代码。如果您对如何 mergers 处理它们，请参见 提交代码 。
下面，我们将展示如何创建一个包含trac票据XXXXX更改的Github拉取请求。通过创建一个完全准备好的请求，您将使审阅者的工作更容易，这意味着您的工作更有可能被合并到Django中。
您也可以将一个传统的补丁上传到trac，但是对于评论来说，它不太实用。
Django使用 Git 用于其源代码管理。你可以 download 但使用操作系统的软件包管理器安装起来通常比较容易。
Django Git repository 托管在 GitHub ，建议您也使用GitHub。
安装Git后，您应该做的第一件事是设置您的姓名和电子邮件：
$ git config --global user.name "Your Real Name"
$ git config --global user.email "you@email.com"
注意 user.name 应该是你的真名，而不是你的Github尼克。GitHub应该知道你在 user.email 字段，因为这将用于将您的提交与GitHub帐户关联。
当您创建了您的GitHub帐户，其昵称为“GitHub_Nick”，并且 forked Django's repository ，创建分叉的本地副本：
git clone https://github.com/GitHub_nick/django.git
这将创建一个新目录“Django”，其中包含GitHub存储库的克隆。本页上的其余git命令需要在克隆的目录中运行，因此现在切换到该目录：
cd django
您的GitHub存储库将在Git中称为“源站”。
您还应该设置 django/django 作为“上游”远程(也就是说，告诉git参考Django存储库是您的分支的来源)：
git remote add upstream https://github.com/django/django.git
git fetch upstream
您可以类似地添加其他遥控器，例如：
git remote add akaariai https://github.com/akaariai/django.git
处理票据时，为该工作创建一个新分支，并将其作为工作的基础 upstream/main ：
git checkout -b ticket_xxxxx upstream/main
-b标志在本地为您创建一个新的分支。即使是对最小的事物也要毫不犹豫地创建新的分支——这就是它们存在的目的。
相反，如果您正在为1.4分支的修复程序而工作，您将执行以下操作：
git checkout -b ticket_xxxxx_1_4 upstream/stable/1.4.x
假设工作在Ticket_xxxxx分支上进行。进行一些更改并提交它们：
git commit
在编写提交消息时，请遵循 commit message guidelines 以减轻合并的工作负担。如果您对英语感到不舒服，请至少尝试准确地描述提交所做的事情。
如果您需要在分支机构上执行其他工作，请根据需要经常提交：
git commit -m 'Added two more tests for edge cases'
您可以通过运行以下命令在GitHub上发布您的工作：
git push origin ticket_xxxxx
当您转到Github页面时，您会注意到一个新的分支已经创建。
如果您正在处理trac票据，您应该在票据中提到您的工作可以从Github回购的分支票据_xxxxx获得。包括指向分支的链接。
注意，上面的分支在git术语中称为“主题分支”。您可以使用 git rebase 例如。其他人不应该将他们的工作建立在这样一个分支上，因为当您编辑提交时，他们的复制会损坏。
还有“公共分支机构”。这些是其他人应该分叉的树枝，所以这些树枝的历史永远不应该改变。公共分支的很好的例子是 main 和 stable/A.B.x 中国的分支机构 django/django 存储库。
当您认为您的工作已经准备好被拉入Django时，您应该在Github创建一个拉请求。良好的拉动请求意味着：
提交，每个提交中都有一个逻辑更改，遵循 coding style ，
每个提交的格式良好的消息：一个摘要行，然后以72个字符换行--请参见 committing guidelines 有关详细信息，
如果需要，文档和测试——实际上，除了文档更改之外，总是需要测试。
测试套件必须通过，并且文档必须在没有警告的情况下生成。
创建拉请求后，应在相关的TRAC通知单中添加注释，解释您所做的操作。尤其要注意运行测试的环境，例如：“所有测试都在sqlite和mysql下通过”。
GitHub的拉取请求只有两种状态：打开和关闭。将处理您的Pull请求的合并只有两个选项：合并或关闭。出于这个原因，在代码准备好合并--或者足够接近合并将自己完成它之前--发出拉请求是没有用的。
在上面的示例中，您创建了两个提交，“Fixed Ticket_xxxxx”提交和“Added Two More Tests”提交。
我们不希望在您的存储库中保存您工作过程的整个历史记录。你的承诺“再增加两个测试”将是无用的噪音。相反，我们希望只有一个包含所有工作的提交。
要修改分支的历史记录，您可以使用交互式REBASE将提交压缩为一个：
git rebase -i HEAD~2
上面的头2是最近两次提交的简写。上面的命令将打开一个编辑器，显示两个提交，前缀为“pick”。
将第二行的“pick”改为“squash”。这将保持第一个提交，并将第二个提交压缩为第一个提交。保存并退出编辑器。应该打开第二个编辑器窗口，这样您就可以重新编写提交消息了，因为它包含了两个步骤。
你也可以在Rebase中使用“编辑”选项。这样，您可以更改单个提交，例如修复文档字符串中的拼写错误：
git rebase -i HEAD~3
# Choose edit, pick, pick for the commits
# Now you are able to rework the commit (use git add normally to add changes)
# When finished, commit work with "--amend" and continue
git commit --amend
# Reword the commit message if needed
git rebase --continue
# The second and third commits should be applied.
如果你的主题分支已经在GitHub上发布了，例如，如果你为了考虑到一篇评论而做了一些微小的改变，你将需要强制执行这些改变：
git push -f origin ticket_xxxxx
注意，这将重写ticket_xxxxx的历史记录-如果您在GitHub上检查操作前后的提交哈希，您会发现提交哈希不再匹配。这是可以接受的，因为这个分支是一个主题分支，任何人都不应该以它为工作基础。
当上游时 (django/django )已经改变了，你应该重新定位你的工作。要执行此操作，请使用：
git fetch upstream
git rebase upstream/main
使用您派生的分支自动重新设置工作的基数，在本例中使用 upstream/main 。
REBASE命令临时删除所有本地提交，应用上游提交，然后在工作中再次应用本地提交。
如果存在合并冲突，则需要解决这些冲突，然后使用 git rebase --continue . 在任何时候你都可以使用 git rebase --abort 回到原来的状态。
注意你想 重碱 在上游，不是 合并 上游。
这样做的原因是，通过重新平衡，你的承诺将永远是 在顶部 上游的工作，不是 混入 上游的变化。这样，您的分支将只包含与其主题相关的提交，这使得挤压更加容易。
在没有审阅者请求更改的情况下，将任何数量不重要的代码放入核心是不常见的。在这种情况下，将更改作为一个增量提交添加到您的工作中通常是一个好主意。这允许审阅者轻松检查您所做的更改。
在这种情况下，请按照审阅者的要求进行更改。只要有必要，就经常做出承诺。在发布更改之前，请重新设置您的工作的基准。如果添加了两个提交，您将运行：
git rebase -i HEAD~2
将第二次提交挤入第一次提交。编写一条提交消息，内容如下：
Made changes asked in review by <reviewer>
- Fixed whitespace errors in foobar
- Reworded the docstring of bar()
最后，将您的工作推回到您的GitHub存储库。由于您在rebase过程中没有触及公共提交，因此您应该不需要强制推送：
git push origin ticket_xxxxx
您的请求请求现在也应该包含新的提交。
请注意，在提交代码时，合并很可能会将审查提交挤入前一次提交。
开发人员可以为Django做出贡献的方式之一是审查补丁。这些补丁通常作为GitHub上的Pull请求存在，并且可以轻松地集成到您的本地存储库：
git checkout -b pull_xxxxx upstream/main
curl -L https://github.com/django/django/pull/xxxxx.patch | git am
这将创建一个新的分支，然后将拉请求中的更改应用到它。此时，您可以运行测试或者做任何其他需要做的事情来调查补丁的质量。
有关使用拉入请求的更多详细信息，请参阅 guidelines for mergers 。
如果可以，可以在Github上工作。
通过链接到您的Github分支机构，在Trac票据上宣布您的工作。
当你准备好了什么，提出一个请求。
尽可能地提出拉车请求。
在对工作进行修复时，请使用 git rebase -i 压制承诺。
当上游发生变化时， git fetch upstream; git rebase .
12月 18, 2023