This section explains how the community can contribute code to Django via pull\nrequests. If you're interested in how committers handle them, see\n提交代码.
\nBelow, we are going to show how to create a GitHub pull request containing the\nchanges for Trac ticket #xxxxx. By creating a fully-ready pull request, you\nwill make the reviewer's job easier, meaning that your work is more likely to\nbe merged into Django.
\n您也可以将传统的补丁程序上传到 Trac ，但对于评论来说不太实用。
\nDjango uses Git for its source control. You can download Git, but it's often easier to install with\nyour operating system's package manager.
\nDjango的 Git 仓库 托管在 GitHub 上，建议您也使用GitHub。
\nAfter installing Git, the first thing you should do is setup your name and\nemail:
\n$ git config --global user.name "Your Real Name"\n$ git config --global user.email "you@email.com"\n请注意， user.name 应该是您的真实姓名，而不是您的GitHub昵称。 GitHub应该知道您在 user.email 字段中使用的电子邮件，因为这将用于将提交与GitHub账户相关联。
When you have created your GitHub account, with the nick "GitHub_nick", and\nforked Django's repository,\ncreate a local copy of your fork:
\ngit clone https://github.com/GitHub_nick/django.git\nThis will create a new directory "django", containing a clone of your GitHub\nrepository. The rest of the git commands on this page need to be run within the\ncloned directory, so switch to it now:
\ncd django\n在 Git 中，你的 Github 仓库会被称做“origin”。
\nYou should also setup django/django as an "upstream" remote (that is, tell\ngit that the reference Django repository was the source of your fork of it):
git remote add upstream git@github.com:django/django.git\ngit fetch upstream\n您可以类似地添加其他远程仓库，例如：
\ngit remote add akaariai git@github.com:akaariai/django.git\nWhen working on a ticket, create a new branch for the work, and base that work\non upstream/master:
\ngit checkout -b ticket_xxxxx upstream/master\n-b 参数在本地为您创建一个新分支。 即使是最小的事情，也不要犹豫创建新分支——这就是它们的用途。
\n相反，如果您正在1.4分支上进行修复，则可以执行以下操作：
\ngit checkout -b ticket_xxxxx_1_4 upstream/stable/1.4.x\nAssume the work is carried on the ticket_xxxxx branch. Make some changes and\ncommit them:
\ngit commit\n编写提交消息时，请遵循提交 commit message guidelines 以简化提交者的工作。 如果您不习惯使用英语，请尝试至少准确描述提交的功能。
\n如果您需要在分支上执行其他工作，请根据需要多次提交：
\ngit commit -m 'Added two more tests for edge cases'\nYou can publish your work on GitHub by running:
\ngit push origin ticket_xxxxx\nWhen you go to your GitHub page, you will notice a new branch has been created.
\nIf you are working on a Trac ticket, you should mention in the ticket that\nyour work is available from branch ticket_xxxxx of your GitHub repo. Include a\nlink to your branch.
\n请注意，在Git中，上述分支称为“主题分支”。 您可以自由地重写该分支的历史记录，例如，使用 git rebase 变更基本。 其他人不应在这样的分支上进行工作，因为当您编辑提交时，他们的副本会损坏。
There are also "public branches". These are branches other people are supposed\nto fork, so the history of these branches should never change. Good examples\nof public branches are the master and stable/A.B.x branches in the\ndjango/django repository.
当您准备将工作成果并入Django时，应在GitHub上创建一个pull请求。好的拉取请求要求：
\n按照:doc:coding style <coding-style> ，每个提交都进行一次逻辑更改，
每次提交的格式正确的消息：摘要行，其后以72个字符包装的段落——有关详细信息，请参见 committing guidelines 。
如果需要，带有文档和测试——实际上一直需要测试，除了文档更改外。
测试套件必须通过，并且文档的构建必须没有警告。
\nOnce you have created your pull request, you should add a comment in the\nrelated Trac ticket explaining what you've done. In particular, you should note\nthe environment in which you ran the tests, for instance: "all tests pass\nunder SQLite and MySQL".
\nPull requests at GitHub have only two states: open and closed. The committer\nwho will deal with your pull request has only two options: merge it or close\nit. For this reason, it isn't useful to make a pull request until the code is\nready for merging -- or sufficiently close that a committer will finish it\nthemselves.
\nIn the example above, you created two commits, the "Fixed ticket_xxxxx" commit\nand "Added two more tests" commit.
\n我们不想在您的代码库中拥有您工作过程的全部历史记录。您的提交“添加了两个以上的测试”将毫无助益。相反，我们只希望一次提交包含您的所有工作。
\n要重做分支的历史记录，可以使用交互式rebase将提交压缩为一个：
\ngit rebase -i HEAD~2\n上面的 HEAD~2 是最近两次提交的简写。 上面的命令将打开一个编辑器，显示两个提交，前缀为 "pick" 。
\nChange "pick" on the second line to "squash" instead. This will keep the\nfirst commit, and squash the second commit into the first one. Save and quit\nthe editor. A second editor window should open, so you can reword the\ncommit message for the commit now that it includes both your steps.
\n您还可以在rebase中使用“编辑”选项。这样，您可以更改单个提交，例如修复文档字符串中的错字：
\ngit rebase -i HEAD~3\n# Choose edit, pick, pick for the commits\n# Now you are able to rework the commit (use git add normally to add changes)\n# When finished, commit work with "--amend" and continue\ngit commit --amend\n# Reword the commit message if needed\ngit rebase --continue\n# The second and third commits should be applied.\nIf your topic branch is already published at GitHub, for example if you're\nmaking minor changes to take into account a review, you will need to force-push\nthe changes:
\ngit push -f origin ticket_xxxxx\nNote that this will rewrite history of ticket_xxxxx - if you check the commit\nhashes before and after the operation at GitHub you will notice that the commit\nhashes do not match anymore. This is acceptable, as the branch is a topic\nbranch, and nobody should be basing their work on it.
\nWhen upstream (django/django) has changed, you should rebase your work. To\ndo this, use:
git fetch upstream\ngit rebase\nThe work is automatically rebased using the branch you forked on, in the\nexample case using upstream/master.
rebase命令暂时删除所有本地提交，应用上游提交，然后在工作上再次应用本地提交。
\nIf there are merge conflicts, you will need to resolve them and then use git\nrebase --continue. At any point you can use git rebase --abort to return\nto the original state.
请注意，您想在上游 变基 ，而不是 合并 上游。
\n这样做的原因是，通过重新定基，您的提交将始终在上游工作的*基础*上，而不是与上游所做的更改*混合在一起*。这样，您的分支将只包含与其主题相关的提交，这使得压缩更加容易。
\n在审核者未要求更改的情况下，将任何不重要的代码放入内核是很不正常的。 在这种情况下，通常最好将更改添加为对工作的一次增量提交。 这使审阅者可以轻松地检查您所做的更改。
\n在这种情况下，请执行审阅者要求的更改。 尽可能频繁地提交。 在发布更改之前，请重新设定工作基础。 如果添加了两个提交，则将运行：
\ngit rebase -i HEAD~2\n将第二个提交压缩为第一个。 按照以下内容编写提交消息：
\nMade changes asked in review by <reviewer>\n\n- Fixed whitespace errors in foobar\n- Reworded the docstring of bar()\nFinally, push your work back to your GitHub repository. Since you didn't touch\nthe public commits during the rebase, you should not need to force-push:
\ngit push origin ticket_xxxxx\n您的拉取请求现在也应该包含新的提交。
\n请注意，提交者在提交代码时可能会将审阅提交压缩为先前的提交。
\nOne of the ways that developers can contribute to Django is by reviewing\npatches. Those patches will typically exist as pull requests on GitHub and\ncan be easily integrated into your local repository:
\ngit checkout -b pull_xxxxx upstream/master\ncurl https://github.com/django/django/pull/xxxxx.patch | git am\nThis will create a new branch and then apply the changes from the pull request\nto it. At this point you can run the tests or do anything else you need to\ndo to investigate the quality of the patch.
\nFor more detail on working with pull requests see the\nguidelines for committers.
\n如果可以，请在GitHub上工作。
通过链接到您的GitHub分支来宣布您在Trac工单上的工作。
准备就绪后，请提出拉取请求。
使您的拉取请求尽可能地好。
在对您的工作进行修复时，请使用 git rebase -i 压缩提交。
当上游发生变化时，请执行 git fetch upstream; git rebase。