Git将我的分叉分支在上游主服务器上

Question

A certain user on Github has a repository with single master branch. I have forked that repository into my own account. I have created a new branch on my own forked repository and have commited some changes to it.

The upstream user has commited changes to their master. I wish to update my master with those changes. Additionally, if I understand rebase correctly, I want to rebase my branch on that master. I do not want to merge with master because I have not finished developing my branch. Note: The files changed by upstream are different from the files I have changed in my branch, so there should not be an conflicts.

I have tried the following:

I pulled changes from the upstream user into my local repo:
git pull upstream master

I pushed changes from my local master into my forked master:
git push origin master

I rebased my local branch on my local master:
git checkout mybranch
git rebase master

I attempted to push my rebased local branch to my forked branch:
git push origin mybranch

However, I get the following error:

To https://github.com/myusername/myforkedrepository.git
 ! [rejected]        mybranch -> mybranch (non-fast-forward)
error: failed to push some refs to 'https://github.com/myusername/myforkedrepository.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Note that origin is my forked repository and upstream is the original repositrory.

There is similar question on stackoverflow that suggested a slightly simpler method:

git fetch upstream
git rebase upstream/master

This did not give any errors, but it has also not pushed anything to my remote fork. After trying the above, I again tried

git push origin mybranch

but the same error persisted.

How would I go about doing what I want?

Answer 1

This is how I understand your scenario:

[upstream repo] ==> [forked repo] <==> [local repo]
   master               master            master
                                          mybranch

_{The arrows indicate the directional flow of commits.}

And given the above you've asked how do you implement your desired dev flow of keeping your changes always on top.

Overall it is inevitable for the master on both the forked and local repos to deviate from the upstream master , if they are is to incorporate the changes on the mybranch topic branch.

However, when the changes are completely disjoint, as you outline in the question, you can indeed keep your set of changes on top by rebasing and fast-forwarding, when you merge or pull.

0] local master   $ branch mybranch off master 
    1] fork  master   $ git pull --rebase
    2] local master   $ git pull --rebase
    3] local mybranch $ commit commit commit
    4] local mybranch $ git rebase master

Repeat 1-4 or just 3-4 as many times as necessary in your dev flow. When you are ready to publish your work to the forked repo master , the upstream master and the forked master will go out of sync, but as long as you've followed 1-4 you should be able to forever keep your changes on top.

5] local master $ git merge --ff-only mybranch
    6] local master $ git push origin

And then repeat 1-4 again as many times as necessary.

A word of caution. In order for this to work you may need to reset your branches (or maybe re-clone your repos) to a "clean" state, where you haven't merged and/or pushed yet any of the changes on mybranch to a local or forked master .

Answer 2

This is because you already published your mybranch branch before this.

The solution is simple: Just don't. You want to changed published history, which is never a good idea! This could lead to really ugly bugs for other developers who already based work on your public mybranch branch.

---

A technical solution would be: git push --force origin mybranch or deleting the remote branch and pushing it again with git push origin :mybranch and git push origin mybranch

But you don't should do this if mybranch is already published.