git 恢复 远程分支,在Git中重新设置远程分支

I am using an intermediate Git repository to mirror a remote SVN repository, from which people can clone and work on. The intermediate repository has it's master branch rebased nightly from the upstream SVN, and we are working on feature branches. For example:

remote:

master

local:

master

feature

I can successfully push my feature branch back to the remote, and end up with what I expect:

remote:

master

feature

local:

master

feature

I then re-setup the branch to track the remote:

remote:

master

feature

local:

master

feature -> origin/feature

And all is well. What I would like to do from here is to rebase the feature branch to the master branch on the remote, but I would like to do this from my local machine. I'd like to be able to do:

git checkout master

git pull

git checkout feature

git rebase master

git push origin feature

To keep the remote feature branch up-to-date with the remote master. However, this method causes Git to complain:

To

! [rejected] feature -> feature (non-fast-forward)

error: failed to push some refs to ''

To prevent you from losing history, non-fast-forward updates were rejected

Merge the remote changes (e.g. 'git pull') before pushing again. See the

'Note about fast-forwards' section of 'git push --help' for details.

git pull does the trick but causes a merge commit that I'd like to avoid. I'm concerned that the message states feature -> feature rather than feature -> origin/feature but this may just be a presentation thing.

Am I missing something, or going about this in completely the wrong way? It's not critical to avoid doing the rebase on the remote server, but it makes fixing any merge conflicts from the rebase much harder.

解决方案

It comes down to whether the feature is used by one person or if others are working off of it.

You can force the push after the rebase if it's just you:

git push origin feature -f

However, if others are working on it, you should merge and not rebase off of master.

git merge master

git push origin feature

This will ensure that you have a common history with the people you are collaborating with.

On a different level, you should not be doing back-merges. What you are doing is polluting your feature branch's history with other commits that don't belong to the feature, making subsequent work with that branch more difficult - rebasing or not.

This is my article on the subject called branch per feature.

Hope this helps.