我最近参加了GitHub的一个项目。我做了以下事情：
分叉原始存储库，将其克隆到我的本地机器上，创建一个分支来修复现有的错误，修复该分支中的错误，将该分支推送到我的repo，向存储库的作者发送拉取请求，将我的修复分支合并到其主分支。
这是我第一次提交别人的代码，所以我不知道该怎么办。现在我的pull请求已经被作者合并到原始repo/project中。
我下一步该怎么办我应该删除分支吗？我应该合并分支吗？还有别的吗？
其他信息：
原始项目只有一个分支。
我还有一个上游集合，可以从原始回购中获取最新更新(我是这样做的)：
git remote add upstream https://path/to/original/repo.git
我得到这样的更新：
git fetch upstream
下一步要做的是：继续贡献新功能或在自己的专用分支中修复其他bug(仅推送到您的fork)。
这意味着你的叉子可以停留，但叉子里的树枝可以来来去去。
如果你不打算进一步贡献，你也可以删除fork，但它会删除"你贡献的存储库"中的相应条目。
更容易：
- 在你的fork上删除你的
fix分支(实际上，它现在已经为你删除了)(在你的本地克隆repo中：请参阅"本地和远程删除Git分支") git pull upstream master(如果master是集成了修复程序的分支：合并将是一个快速的分支)：此时不需要重新设置基础- 在更新的本地
master(现在是upstream master的最新版本)之上重新创建修复分支
但是，在提交任何未来拉取请求之前，永远不要忘记一个步骤：
首先从上游目的地分支机构重新设置当前分支机构(fix)的基础
(upstream是您分叉的原始回购：请参阅"github中的原始回购和上游回购之间的区别")
在将任何内容提交回原始回购("上游")之前，您需要确保您的工作是基于所述原始回购的最新(否则，撤回请求一旦应用回upstream回购就不会导致快进合并)
例如，请参阅"管理github中共享转发请求的工作流"。
换言之，当您忙于修复内容时，upstream可以进化(在其上推送新的提交)。您需要在上游最新工作的基础上重新进行修复，以确保您的提交仍然与最新的upstream兼容。
OP Santosh Kumar在评论中问道：
我已经从
upstream拉合并到master，现在怎么办？
如果自最近的拉取请求以来，您还没有进行任何新的修复，请参阅上文(在更新的master之上删除并重新创建一个新的分支fix)。
如果你在拉取请求后做了更多的工作，如果我想发出新的拉取请求，我不会从upstream合并：我会拉取并重新建立基础：
git pull --rebase upstream master
这样，我所有新的本地工作都会在最近的upstreammaster提交(在我的本地repo中获取)之上重播，假设master是将集成我未来的pull请求的目标分支。
然后我可以将我的本地工作推送到"origin"，这是我在upstream的GitHub上的分支
从我在GitHub上的fork，我可以安全地发出pull请求，因为我知道它只会向upstream添加新的提交，而不需要任何合并解决方案：在upstreamrepo中合并这些新的提交将意味着一个简单的快进合并。
git pull --rebase如果不指定要在其上重新建立(当前已签出)fix分支基础的分支，则无法工作：
(
git pull --rebase)说：
You asked to pull from the remote '`upstream`', but did not specify a branch.
我最后应该追加master吗？这会有什么作用？，它会删除我的
fix分支吗？
是的，您可以指定将成为拉取请求目标的分支，例如"master">
这不会删除您的fix分支，但会在回购中提取的上游master之上重播。
首先，祝贺您对Github项目的第一次贡献。
Github通常的工作流程是为您解决的每个问题创建一个新的分支。这样，主线存储库的维护者就可以决定合并哪个解决方案，拒绝哪个解决方案。分支在上游合并后，就不再需要该分支，通常可以删除该分支。