git 我的拉取请求已合并，下一步该怎么做？

My pull request has been merged, what to do next?

提问by Santosh Kumar

I recently participated in a project from GitHub. I did the following:

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

Forked the original repository, cloned it to my local machine, made a branch to fix existing bug, fixed bug being in that branch, pushed that branch to my repo, send a pull request to the author of the repository to merge my fixbranch to its master branch.

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

It was my first time I commited on another's code so I don't know what to do. Now my pull request has been merged to original repo/project by the author.

这是我第一次提交别人的代码，所以我不知道该怎么做。现在我的 pull request 已被作者合并到原始 repo/project 中。

What should I do next?Should I delete the branch? Should I merge the branch? Anything else?

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

---

---

Additional info:

附加信息：

The original project has a single branch.

原始项目只有一个分支。

I also have a upstream set to get latest updates form the original repo. (I did it like this):

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

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

And I get updates like this:

我得到这样的更新：

git fetch upstream

采纳答案by VonC

What to do next is: going on contributing new features or fixing other bugs in their own dedicated branches (pushed only to your fork).

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

Meaning your fork stays, but the branches within your fork can come and go.

这意味着您的叉子会保持不动，但叉子内的分支可以来来去去。

You can also remove the fork if you are not planning to contribute further, but it will remove the corresponding entry in 'Repositories you contribute to'.

如果您不打算进一步贡献，您也可以删除分叉，但它会删除 'Repositories 您贡献的' 中的相应条目。

It is easier to:

更容易：

• delete your fixbranch (actually, it is now deleted for you) on your fork (and in your local cloned repo: see "Delete a Git branch both locally and remotely")
• git pull upstream master(if masterwas the branch in which your fix has been integrated: the merge will be a fast-forward one): no rebase needed at this point.
• recreate a fix branch on top of your updated local master(now with the latest from upstream master).

• 在您的 fork 上删除您的fix分支（实际上，它现在已经为您删除了）（以及在您本地克隆的存储库中：请参阅“在本地和远程删除 Git 分支”）
• git pull upstream master（如果master是您的修复程序已集成到的分支：合并将是快进的）：此时不需要变基。
• 在更新的本地master（现在使用最新的 from upstream master）之上重新创建修复分支。

---

---

However, never forget one step before submitting any futurepull request:

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

rebase first your current branch (fix) from upstream destination branch

首先fix从上游目标分支重新设置当前分支 ( )

(upstreambeing the original repo you have forked: see "What is the difference between origin and upstream in github")

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

Before submitting anything back to the original repo ("upstream"), you need to make sure your work is based on top of the latestfrom said original repo (or the pull-request won't result in a fast-forward merge once applied back on upstreamrepo).
See, for instance, "Workflow for managing pull requests on shared repos in github".

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

In other words, upstreamcan evolve (have new commits pushed on it) while you are busy fixing stuff. You need to replay your fixes on top of that latest work from upstream to make sure your commits are still compatible with the latest of upstream.

换句话说，upstream可以在您忙于修复东西的同时进化（有新的提交推送）。您需要在上游的最新工作之上重放您的修复程序，以确保您的提交仍然与最新的upstream.

---

---

The OP Santosh Kumarasks in the comments:

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

I have pulled and merged from upstreamto master, now what?

我已经拉取并合并upstream到主人，现在怎么办？

If you haven't made any new fixes since your recent pull request, see above (delete and recreate an new branch fixon top of your updated master).

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

If you have done any more work since your pull request, I wouldn't merge from upstreamif I want to make a newpull request: I would pull and rebase:

如果您在拉取请求之后做了更多的工作，upstream如果我想提出一个新的拉取请求，我不会合并：我会拉取和变基：

git pull --rebase upstream master

That way, all my new local work is replayed on top of the most recent upstreammastercommits (fetched in my local repo), supposing that masteris the target branch that will integrate my future pull request.

这样，我所有新的本地工作都会在最近的upstreammaster提交（在我的本地存储库中获取）之上重放，假设这master是将集成我未来拉取请求的目标分支。

Then I can push my local work to 'origin', which is my fork on GitHub of upstream.
And from my fork on GitHub, I can safely make a pull request, knowing that it will only add new commits to upstreamwithout needing any merge resolution: merging those new commits in upstreamrepo will mean a simple fast-forward merge.

然后我可以将我的本地工作推送到 ' origin'，这是我在upstream.
从我在 GitHub 上的 fork，我可以安全地发出拉取请求，知道它只会添加新的提交upstream而不需要任何合并解析：在upstreamrepo 中合并这些新提交将意味着一个简单的快进合并。

---

---

A git pull --rebasewithout specifying the branch on top of which you want to rebase your (currently checked out) fixbranch wouldn't work:

Agit pull --rebase没有指定要在其上重新设置（当前签出的）fix分支的分支将不起作用：

That (git pull --rebase) says:

那 ( git pull --rebase) 说：

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

Should I append master at last? And what will this do?, will it delete my fixbranch?

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

Yes, you can specify the branch which will be the target of the pull request, for instance 'master'.
That will not delete your fixbranch, but will replay it on top of upstream masterfetched in your repo.

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

回答by Philipp

First, congratulations for your first contribution to a project on Github.

首先，祝贺你对 Github 上的一个项目做出的第一个贡献。

The usual Github workflow is to create a new branch for every problem you solve. That way the maintainer of the mainline repository can decide which one of your solutions to merge and which one to reject. After a branch got merged upstream, the branch won't be needed anymore and can usually be deleted.

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