Contributing to project on github, how to "rebase my pull request on top of master"
GitGithubGit Problem Overview
Ok so I an contributing to a project on github. The project on github is upstream
, my forked repo on github is origin
, and my local
repo on my computer.
git checkout -b feature
# Working on feature
git commit -a -m 'only commit on feature'
then I submit a pull request
git push origin master
The pull request is reviewed and a unrelated change needs to be made. Someone else makes a commit and merge into upstream/master
Now I am asked by the upstream
maintainer to "rebase my pull request on top of master"
This is my story (insert Law and Order sound effect).....
I did not make any changes to the pull request and its still the same commit on branch feature.
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"
I don't understand. How is this possible when I know that someone committed and merged to upstream/master
after I pushed my pull request to origin/feature
?
Can anyone tell me what the correct procedure should be in this situation?
Git Solutions
Solution 1 - Git
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 dangerous, 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.
Solution 2 - Git
> 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.