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 2015-01-17 09:50:13 +08:00
git push --force对个人自己用的feature分支确实没啥问题。但如果是多人合作的分支……我估计其他人pull时会有问题吧?
|
2
ZackYang 2015-01-17 09:57:54 +08:00
呃,奇妙的衍合也并非完美无缺,要用它得遵守一条准则:
一旦分支中的提交对象发布到公共仓库,就千万不要对该分支进行衍合操作。 如果你遵循这条金科玉律,就不会出差错。否则,人民群众会仇恨你,你的朋友和家人也会嘲笑你,唾弃你。 来自: 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 2015-01-17 10:00:46 +08:00
git push -f 时请小心,最好写上分支名。
|
4
ery 2015-01-17 10:22:31 +08:00
git push origin HEAD --force
强制推送当前分支到服务器上 |
5
bcxx 2015-01-17 10:29:32 +08:00
> 我pull回来,把本地feature分支rebase到develop上
你先在 develop 上合并了 remote 的 develop 再去 rebase 自己的 feature 应该会好点吧? 我一般都是不在本地(自己)的 develop 里面进行 rebase,而是通过 pr 到 remote 并且 merge 之后再在本地 fast forward 过去…… rebase 的确只适合在本地操作啊,多几个 merge commit 也比搞砸了啊~ |
9
fgwww 2015-01-17 10:42:21 +08:00 via iPad
不要变基
|
10
bearzk OP @bcxx 谢谢 我下次按照你说的想想再来一遍 也许因为我们都在自己的fork上工作..同事的pr被merge到upstream develop以后我会pull upstream develop再rebase分支到develop 不过这时会提示pull 照做的话就会有些重复的(尽管hash不同)的commits了
|
12
old9 2015-01-17 10:55:32 +08:00 1
我觉得 --force 没什么可怕的,因为你的本地分支一旦 rebase ,他就不是以前的他了,以前的他已经烟消云散,那么远程服务器上的对应分支也失去了意义,自然要被(而且应该要被) --force 给替换掉。
这种私有的 branch,大胆 --force 好了。 如果不是私有 branch,那就压根不应该 rebase。如果一个协作用的 branch 需要经常 rebase,那一定是你们的工作流程有问题。 |
13
comcuter 2015-01-17 11:04:04 +08:00
@old9 如果是多个人需要在同一个仓库上的同一个分支上进行开发呢?
你的意思是每个人尽量多开 feature 分支, 然后 merge 到 develop 上去? |