关于git rebase 后 push rejected

stackoverflow上的一个帖子，楼主和后面的回答都详细到位，很好的解释了这个问题

总结git rebase：这是一个 更改历史 的操作，所以不要指望你改了历史然后就顺利把你篡改够的历史提交上去。

PS:pro git 上的一句话：

“永远不要衍合那些已经推送到公共仓库的更新。
如果你遵循这条金科玉律,就不会出差错。否则,人民群众会仇恨你,你的朋友和家人也
会嘲笑你,唾弃你。”      看到这句话你大概就知道该怎么用了。至少不会用坏。

http://stackoverflow.com/questions/8939977/git-push-rejected-after-feature-branch-rebase

1楼

OK, I thought this was a simple git scenario, what am I missing?

I have a master branch and a feature branch. I do some work on master, some on feature, and then some more on master. I end up with something like this (lexicographic order implies order of commits):

A--B--C------F--G
       \    
        D--E

I have no problem to git push origin master to keep the remote master updated, nor with git push origin feature (when on feature) in order to maintain a remote backup for my featurework. Up until now, we're good.

But now I wanna rebase feature on top of the F--G commits on master, so I git co featureand git rebase master. Still good. Now we have:

A--B--C------F--G
                 \
                  D--E

(yeah, I know, it's actually D' and E'.)

Problem: the moment I want to backup the new rebased feature branched with git push origin feature, the push is rejected since the tree has changed due to the rebasing. This can only be solved with git push --force origin feature.

I hate using --force without being sure I need it. So, do I need it? Does the rebasing necessarilyimply that the next push should be --forceful?

This feature branch is not shared with any other devs, so I have no problem de facto with the forced push, I'm not gonna lose any data, the question is more conceptual.

2楼

The problem is that git push assumes that remote branch can be fast-forwarded to your local branch, that is that all the difference between local and remote branches is in local having some new commits at the end like that:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

When you perform git rebase commits D and E are applied to new base and new commits are created. That means after rebase you have smth like that:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

In that situation remote branch can't be fast-forwarded to local. Though, theoretically local branch can be merged into remote (obviously you don't need it in that case), but as git push performs only fast-forward merges it throws and error.

And what --force option does is just ignoring state of remote branch and setting it to the commit you're pushing into it. So git push --force origin feature-branch simply overridesorigin/feature-branch with local feature-branch.

In my opinion, rebasing feature branches on master and force-pushing them back to remote repository is ok as long as you're the only one who works on that branch.

3楼

One solution to this is to do what msysGit's rebasing merge script does - after the rebase, merge in the old head of feature with -s ours. You end up with the commit graph:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... and your push of feature will be a fast-forward.

In other words, you can do:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(Not tested, but I think that's right...)

4楼

What is wrong with a git merge master on the feature branch? This will preserve the work you had, while keeping it separate from the mainline branch.

A--B--C------F--G
       \         \
        D--E------H

Edit: Ah sorry did not read your problem statement. You will need force as you performed a rebase. All commands that modify the history will need the --force argument. This is a failsafe to prevent you from losing work (the old D and E would be lost).

So you performed a git rebase which made the tree look like (although partially hidden as D andE are no longer in a named branch):

A--B--C------F--G
       \         \
        D--E      D'--E'

So, when trying to push your new feature branch (with D' and E' in it), you would lose D and E.

5楼

Other's have answered your question. If you rebase a branch you will need to force to push that branch.

Rebase and a shared repository generally do not get along. This is rewriting history. If others are using that branch or have branched from that branch then rebase will be quite unpleasant.

In general, rebase works well for local branch management. Remote branch management works best with explicit merges (--no-ff).

We also avoid merging master into a feature branch. Instead we rebase to master but with a new branch name (e.g adding a version suffix). This avoids the problem of rebasing in the shared repository.