前些天发现了一个巨牛的人工智能学习网站，通俗易懂，风趣幽默，忍不住分享一下给大家。点击跳转到网站。

简介

为开源项目做贡献是一种有益的经验，因为您正在努力为最终用户（包括您自己）改进软件。一旦您提交了拉取请求，为了被接受，参与项目的过程可能需要一些重新基于和重写代码，然后进行分支的一般清理。

本教程将指导您在向开源软件项目提交拉取请求后可能需要采取的一些下一步操作。

先决条件

本教程将引导您完成提交拉取请求后的步骤，因此您应该已经安装了 Git，并且已经提交了或正在考虑创建拉取请求。

截至 2020 年 11 月，GitHub 移除了基于密码的身份验证。因此，您需要创建个人访问令牌或添加您的 SSH 公钥信息，以便通过命令行访问 GitHub 仓库。

要了解更多关于为开源项目做贡献的信息，您可以阅读这篇介绍。要了解如何提交拉取请求，请阅读“如何在 GitHub 上创建拉取请求”。

重新基于代码和清理注释

在为开源项目做贡献时，您可能会发现您的分支或拉取请求与上游代码之间存在冲突。您可能会在 shell 中收到类似以下的错误：

CONFLICT (content): Merge conflict in your-file.py
Automatic merge failed; fix conflicts and then commit the result.

或者在 GitHub 网站上的拉取请求中收到类似以下的错误：

!GitHub 拉取请求冲突

如果维护者一段时间内没有回应您的拉取请求，或者许多人同时为项目做出贡献，就可能会出现这种情况。当出现这种情况并且您仍然希望合并您的拉取请求时，您将需要解决冲突并重新基于您的代码。

重新基于 允许我们通过更改它们所基于的提交来移动分支。这样，我们可以重新基于我们的代码，使它们基于主分支的最新提交。重新基于应该谨慎进行，并且您应该确保在整个过程中使用正确的提交和正确的分支。我们还将在下面介绍使用 git reflog 命令，以防您出现错误。

与我们在拉取请求教程中所做的一样，我们将进入代码目录：

cd repository

接下来，您需要通过使用 git checkout 命令导航到正确的分支以确保您在正确的分支上：

git checkout new-branch

然后，运行 git fetch 获取最新的上游代码版本：

git fetch origin

一旦您获取了项目的上游版本，您可以通过压缩或重新编写提交消息来清理您的注释，以使它们更易于被项目维护者理解。如果您没有进行许多小的提交，则可能不需要这样做。

要开始此过程，您将执行一个交互式的重新基于。交互式重新基于 可用于编辑先前的提交消息，将多个提交合并为一个，或删除或撤消不再必要的提交。为此，我们需要能够通过编号或引用我们分支的基础的字符串来引用我们所做的提交。

要找出我们所做的提交数量，我们可以使用以下命令检查已对项目进行的总提交数量：

git log

这将为您提供类似于以下内容的输出：

commit 46f196203a16b448bf86e0473246eda1d46d1273
Author: username-2 <email-2>
Date:   Mon Dec 14 07:32:45 2015 -0400

    提交详情

commit 66e506853b0366c87f4834bb6b39d941cd034fe3
Author: username1 <email-1>
Date:   Fri Nov 27 20:24:45 2015 -0500

    提交详情

日志显示了对给定项目仓库的所有提交，因此您的提交将与其他人的提交一起列出。对于具有多个作者的广泛提交历史的项目，您将希望在命令中指定自己作为作者：

git log --author=your-username

通过指定此参数，您应该能够计算出您所做的提交数量。如果您正在处理多个分支，您可以在命令的末尾添加 --branches[=<branch>] 以限制按分支进行筛选。

现在，如果您知道您在要重新基于的分支上所做的提交数量，您可以运行 git rebase 命令，如下所示：

git rebase -i HEAD~x

在这里，-i 指的是交互式重新基于，HEAD 指的是主分支的最新提交。x 将是您自从最初获取它以来在您的分支上所做的提交数量。

