我的拉取请求已合并,下一步该怎么办？

Question

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

分叉原始存储库,克隆到我的本地机器,建立一个分支来修复现有的bug,修复了该分支中的bug,将该分支推送到我的repo,向存储库的作者发送pull请求以合并我的fix分支到它的主要分支.

这是我第一次提交另一个代码,所以我不知道该怎么做.现在我的pull请求已被作者合并到原始repo/project.

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

---

附加信息:

原始项目有一个分支.

我还有一个上游设置,以获得原始回购的最新更新.(我是这样做的):

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

我得到这样的更新:

git fetch upstream

Answer 1

接下来要做的是:继续提供新功能或修复自己专用分支中的其他错误(仅推送到您的分支).

意思是你的叉子停留,但叉子里的树枝可以来来去去.

如果您不打算进一步贡献,也可以删除分叉,但它会删除"您贡献的存储库"中的相应条目.

它更容易:

• 删除您的fix分支(实际上,它现在已被删除)在您的分支上(并在您的本地克隆仓库中:请参阅" 在本地和远程删除Git分支 ")
• git pull upstream master(如果master是您的修复已经集成的分支:合并将是一个快进的分支):此时不需要rebase.
• 在更新的本地master(现在使用最新版本upstream master)之上重新创建修复分支.

但是,在提交任何未来的拉取请求之前,永远不要忘记一步:

首先fix从上游目标分支重新绑定当前branch()

(upstream作为您分叉的原始回购:请参阅" github中的原始和上游之间的区别 ")

在将任何内容提交回原始仓库("上游")之前,您需要确保您的工作基于所述原始仓库的最新工作(或者拉动请求一旦应用就不会导致快速合并回到upstream回购).
例如,请参阅" 在github中管理共享存储库上的拉取请求的工作流程 ".

换句话说,upstream当你忙于修复东西的时候,可以进化(有新的提交).您需要在上游的最新工作之上重放您的修复程序,以确保您的提交仍然与最新的提交兼容upstream.

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

我已经拉到并合并upstream到主人,现在怎么样？

如果您自最近的拉取请求后未进行任何新修复,请参阅上文(删除并fix在更新后重新创建新分支master).

如果你在拉取请求后已经做了更多的工作,upstream如果我想提出一个新的拉取请求,我就不会合并:我会拉动和变换:

git pull --rebase upstream master

这样,所有我的新本地工作都会在最近的upstream master提交(在我的本地仓库中提取)之上重放,假设这master是将集成我未来的pull请求的目标分支.

然后我可以把我的本地工作推到' origin',这是我在GitHub上的分支upstream.
从我在GitHub上的分支,我可以安全地发出一个pull请求,知道它只会添加新的提交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在您的仓库中提取的上游重播它.

Answer 2

首先,祝贺您对Github项目的第一次贡献.

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