我的拉取请求已合并，接下来要做什么？
我最近参加了GitHub的一个项目。 我做了以下几点：
分叉原始的存储库，克隆到我的本地机器，build立了一个分支来修复现有的错误，修正了该分支中的错误，将该分支推送到我的回购站，向存储库的作者发送拉取请求，其主分支。
这是我第一次犯他人的代码，所以我不知道该怎么做。 现在我的拉请求已经合并到作者原始的回购/项目。
接下来我应该做什么？ 我应该删除分支吗？ 我应该合并分支吗？ 还要别的吗？
附加信息：
原始项目有一个分支。
我也有一个上游设置从原始回购得到最新的更新。 （我这样做） ：
git remote add upstream https://path/to/original/repo.git 我得到像这样的更新：
git fetch upstream
接下来要做的是：继续提供新function或修复其专用分支中的其他错误（仅推送到您的分支）。
意思是你的叉子留下来，但叉子里的枝条可以来去。
如果您不打算进一步捐款，也可以删除分支，但是它会删除“您捐献的资料库”中的相应条目 。
更容易：
- 删除你的
fix分支（实际上， 现在已经删除了 ）在你的分支（和你本地的克隆回购：请参阅“ 本地和远程删除一个Git分支 ”） -
git pull upstream master（如果master是你的修复已被整合的分支：合并将是一个快速的）：在这一点上不需要rebase。 - 在更新的本地
master（现在使用来自upstream master的最新版本）之上重新创build修复分支。
但是，在提交任何未来的请求之前，请不要忘记一步。
首先把你当前的分支（ fix ）从上游的目的地分支重新绑定
（ upstream是您分叉的原始回购：请参阅“ github中的起源和上游之间的区别 ”）
在将任何内容提交回原始仓库（“上游”）之前，您需要确保您的工作基于最初的仓库仓库中的最新仓库（或者，一旦应用，抽取请求不会导致快速合并回upstream回购）。
例如，请参阅“ 用于在github中pipe理共享回购站上的请求的工作stream程 ”。
换句话说，在你忙于修理东西的时候， upstream可以进化（有新的提交）。 您需要在上游的最新工作之上重播您的修补程序，以确保您的提交仍与最新的upstream兼容。
OP Santosh Kumar 在评论中问道：
我已经从
upstream拉到合并师傅，现在呢？
如果自从最近的请求发出后没有做任何新的修复，请参阅上面的内容（删除并重新创build一个新的分支fix到最新的fix之上）。
如果你的pull请求已经做了更多的工作，如果我想提出一个新的pull请求，我将不会从upstream合并：我将pull 和rebase ：
git pull --rebase upstream master
这样，我所有新的本地工作都在最近的upstream master提交（在本地回购中提取）之上重播，假设master是将要集成未来请求的目标分支。
然后我可以把我的本地工作推到“ origin ”，这是我在upstream GitHub上的分支。
从我在GitHub上的fork中，我可以安全地做出一个pull请求，知道它只会向upstream添加新的提交而不需要任何合并解决scheme：在upstream repo中合并这些新的提交将意味着一个简单的快速合并。
一个没有指定你想重新绑定你的（当前签出的） fix分支的分支的git pull --rebase行不通的：
那（
git pull --rebase）说：
You asked to pull from the remote '`upstream`', but did not specify a branch.
我应该最后追上主人吗？ 这将做什么？它会删除我的
fix分支？
是的，您可以指定将作为拉取请求目标的分支，例如“ master ”。
这不会删除您的fix分支，但会在您的回购库中获取的上游master上重播。
首先，恭喜你第一次参与Github的项目。
通常的Github工作stream程是为你解决的每个问题创build一个新的分支。 这样，主线库的维护者可以决定合并哪个解决scheme，哪个解决scheme被拒绝。 分支合并到上游后，分支将不再需要，通常可以删除。
