我的拉取请求已合并，接下来要做什么？ [英] My pull request has been merged, what to do next?

问题描述

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

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

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

接下来应该做什么？我应该删除分支吗？我应该合并分支吗？还有其他什么？

---

附加信息：

原始项目有一个分支。

我还有一个上游设置，可以从原始回购获取最新更新。 ：

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

我得到如下更新：

  git fetch upstream 
  

解决方案

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

意思是你的叉子保持不变，但叉子内的分支可以来去。

如果您不打算进一步提供捐款，也可以移除分支，但它会删除'您捐献的资料库'中的相应条目。

更容易：

• 删除您的修复分支（实际上， 现在它已被删除 ）在叉子上（以及在本地克隆的repo中：请参阅删除本地和远程的Git分支）


• git pull upstream master （if master 是您的修补程序已被集成的分支：合并将是一个快速转换的分支）：此时不需要转义。


• 在更新后的本地 master （现在使用最新的 upstream master ）重新创建修补分支。

---

然而，ne在提交任何 future 请求之前，请先忘记一步：

/ code>）来自上游目的地分行

（上游已分叉：请参阅什么是github上的起源和上游之间的区别）

在将任何内容提交回原始回购（上游）之前，您需要确保您的工作是基于来自所述原始repo的 latest 的顶部（或者拉回请求不会导致一旦在上游上应用了快进合并> repo）。

例如，参见用于管理github中共享回购站的请求的工作流程。

换句话说，在你忙于修改东西的时候， upstream 可以发展（在它上面推新的提交）。您需要在上游的最新工作之上重播您的修补程序，以确保您的提交与最新的上游兼容。

---

OP Santosh Kumar 要求在评论中：

我已经从上游拉到并合并为master，现在呢？

如果您最近的pull请求后没有做任何新的修复，请参阅上文（删除并重新创建一个新分支修正在您更新的 master 之上）。 如果您有如果我想创建一个新的请求，我不会从上游进行合并：我会将和rebase ：

  git pull --rebase upstream master 
  

这样，我所有新的本地作品都会在最近的上游 master 提交（在本地仓库中提取），假设 master 是将要集成未来请求的目标分支。

然后我可以把我的本地工作推到' origin '，这是我在<$ c的GitHub上的分支$ c> upstream 。

从我在GitHub上的fork中，我可以安全地发出pull请求，知道它只会添加新的提交到上游，而不需要任何合并解析：合并那些在上游 repo中的新提交将意味着一个简单的快速合并。

---

A git pull --rebase 其中，您希望重新绑定您的（当前已检出）修复分支无法正常工作：

（ git pull --rebase ）说：

 你要求从远端的'上游'拉，但没有指定分支。 
  

我应该最后追加主人吗？它会做什么？它会删除我的修复程序分支吗？

是的，您可以指定将成为拉请求目标的分支，例如' master '。

这不会删除您的 fix 分支，但会在您的回购中提取的上游 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屋！