然而，如果您不知道您在分支上所做的提交数量，您将需要找出哪个提交是您分支的基础，您可以通过运行以下命令来执行：

git merge-base new-branch main

此命令将返回一个称为提交哈希的长字符串，看起来类似于以下内容：

66e506853b0366c87f4834bb6b39d341cd094fe9

我们将使用此提交哈希传递给 git rebase 命令：

git rebase -i 66e506853b0366c87f4834bb6b39d341cd094fe9

对于上述任何一个命令，您的命令行文本编辑器将打开一个包含您分支中所有提交列表的文件，现在您可以选择是压缩提交还是重新编写它们。

合并提交

当我们合并提交消息时，我们将几个较小的提交合并或组合成一个较大的提交。

在每个提交前，你会看到“pick”这个词，所以如果你有两个提交，你的文件看起来会像这样：

pick a1f29a6 添加一个新功能
pick 79c0e80 这里是另一个新功能

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

现在，对于文件中除第一行外的每一行，你应该将“pick”这个词替换为“squash”以合并提交：

pick a1f29a6 添加一个新功能
squash 79c0e80 这里是另一个新功能

在这一点上，你可以保存并关闭文件，这将打开一个新文件，其中包含了所有提交的提交消息。你可以根据需要重新编写提交消息，然后保存并关闭文件。

一旦你关闭文件，你会收到反馈：

成功地 rebase 并更新了 refs/heads/new-branch。

现在，你已经通过合并提交将所有提交合并为一个。

重新编写提交

重新编写提交消息非常适合当你注意到拼写错误，或者意识到你没有为每个提交使用并行语言时。

一旦你使用 git rebase -i 命令执行交互式 rebase，你会看到一个打开的文件，内容如下：

pick a1f29a6 添加一个新功能
pick 79c0e80 这里是另一个新功能

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

现在，对于每个你想重新编写的提交，将“pick”替换为“reword”：

pick a1f29a6 添加一个新功能
reword 79c0e80 添加第二个新功能

# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

保存并关闭文件后，一个新的文本文件将出现在你的终端编辑器中，显示了修改后的提交消息。如果你想再次编辑文件，可以在保存并关闭文件之前这样做。这样可以确保你的提交消息是有用且统一的。

完成 rebase

一旦你满意于你所做的提交数量和相关的提交消息，你应该完成你的分支在项目最新上游代码的 rebase。为此，你应该从你的代码库目录运行以下命令：

git rebase origin/main

此时，Git 将开始将你的提交重新应用到 main 的最新版本上。如果在此过程中出现冲突，Git 将暂停并提示你在继续之前解决冲突。如果没有需要解决的内容，你的输出将会显示：

当前分支 new-branch 已经是最新的。

一旦你解决了冲突，你将运行：

git rebase --continue 

这个命令将告诉 Git 它现在可以继续重新应用你的提交。

如果你之前通过使用 squash 命令合并了提交，你只需要解决一次冲突。

使用强制推送更新拉取请求

一旦你执行了 rebase，你的分支历史将发生变化，你将无法再使用 git push 命令，因为直接路径已经被修改。

相反，我们将不得不使用 --force 或 -f 标志来强制推送更改，告诉 Git 你完全了解你正在推送的内容。

首先，让我们确保我们的 push.default 是 simple，这是 Git 2.0+ 中的默认设置，通过配置它来实现：

git config --global push.default simple

此时，我们应该通过检出我们正在工作的分支来确保我们在正确的分支上：

git checkout new-branch

已经在 'new-branch' 上
. . .

现在我们可以执行强制推送：

git push -f

现在你应该收到更新的反馈，以及这是一个“强制更新”的消息。你的拉取请求现在已经更新。

恢复丢失的提交

如果你在某个时候丢弃了一个你真正想要集成到更大项目中的提交，你应该能够使用 Git 来恢复你可能意外丢弃的提交。

