@bef0rewind #43
「如果 merge 的话是用最后一个 commit 去 merge ，rebase 的话从最早的一个 commit 开始 rebase 。所以冲突结果可能不一样。」
那我大概知道为啥 merge 没冲突但是 rebase 有冲突了。

我平常都是 pull rebase ，没怎么用过 fetch

@tromoli #41
他们是解决冲突完了已经并且 commit 了

@xiaoming1992 #37
是，我搞不清楚为啥 pull merge 没冲突 pull rebase 有

@nothingistrue #39
最后是找的本地最新的人把代码推上去的，有没有先拉再推，有没有强制推，他们现在也不记得了。。。

@nothingistrue #34
所以说远程分支落后本地的话，直接拿本地的代码 push --force 就行了吗？然后别的人再 pull 后解决自己的冲突再 push 就可以了？

@FACEB00K #29
他们当时应该是已经 continue 了，找我去看的时候已经有 rebase 的 commit 了

@DeWjjj #26
我们现在是 dev ，每个人都从 dev 拉分支最后再合过去。

@daimubai #23
以前公共分支拉的时候都 rebase 成一条直线了，这次弄了以后不敢 rebase 了，可是 merge 的话也太乱了吧

@nothingistrue #19
「远程分支回滚后的那个 Head ，它之后的（在回滚前）所有提交，不管是本地的还是远程的，都被搞废了」
远程的被破坏我能理解，为什么说本地的也被破坏了呢？

「你现在本地仓库上的远程仓库引用 origin/master 跟真是的远程仓库 master 分支可能都不一样」
仓库地址我没有改过，为什么 还能不一样呢？

请大佬解惑

@raykle #8
感谢大佬分享

@xiaoming1992 #14
不明白为啥 pull rebase 会丢掉本地的 commit ，rebase 不是会生成新的 commit 吗

@shawndev #13
rebase 教程都是合并分支时候，这种远程分支落后的情况下 pull rebase 我确实是蒙了

@FACEB00K #12
他们已经解决完冲突 commit 了，所以没法 abort 了，git log 也没找到前几天的本地 commit

@unco020511 #9
同一个分支的本地和远程

@nothingistrue #10
push --force 是因为远程分支被回滚了，落后了本地分支。用 2 以后本地的提交好多都没了

@raykle #6
自己搭的什么？类似 code push 吗？

@Felldeadbird #5
pull merge 没冲突，pull rebase 有冲突，这是为啥啊。
您说的这种新建分支再合过去我觉得是合理的，也好理解。

#7
我们都是 dev 开发，然后每个人都有自己的 dev-xx 分支，然后去往 dev 合，就很乱。。。

@raykle #3
@Parabolazz #4
两位大佬用的都是 code push 吗？

@han777 #1
您这个是一个好办法，如果代码改动太多的话应该也不小工作量吧。有没有更好的办法呢？

@Jooooooooo #2
push 之前不都是先 pull 的吗？不知道这次为什么 pull rebase 以后本地的代码也没了。rebase 不是会生成新的 commit 吗？

@efcndi #1
我就是不理解，这不应该是局域网吗？


@lixiang2017 #2
@usbusbc #3
用的是 iPhone ，只不过是在公司。家里的 250 G 电脑空间也不太够就想着上班给弄了，结果一直没完。现在就一个一个还原了。。。