要么就是让 bob 别 push，先把 feature 回退到仓库的样子。

不过不大清楚你这里预期想让仓库变成啥样。

@randyzhao

最好的预期是 A-B-C-D'-E'
其次的预期是 A-B-C-D'-D-E

粗略看了下原文，这个图是作者用来举反例的。
这里犯了两个错误：
1. Bob 不应该和 Anna 同时工作在 feature branch 上，应该分别 checkout 新的分支开发。
2. Bob 不应该在 feature branch 上执行 rebase master 的操作而且还 push 上去了。
解决办法就是两人都停下来，等 Anna 解决完冲突后同步一下。

Bob 在已知 github 的状态的情况下，不应该做这个把 feature 从 D rebase 成 D'的操作（已经 push 到 remote 的 commit 不应该 rebase ），更不需要解决 Anna 的什么东西（因为 Anna 的 E 压根没有 push，Bob 也不可能得知 E 的信息）

rebase 更多解决的是 Anna 线 push E 到 github，Bob 同时（未拉取最新修改）在 D 上 commit 了变更 F 后，发现 push 失败

此时用 rebase 把 ABDF 变成 ABDEF 再 push,使 feature branch 的结果为一直线，避免增加 merge commit

@will0404

抱歉,我想问一下,相同版本的功能不应该开发在同一分支吗? 开发在同一分支的好处是一个功能可以让两个人开发,互相可以看互相的代码.

顺便，这个过程的实际操作是 git fetch && git rebase （取代 git pull ），现在 git pull 增加了 `--rebase` 开关可以直接用

@mcfog
您好,一个场景是 Bob 在 rebase master 的时候,Anna push 了自己代码到远程分支, Bob rebase 完毕后 再 push 时会失败..

@fov6363 我觉得你没看我的回答

@mcfog
我看了...我理解你的观点是开发时候不要这么做.....现在的场景是 Bob 已经这么做了,所以我想是否有更好的解决办法...

Anna：我什么都没干啊，操作也很规范啊。

所以如果我是 Leader，就让 Anna 正常 push 先，让 Bob 自尝苦果，下次他就不会乱来了。

@randyzhao
good idea

论 pr 的重要性

Anna 的代码过期了，Anna 先搞好。再提交。

@fov6363 已经那么干了的话先让他认识到问题，然后 feature 分支直接 reset 回到 origin/feature 即可，如果 D' 之后又开发了东西，rebase 回去

@mcfog
收到,感谢指导~

不要在公共分支上 rebase 或者 push -f，小心队友打死你
解决办法就是 push -f，然后让大家 fetch 再 rebase origin/master，最后自裁谢罪

@fov6363 无论如何都不应该两个人在一个分支上开发。
不知道你说的同一个功能什么意思，比如前后端在开发一个功能，约定好接口形式后就互相在新的分支上开发，先后合并到 feature 分支上，后者在自己的分支上 rebase feature 分支，这样不会有冲突。

@will0404
一个常见的功能场景是: 开发用户的登录注册 API,Bob 开发登录 API,Anna 开发注册 API,比如验证密码方法是共用的,Bob 就可以告诉 Anna 这个方法我开发了,你一会拉我代码直接用就行,一个分支开发就会很方便.....如果是两个分支的就会比较麻烦....我的意思是,如果一个功能在同一分支开发,会比较快, 带来的问题就是合并代码的问题...我觉得多人开发同一分支是常见操作....

分支设保护禁止 force push，Anna 正常 push，Bob 发现 push 不了，只能再 reset/rebase 回去。Bob 认栽，下次不敢再乱 rebase。

如果 Bob 已经 push -f 了，Anna 只好 rebase 再 push （然后打 Bob 一顿。

@fov6363 #18
多人用一个远程分支其实是省事的操作
你楼上说的是各自有各自的分支，但是合并提交到同一个 feature 分支里。然后 feature 分支正如 @h404bi #19 说的那样，禁止 push -f。
这种操作也能达到你想要的工作流，但是更规范和安全一些。

@fov6363 你们开发协作这么随意的吗？
任何功能合并到 feature 分支上不用经过 pr?不用 code review?
如果是你说的那么随意，那 master 什么时候合并 feature 分支？什么时候进行 code review ？

git rebase 之前先 git brance backup_xxx 备份下现有分支，还有后悔药可以吃

因为 bob 能看到版本 d，他需要把 e 给 cherry-pick 过来

不要在公共分支上 rebase +1
坑死队友