发布工作¶

您可以通过运行以下命令在 GitHub 上发布您的工作

git push origin ticket_xxxxx

转到您的 GitHub 页面时，您会注意到已创建了一个新分支。

如果您正在处理 Trac 问题，则应在问题中提到您的工作可从 GitHub 仓库的 ticket_xxxxx 分支获得。包含指向您分支的链接。

请注意，上述分支在 Git 行话中称为“主题分支”。您可以通过使用 git rebase 等方式重写此分支的历史记录。其他人不应基于此类分支进行工作，因为当您编辑提交时，他们的克隆将变得损坏。

还有“公共分支”。这些是其他人应该分叉的分支，因此这些分支的历史记录不应该改变。公共分支的良好示例是 django/django 仓库中的 main 和 stable/A.B.x 分支。

当您认为您的工作已准备好被拉入 Django 时，您应该在 GitHub 上创建一个拉取请求。一个好的拉取请求意味着

• 每个提交包含一个逻辑更改，遵循 编码风格，

• 每个提交都具有格式良好的消息：一个摘要行，然后是之后换行到 72 个字符的段落——有关更多详细信息，请参阅 提交指南，

• 如有必要，请提供文档和测试——实际上，除了文档更改之外，始终需要测试。

测试套件必须通过，并且文档必须在没有警告的情况下构建。

创建拉取请求后，您应该在相关的 Trac 问题中添加一条评论，说明您做了什么。特别是，您应该注意运行测试的环境，例如：“所有测试在 SQLite 和 MySQL 下都通过”。

GitHub 上的拉取请求只有两种状态：打开和关闭。将处理您的拉取请求的合并者只有两个选项：合并它或关闭它。因此，在代码准备好合并之前（或足够接近合并者自己完成它）创建拉取请求是没有意义的。

变基分支¶

在上面的示例中，您创建了两个提交，“修复 ticket_xxxxx”提交和“添加了两个更多测试”提交。

我们不希望在您的仓库中包含整个工作流程的历史记录。您的提交“添加了两个更多测试”将是无用的噪声。相反，我们宁愿只拥有一个包含所有工作的提交。

要重做分支的历史记录，您可以使用交互式变基将提交压缩为一个

git rebase -i HEAD~2

上面的 HEAD~2 是两个最新提交的简写。上述命令将打开一个编辑器，显示两个提交，并在前面加上“pick”一词。

将第二行的“pick”更改为“squash”。这将保留第一个提交，并将第二个提交压缩到第一个提交中。保存并退出编辑器。应该会打开第二个编辑器窗口，以便您可以在提交消息中重新措辞提交，因为现在它包含了您的两个步骤。

您也可以在变基中使用“edit”选项。这样您就可以更改单个提交，例如修复文档字符串中的错别字

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。

变基命令会暂时删除所有本地提交，应用上游提交，然后再次在上游工作上应用本地提交。

如果存在合并冲突，您需要解决它们，然后使用 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 仓库。由于您在变基期间没有触及公共提交，因此您不应该需要强制推送

git push origin ticket_xxxxx

您的拉取请求现在也应该包含新的提交。

请注意，合并者在提交代码时可能会将审查提交压缩到上一个提交中。