我们将使用 git reflog 命令来找到我们丢失的提交，然后从该提交创建一个新分支。

Reflog 是 reference logs 的缩写，它记录了本地存储库中分支和其他引用的末端上次更新的时间。

从我们正在工作的代码存储库的本地目录中，我们将运行以下命令：

git reflog

运行此命令后，你将收到类似以下内容的输出：

46f1962 HEAD@{0}: checkout: moving from branch-1 to new-branch
9370d03 HEAD@{1}: commit: code cleanups
a1f29a6 HEAD@{2}: commit: brand new feature 
38f2fc2 HEAD@{3}: commit: remove testing methods 
. . .

你的提交消息将告诉你哪个提交是你留下的，相关的字符串将出现在终端窗口左侧的 HEAD@{x} 信息之前。

现在你可以使用这些信息从相关提交创建一个新分支：

git checkout -b new-new-branch a1f29a6

在上面的示例中，我们从上面显示的第三个提交创建了一个新分支，这个提交推出了一个“全新的功能”，用字符串 a1f29a6 表示。

根据你需要做什么，你可以按照拉取请求教程中的步骤设置你的分支，或者返回到当前教程的顶部，来完成新分支的 rebase。

代码审查中的预期结果

当您提交拉取请求时，您正在与一个更大的项目进行对话。提交拉取请求就像邀请其他人讨论您的工作一样，就像您自己正在讨论和参与更大的项目一样。为了进行成功的对话，重要的是您能够通过您的提交消息清楚地传达为什么您正在进行拉取请求，因此最好尽量准确和清晰。

拉取请求审查可能会因项目而异，可能会很长并且详细。最好将这个过程视为学习经验，也是您改进代码并使拉取请求更好并符合软件项目需求的好方法。审查应该允许您根据维护者的建议和指导自己进行更改。

拉取请求将记录审阅者的注释以及您一起进行的任何更新和讨论。在拉取请求被接受之前，您可能需要在此过程中进行多次额外的提交。这是完全正常的，并为您提供了作为团队一部分进行修订的好机会。

您的拉取请求将通过 Git 继续维护，并在整个过程中自动更新，只要您在同一分支上添加提交并将其推送到您的分支即可。

尽管您将自己的代码提交到更大的世界中供同行审查，但您不应该感到审查变得个人化，因此请务必阅读相关的CONTRIBUTION.md文件或行为准则。确保您的提交符合项目指定的准则是很重要的，但如果您开始感到不舒服，您正在工作的项目可能不值得您的贡献。在开源社区中有许多受欢迎的空间，虽然您可以期望您的代码受到严格的审视，但您收到的所有反馈都应该是专业和礼貌的。

拉取请求的接受和删除您的分支

如果您的拉取请求已被接受，您已成功为开源软件项目做出了贡献！

此时，您需要通过本地存储库将您所做的更改拉回到您的分支。这就是您在同步分支的过程中已经完成的操作。您可以在终端窗口中使用以下命令来执行此操作：

git checkout main
git pull --rebase origin main
git push -f origin main

现在，您应该清理本地和远程分支，删除您在两个地方创建的分支，因为它们不再需要。首先，让我们删除本地分支：

git branch -d new-branch

添加到git branch命令的-d标志将删除您传递给该命令的分支。在上面的示例中，它被称为new-branch。

接下来，我们将删除远程分支：

git push origin --delete new-branch

删除分支后，您已清理了存储库，并且您的更改现在位于主存储库中。请记住，因为您通过拉取请求所做的更改现在已成为主存储库的一部分，它们可能不会对下载公共发布的普通最终用户可用。一般来说，软件维护者会将几个新功能和修复捆绑到单个公共发布中。

结论

本教程带您完成了提交拉取请求到开源软件存储库后可能需要完成的一些后续步骤。

为开源项目做出贡献，并成为积极的开源开发者，通常是一种有益的经验。定期为您经常使用的软件做出贡献有助于确保它对其用户社区是有价值和有用的。