贡献于 github 上的项目,如何“将我的 pull 请求置于 master 之上”

好的,我在 Github 上为一个项目做贡献。在 github 上的项目是 upstream,我在 github 上的分叉回购是 origin,我在计算机上的 local回购。

git checkout -b feature
# Working on feature
git commit -a -m 'only commit on feature'

然后我提交一个请求

git push origin master

拉请求将被审查,并且需要进行一个不相关的更改。其他人进行提交并合并到 upstream/master

现在我被 upstream维护人员要求到 “将我的拉动请求置于 master 之上”

这是我的故事(插入法律和秩序的声音效果) ..。

我没有对 pull 请求做任何更改,它仍然是分支上的提交特性。

git checkout master
git fetch upstream
git checkout feature
git rebase master
=> "Current branch feature is up to date."
git push origin feature
=> "Everything up-to-date"

我不明白。当我知道有人提交并合并到 upstream/master后,我把我的拉请求到 origin/feature时,这怎么可能?

有人能告诉我在这种情况下正确的程序应该是什么吗?

34082 次浏览

You only show a fetch on the upstream repo. That doesn't actually update any of your local branches. It only updates your knowledge of upstream. You'd need to ensure upstream/master is fully merged into your master, like with a git pull, prior to rebasing onto master, or more simply just rebase onto upstream/master.

I.e:

git checkout master
git pull upstream master
git checkout feature
git rebase master

or

git checkout feature
git fetch upstream master
git rebase upstream/master

Update:

After fixing your local feature branch, you'll need to push it back to origin to finish updating the pull request. Since you've pushed feature once already, you can't simply push again because a rebase changes history, and it's no long a fast-forward. Normally, whan a push fails with a "non-fast-forward", you'd resolve it by doing a pull, but a pull will just combine the two divergent histories, which is definitely not what you want. That would mean your old (pre rebase) feature branch would be combined with the new (post rebase) one. You want to overwrite origin/feature with the state of the new feature branch, dumping any record of the old one. That means you'll want to force the push to happen, even though it's not a fast-forward, using git push -f origin feature. Note: force pushing is origin0, and you can lose commits with it. Only use it if you're absolutely sure you know what you're doing, like right here, where you intentionally want to drop the old, useless commits in the pre-rebase feature branch.

Now I am asked by the upstream maintainer to "rebase my pull request on top of master"

Note that since Sept. 2016, the maintainer can trigger the rebase himself/herself.

See "Rebase and merge pull requests"

When you select the new "Rebase and merge" option, the commits from the pull request's branch are rebased on to the tip of the base branch, and then the base branch itself is fast forwarded to this newly rebased head. Rebases automatically set the committer of the rebased commits to the current user, while keeping authorship information intact. The pull request's branch will not be modified by this operation.

If a rebase can't be performed due to conflicts, we'll let you know so you can manually resolve them as necessary.

https://cloud.githubusercontent.com/assets/2195/18671961/a03fa9b6-7f35-11e6-8fa0-e16b2fede8ca.gif