我的拉取请求已合并，下一步该怎么做? [英] My pull request has been merged, what to do next?

问题描述

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

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

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

接下来我该怎么做?我应该删除分支吗?我应该合并分支吗?还有什么?

<小时>

附加信息:

原始项目只有一个分支.

我还有一个上游集，可以从原始存储库中获取最新更新.(我就是这样做的):

git 远程添加上游 https://path/to/original/repo.git

我收到这样的更新:

git fetch 上游

解决方案

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

意思是你的叉子不动，但叉子里的树枝可以来来去去.

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

更容易:

• 删除您的 fix 分支(实际上，现在已经为您删除了) 在您的 fork 上(以及在您本地克隆的存储库中:请参阅在本地和远程删除 Git 分支")
• git pull upstream master(如果 master 是你的修复被集成的分支:合并将是一个快进的):不需要 rebase这一点.
• 在更新的本地 master 之上重新创建一个修复分支(现在使用来自 upstream master 的最新版本).

<小时>

然而，在提交任何未来拉取请求之前，永远不要忘记一个步骤:

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

(upstream 是您分叉的原始存储库:请参阅github中的origin和upstream有什么区别")

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

换言之，upstream 可以在您忙于修复东西的同时发展(将新的提交推送到它上面).您需要在上游的最新工作之上重放您的修复程序，以确保您的提交仍然与最新的上游 兼容.

<小时>

OP Santosh Kumar 问在评论中:

<块引用>

我已经从 upstream 拉取并合并到 master，现在呢?

如果您在最近的拉取请求之后没有进行任何新的修复，请参见上文(在更新的 master 之上删除并重新创建一个新的分支 fix).

如果您在拉取请求后还做了更多工作，如果我想创建一个新拉取请求，我不会从 upstream 合并:我会拉 和rebase:

git pull --rebase upstream master

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

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

<小时>

一个 git pull --rebase 没有指定你想要在其上重新设置你的(当前检出的)fix 分支的分支是行不通的:<块引用>

那个 (git pull --rebase) 说:

您要求从远程上游"拉取，但未指定分支.

<块引用>

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

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

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

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 fix branch 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.

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

解决方案

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'.

It is easier to:

• delete your fix branch (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 master was 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).

---

However, never forget one step before submitting any future pull request:

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

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

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

In other words, upstream can 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.

---

The OP Santosh Kumar asks in the comments:

I have pulled and merged from upstream to master, now what?

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

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

git pull --rebase upstream master

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

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 upstream without needing any merge resolution: merging those new commits in upstream repo will mean a simple fast-forward merge.

---

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

That (git pull --rebase) says:

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 fix branch?

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

这篇关于我的拉取请求已合并，下一步该怎么做?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！