我的请求请求已合并，下一步该怎么办？

我最近参加了GitHub的一个项目。我做了以下事情：

分叉原始存储库，将其克隆到我的本地计算机，创建一个分支来修复现有的错误，修复该分支中的错误，将该分支推送到我的仓库中，向存储库的作者发送拉取请求以将我的修订分支合并到它的主分支。

这是我第一次提交别人的代码，所以我不知道该怎么做。现在，我的拉取请求已被作者合并到原始回购/项目中。

接下来我该怎么办？我应该删除分支吗？我应该合并分支吗？还要别的吗？

附加信息：

原始项目只有一个分支。

我还有一个上游设备，可以从原始存储库获取最新更新。（我这样做是这样的）：

git remote add upstream https://path/to/original/repo.git

我得到这样的更新：

git fetch upstream

接下来要做的是：继续贡献新功能或修复自己专用分支中的其他错误（仅在您的分支上推送）。

意味着您的叉子停留了，但是叉子中的分支可以来去去了。

如果您不打算进一步捐款，也可以删除该分支，但是它将删除“您捐款的存储库”中的相应条目。

更容易：

• 删除叉子上的fix分支（实际上，现在已经为您删除了）（在本地克隆的仓库中：请参阅“ 在本地和远程删除Git分支 ”）
• git pull upstream master（如果master是集成了您的修订的分支：合并将是一个快速的分支）：此时无需重新设置基准。
• 在更新后的本地上重新创建一个修订分支master（现在有来自的最新版本upstream master）。

但是，在提交任何将来的拉取请求之前，请不要忘记第一步：

首先fix从上游目标分支重新建立当前分支（）

（这是upstream您分叉的原始存储库：请参阅“ github的原始和上游有什么区别 ”）

在将任何内容提交回原始存储库（“上游”）之前，您需要确保您的工作基于所述原始存储库的最新内容（否则拉取请求一旦应用便不会导致快速合并重新upstream回购）。
例如，请参阅“ 用于管理github中共享存储库上的拉取请求的工作流 ”。

换句话说，upstream当您忙于修复某些东西时，它会不断发展（已经提交了新的提交）。您需要从上游重播最新的修补程序，以确保您的提交仍与的最新版本兼容upstream。

该OP桑托斯·库马尔要求在评论：

我已经从upstream大师那里合并了，现在呢？

如果自从最近的请求请求以来没有进行任何新的修复，请参阅上文（fix在更新的顶部删除并重新创建一个新分支master）。

如果自请求请求以来您已完成其他工作，那么upstream如果要提出新的请求，就不会合并：我会进行合并并变基：

git pull --rebase upstream master

这样，我所有的本地新作品都会在最近的作品上重播 upstream master提交（在我的本地仓库中获取）的基础，假设这master是将集成我将来的请求请求的目标分支。

然后，我可以将本地工作推送到' origin'，这是我在的GitHub上的分支upstream。
从GitHub上的分叉，我可以放心地发出拉取请求，因为它只会将新的提交添加到upstream而无需任何合并解析：将这些新的提交合并到upstreamrepo中将意味着简单的快速合并。

一个 git pull --rebase没有指定哪个你想衍合上顶部的分支（当前已签出）fix分支是行不通的：

（git pull --rebase）说：

You asked to pull from the remote '`upstream`', but did not specify a branch. 

我应该最后追加主人吗？这将做什么？它将删除我的fix分支吗？

是的，您可以指定将成为拉取请求目标的分支，例如“ master”。
那不会删除您的fix分支，但是会master在您的仓库中获取的上游重播它。

首先，祝贺您为Github上的一个项目所做的第一笔贡献。

Github通常的工作流程是为您解决的每个问题创建一个新分支。这样，主线存储库的维护者可以决定合并哪个解决方案和拒绝哪个解决方案。分支合并到上游后，不再需要该分支，通常可以将其删除。