tl;dr
如果只有你一个人在一个分支上工作，完全可以从origin pull再rebase，紧着着用git push --force解决push分支时被reject的问题。
我工作的时候经常碰到这个问题：同事的pull request被merge到develop，我pull回来，把本地feature分支rebase到develop上，到这一步没有任何问题。但是如果我在这个rebase之前已经把一些本地feature分支的commits push到我的fork，那这些fork上的commits就会reject rebase之后的push了。用git push --force确实可以解决这个问题，不过总感觉这个并不必要的--force好可怕。
然后我就在stackoverflow上看到了完全相同的这个问题，被采纳的答案消除了我害怕用--force的疑惑。这个回答下面的第一条评论确实也可以解决这个问题，但是就会有完全一样的commits重复出现一次，在git log里看起来实在不好看。
我想大家可能也碰到过这个问题，所以把这个问题和回答分享在这里，希望会有帮助。
bearzk
 | 1 palxex Jan 17, 2015 git push --force对个人自己用的feature分支确实没啥问题。但如果是多人合作的分支……我估计其他人pull时会有问题吧？ |
 | 2 ZackYang Jan 17, 2015 呃，奇妙的衍合也并非完美无缺，要用它得遵守一条准则： 一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。 如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。 来自: http://git-scm.com/book/zh/v1/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E8%A1%8D%E5%90%88 |
 | 3 ushuz Jan 17, 2015 git push -f 时请小心，最好写上分支名。 |
 | 4 ery Jan 17, 2015 git push origin HEAD --force 强制推送当前分支到服务器上 |
 | 5 bcxx Jan 17, 2015 > 我pull回来，把本地feature分支rebase到develop上 你先在 develop 上合并了 remote 的 develop 再去 rebase 自己的 feature 应该会好点吧？ 我一般都是不在本地（自己）的 develop 里面进行 rebase，而是通过 pr 到 remote 并且 merge 之后再在本地 fast forward 过去…… rebase 的确只适合在本地操作啊，多几个 merge commit 也比搞砸了啊~ |
 | 9 fgwww Jan 17, 2015 via iPad 不要变基 |
 | 10 bearzk OP @bcxx 谢谢 我下次按照你说的想想再来一遍 也许因为我们都在自己的fork上工作..同事的pr被merge到upstream develop以后我会pull upstream develop再rebase分支到develop 不过这时会提示pull 照做的话就会有些重复的（尽管hash不同）的commits了 |
 | 12 old9 Jan 17, 2015  1 我觉得 --force 没什么可怕的，因为你的本地分支一旦 rebase ，他就不是以前的他了，以前的他已经烟消云散，那么远程服务器上的对应分支也失去了意义，自然要被（而且应该要被） --force 给替换掉。 这种私有的 branch，大胆 --force 好了。 如果不是私有 branch，那就压根不应该 rebase。如果一个协作用的 branch 需要经常 rebase，那一定是你们的工作流程有问题。 |
 | 13 comcuter Jan 17, 2015 @old9 如果是多个人需要在同一个仓库上的同一个分支上进行开发呢? 你的意思是每个人尽量多开 feature 分支, 然后 merge 到 develop 上去? |
Select Language